目录
1.TCP协议格式
首先回答三个问题
一、TCP如何进行解包？
在报文的前20个字节中，包含了一些存储信息（不包含选项）。其中有4位首部长度，可以代表0-15的数字，单位是4字节。最多可以表示60字节，最少为5表示20字节，代表着报头的长度。
所以选项的字节数就是 首部长度*4-20 ，当读完了这么多字节后。剩下的就全都是有效载荷。
二、如何理解TCP报头？
和UDP一样，其实就是位段。
三、如何理解可靠性？
首先需要知道，为什么不可靠。网络通信就好比两个相距很远的人进行交流。当一方说的话没有被对方听清，所以对方没有回复，我也就不知道信息是否被成功接受，这就是不可靠。
我们无法保证自己最新发送的消息有没有被对方接收到。但我们可以保证在最新发送的消息之前的所有信息的可靠性。
如何保证可靠？
我所发出去的所有消息中，只要有匹配的的应答，我就能保证我刚刚发送出去的消息被成功接受了。
TCP协议的确认应答机制也是如此，只要一个报文收到了对应的应答，就能保证我发出的数据被对方收到了。
1.2 32位序号和32位确认序号
32位序号
client可能一次向服务端发送多个请求，但是这些发送的顺序，不一定就是接受数据。报文中的32位序号可以用来缓解这个问题、
假设客户端向服务端发送了3条报文，发送的时候，这些报文会携带序号。假设序号分别为1000、2000、3000。
当server收到这些序号，给客户端应答的时候，也会携带序号，一般为收到的序号+1，所以会发送三条序号分别为1001、2001、3001的报文。当客户端收到报文后，就会一定会用这些序号填上确认序号。
32位确认序号
表示确认序号对应的数字，之前的所有报文已经全部接受到了。告诉对方下次发送时，从确认序号指明的序号发送
序号和确认序号作用
1.将请求和应答一一对应。
2.确认序号，表示的含义是：确认序号之前的数据已经全部收到。
3.允许部分确认丢失，或者不给应答。
4.为什么有两个字段数据？ 任何通信的一方，工作方式都是全双工的，在发送确认的同时，也可能携带新的数据。
5.发送的顺序和接受的数据可能不一致，可以根据序号进行排序。
1.3 16位窗口大小
首先回答一个问题：TCP如何做到全双工呢？
TCP中是有接受缓冲区和发送缓冲区的。要实现全双工，本质上就是发送缓冲区和对方的接受缓冲区进行通信，对方的发送缓冲区和接受缓冲区进行通信。
既然数据是存放在缓冲区的，那有没有可能client发送数据太快，导致接受缓冲区已满，那我通过协议层辛辛苦苦传的数据怎么办呢？又不是我客户端的问题导致的信息失效。
如何保证发送放发送数据既不能太快，也不能太慢。
就需要进行流量控制。报头中有16位窗口大小，也就是表示着接受缓冲区中的剩余空间大小。会在双方发送信息的时候同步给对方。
1.4 六个标记位
客户端和服务端进行发送报文时，一定具有很多类型，比如常规报文，建立连接的报文，断开连接的报文，还有用于确认的发送的报文。
SYN： 该报文是一个连接请求报文。
FIN：该报文是一个断开连接请求的报文.
ACK：确认应答标志位，凡是报文具有应答特征。该标志位都会被设置为1。大部网络报文ACK都是被设置为1，第一个连接请求报文。
RST：该报文是一个连接重置的标记位。
当遇到一些问题，（比如服务端重启了，或者服务端的连接还没建立好，客户端就已经发消息了，或者访问一个页面长时间不操作，再次操作时需要重新进入页面也就是重置连接）服务端认为连接异常时，就会给客户端发送一个报文数据，该报文的RST标记位置一。当客户端收到这个报文，就会重新发起三次握手。
PSH：让对方尽快将数据进行向上交付。
当客户端收到窗口大小为0的报文时，客户端只能等待服务端的数据进行交付后，空余出了空间再发送消息。当等待时间较长时，就会发送一个PSH置一的报文，督促服务端进行数据交付。
URG：紧急标志位
因为tcp是具有按序到达机制的，我们发送的数据，被对方上层读取到，就必须得有先后顺序。如果要想插队，就需要发送URG标记为置一的报文。
一般都是搭配报头中的16位紧急指针来使用的。
2.三次握手 四次挥手
如何理解连接？
因为一定有大量的客户端将来可能连接server，所以server端一定存在大量的连接。那操作系统会对这些连接进行管理（先描述，再组织）。
所谓连接本质就是内核中的一种数据结构，建立连接成功的时候，就是在内核中创建对应的连接对象。再对多个连接对象进行某种数据结构的组织。维护连接是有成本的（内存+CPU）。
2.1 如何理解三次握手？
问题：
是不是三次握手一定要保证成功？
不一定。因为最后一次SYN无法得知是否被对方接受到。
为什么一定是三次呢？一次、两次、四次可以吗？
一次握手，客户端只要发起请求，就会设置自身状态。同样服务端也是，只要接受到了客户端的请求，就会建立连接，设置状态。但是如果遭到攻击呢？
大量的敌意客户端向服务端进行SYN请求，服务端维持连接是有成本的。累计到一定数量，服务端就会崩溃。这样的情况称为SYN洪水。
两次握手。服务端当接受到SYN请求，并发送ACK+SYN之后，就会建立连接。但是对于客户端而言，他的连接是建立在服务端之后的。客户端如果拒绝了连接的报文。那么只会有服务端维护了连接，具有维护成本。而客户端没有。依然不能防止SYN洪水。
四次握手。和两次握手一样，也是服务端先建立连接，先开始对连接的维护。不能防止SYN洪水。
5/7/9次握手。既然三次握手就可以达到目的，为什么要进行这么多次？
为什么要三次握手
1.server可以嫁接同等成本给client
2.验证全双工
2.2 如何理解四次挥手
发起FIN其实就是调用了close()接口。
那如果我们发现服务端具有大量的CLOSE_WAIT状态的连接，原因是什么呢？
应用层服务器写的有BUG，没有关闭对应的连接socket
如果没有TIME_WAIT而是直接关闭时，如果当发送给服务端的ACK报文丢失，服务端也就会重传。如果在等待期间客户端又收到了FIN报文，将会补发ACK
在TIME_WAIT的等待期间，可以有较大的概率将ACK准确的发送给对方。
[TIME_WAIT -> CLOSED] 客户端要等待一个2MSL(Max Segment Life, 报文最大生存时间，即一来一回传输的总时间)的时间, 才会进入CLOSED状态
2379
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
