TCP协议详解

TCP，即Transmission Control Protocol，传输控制协议，对数据的传输进行详细的控制。

TCP协议段格式

源/目的端口号：表示数据从哪个进程来，到那个进程去。
源端口号表示报文的发送端口，源端口号和源IP地址组合起来可以表示报文的发送地址。
目的端口表示报文的接收端口，目的端口和目的IP地址组合起来可以表示报文的接收地址。
TCP协议就是根据IP协议的基础上传输的，TCP报文中的源端口号+源IP，与TCP报文中的目的端口号+目的IP一起，组合起来唯一性的确定一条TCP连接。
序号（Sequence Number）：TCP传输过程中，在发送端出的字节流中，传输报文中的数据部分的每一个字节都有它的编号。序号（Sequence
Number）占32位，发起方发送数据时，都需要标记序号。
在数据传输过程中，TCP协议通过序号（Sequence
Number）对上层提供有序的数据流。发送端可以用序号来跟踪发送的数据量；接收端可以用序号识别出重复接收到的TCP包，从而丢弃重复包；对于乱序的数据包，接收端也可以依靠序号对其进行排序。
序号会根据SYN是否为1，表示不同的意思：
当SYN为1时，当前为建立连接阶段；
当SYN为0是，数据传输正式开始。
确认序号（Acknowledgment Number）：确认序号标识了报文接收端期望接收的字节序列。如果设置了ACK控制位，确认序号的值表示一个准备接收的包的序列号，注意，它所指向的是准备接收的包，也就是下一个期望接收的包的序列号。
4位TCP报头长度：表示TCP头部有多少个32位bit（4字节）；所以TCP头部最大长度为 15 * 4 = 60字节。
6位标志位：

1. URG：紧急指针是否有效；
2. ACK：确认号是否有效，ACK置 1 ，代表起到了确认作用，需要填写确认序列号（下一次期望收到第一个字节的序列号）；
3. PSH：提示接收端应用程序立刻从TCP缓冲区把数据读走；
4. RST：对方要求重新建立连接，我们把携带RST标识的称为复位报文段；
5. SYN：请求建立连接，我们把携带SYN标识的成为同步报文段；
6. FIN：通知对方，本端要关闭了，我们称携带FIN标识的为结束报文段。

窗口大小：长度为16位，共2个字节。此字段用来进行流量控制。流量控制的单位为字节数，这个值是本端期望一次接收的字节数。
１６位校验和：发送端填充，CRC校验。接收端校验不通过，则认为数据有问题，此处的检验和不光包含TCP首部，也包含TCP数据部分。
16位紧急指针：标识那部分数据是紧急数据。

TCP原理

TCP对数据传输提供的管控机制，主要体现在两个方面：安全、效率。
这些机制和多线程的设计原则类似：保证数据传输的安全前提下，尽可能地提高传续效率。

确认应答机制

TCP将每个字节的数据进行了编号，即序列号。
每一个ACK都带有对应的确认序列号，意思是告诉发送者，我已经收到了那些数据，下一次你从哪里开始给我发。

超时重传机制

主机A给主机B发送了数据之后，可能会因为网络拥堵等原因，数据无法发送到B，如果A在一个特定的时间间隔内没有收到B发来的确认应答，就会重新发送。
当然，A没有收到确认应答，也可能是ACK丢了。因此，主机B会收到很多重复数据，可以利用序列号做到去重的效果。

那么超时时间如何确定？

最理想的情况下，找到一个最小的时间，保证 “确认应答一定能在这个时间内返回”。
但是这个时间的长短，随着网络环境的不同，是有差异的。
如果超时时间设的太长，会影响整体的重传效率；
如果超时时间设的太短，有可能会频繁发送重复的包

TCP为了保证无论在任何环境下都能比较高效地通信，因此会动态计算这个最大超时时间。

Linux中（BSD Unix和Windows也是如此），超时以500ms为一个单位进行控制，每次判定
超时重发的超时时间都是500ms的整数倍。
如果重发一次之后，仍然得不到应答，等待 2500ms后再进行重传。如果仍然得不到应答，等待 4500ms 进行重传。依次类推，以指数形式递增。
累计到一定的重传次数，TCP认为网络或者对端主机出现异常，强制关闭连接。

连接管理机制

在正常情况下，TCP要经过三次握手建立连接，四次挥手断开连接

三次握手：

1. 第一次握手：客户端进入SYN_SENT状态，发送一个SYN帧来主动打开传输通道，该帧的SYN标志位被设置为1，同时会带上Client分配好的SN序列号，该SN是根据时间产生的一个随机值。
2. 第二次握手：服务端在收到SYN帧之后，会进入SYN_RCVD状态，同时返回SYN+ACK帧给客户端，主要目的在于通知客户端，服务端已经收到SYN消息，现在需要进行确认。
   服务端发出的SYN+ACK帧的ACK标志位被设置为1，其确认序号ASN值被设置为客户端的SN+1；SYN+ACK帧的SYN标志位被设置为1，SN值为服务端生成的SN序号。
3. 第三次握手：客户端在收到服务端的第二次握手的SYN+ACK确认帧之后，首先将自己的状态会从SYN_SENT变成ESTABLISHED，表示自己方向的连接通道已经建立成功，客户端可以发送数据给服务端了。然后，客户端发ACK帧给服务端，该ACK帧的ACK标志位被设置为1，其确认序号ASN值被设置为服务端的SN序列号+1。
4. 服务端收到客户端的ACK之后，会从SYN_RCVD状态变成ESTABLISHED状态，至此，TCP全双工连接建立完成。

四次挥手：

1. 第一次挥手：主动断开方向对方发送一个FIN结束请求报文，此报文的FIN位被设置为1，发送完成后，主动断开方进入FIN_WAIT_1状态，这表示主动断开方没有业务数据要发送给对方，准备关闭SOCKET连接了。
2. 第二次挥手：正常情况下，在收到了主动断开方发送的FIN断开请求报文后，被动断开方会发送一个ACK响应报文，之后，被动断开方就进入了CLOSE-WAIT（关闭等待）状态，TCP协议服务会通知高层的应用进程，对方向本地方向的连接已经关闭，对方已经没有数据要发送了，若本地还要发送数据给对方，对方依然会接受。被动断开方的CLOSE-WAIT（关闭等待）还要持续一段时间，也就是整个CLOSE-WAIT状态持续的时间。
3. 第三次挥手：在发送完成ACK报文后，被动断开方还可以继续完成业务数据的发送，待剩余数据发送完成后，或者CLOSE-WAIT（关闭等待）截止后，被动断开方会向主动断开方发送一个FIN+ACK结束响应报文，表示被动断开方的数据都发送完了，然后，被动断开方进入LAST_ACK状态。
4. 第四次挥手：主动断开方收在到FIN+ACK断开响应报文后，还需要进行最后的确认，向被动断开方发送一个ACK确认报文，然后，自己就进入TIME_WAIT状态，等待超时后最终关闭连接。处于TIME_WAIT状态的主动断开方，在等待完成2MSL的时间后，如果期间没有收到其他报文，则证明对方已正常关闭，主动断开方的连接最终关闭。
   被动断开方在收到主动断开方的最后的ACK报文以后，最终关闭了连接。

为什么TIME_WAIT的时间是2MSL呢？
MSL是TCP报文的最大生存时间，因此TIME_WAIT持续存在2MSL的话就能保证在两个传输方向上的尚未被接收或迟到的报文段都已经消失（否则服务器立刻重启，可能会收到来自上一个进程的迟到的数据，但是这种数据很可能是错误的）；
同时也是在理论上保证最后一个报文可靠到达（假设最后一个ACK丢失，那么服务器会再重发一个FIN。这时虽然客户端的进程不在了，但是TCP连接还在，仍然可以重发LAST_ACK）。

TCP状态转换汇总：

滑动窗口

刚才我们讨论了确认应答策略，对每一个发送的数据段，都要给一个ACK确认应答。收到ACK后再发送下一个数据段。这样做有一个比较大的缺点，就是性能较差。尤其是数据往返的时间较长的时候。
既然这样一发一收的方式性能较低，那么我们一次发送多条数据，就可以大大的提高性能（其实是将多个段的等待时间重叠在一起了）。

• 窗口大小指的是无需等待确认应答而可以继续发送数据的最大值。上图的窗口大小就是4000个字节（四个段）。
• 发送前四个段的时候，不需要等待任何ACK，直接发送；
• 收到第一个ACK后，滑动窗口向后移动，继续发送第五个段的数据；依次类推；
• 操作系统内核为了维护这个滑动窗口，需要开辟 发送缓冲区 来记录当前还有哪些数据没有应答；只有确认应答过的数据，才能从缓冲区删掉；
• 窗口越大，则网络的吞吐率就越高

如果出现丢包，如何进行重传？

情况一：数据包已经抵达，ACK被丢了

这种情况下，部分ACK丢了并不要紧，因为可以通过后续的ACK进行确认

情况二：数据包就直接丢了

• 当某一段报文段丢失之后，发送端会一直收到 1001 这样的ACK，就像是在提醒发送端 “我想要的是 1001” 一样；
• 如果发送端主机连续三次收到了同样一个 “1001” 这样的应答，就会将对应的数据 1001 - 2000 重新发送；
• 这个时候接收端收到了 1001 之后，再次返回的ACK就是7001了（因为2001 - 7000）接收端其实之前就已经收到了，被放到了接收端操作系统内核的接收缓冲区中

流量控制

接收端处理数据的速度是有限的。如果发送端发的太快，导致接收端的缓冲区被打满，这个时候如果发送端继续发送，就会造成丢包，继而引起丢包重传等等一系列连锁反应。
因此TCP支持根据接收端的处理能力，来决定发送端的发送速度。这个机制就叫做流量控制（Flow Control）。

• 接收端将自己可以接收的缓冲区大小放入 TCP 首部中的 “窗口大小” 字段，通过ACK端通知发送端；
• 窗口大小字段越大，说明网络的吞吐量越高；
• 接收端一旦发现自己的缓冲区快满了，就会将窗口大小设置成一个更小的值通知给发送端；
• 发送端接受到这个窗口之后，就会减慢自己的发送速度；
• 如果接收端缓冲区满了，就会将窗口置为0；这时发送方不再发送数据，但是需要定期发送一个窗口探测数据段，使接收端把窗口大小告诉发送端。

接收端如何把窗口大小告诉发送端呢？回忆我们的TCP首部中，有一个16位窗口字段，就是存放了窗口大小信息。

拥塞控制

TCP引入 慢启动 机制，先发少量的数据，探探路，摸清当前的网络拥堵状态，再决定按照多大的速度传输数据。慢启动，只是初始时慢，增长的很快

为了不增长的那么快，因此不能使拥塞窗口单纯的加倍。
此处引入一个叫做慢启动的阈值
当拥塞窗口超过这个阈值的时候，不再按照指数方式增长，而是按照线性方式增长
当TCP开始启动的时候，慢启动阈值等于窗口最大值；
在每次超时重发的时候，慢启动阈值会变成原来的一半，同时拥塞窗口置回1

少量的丢包，我们仅仅是触发超时重传；大量的丢包，我们就认为网络拥塞;
当TCP通信开始后，网络吞吐量会逐渐上升；随着网络发生拥堵，吞吐量会立刻下降;
拥塞控制，归根结底是TCP协议想尽可能快的把数据传输给对方，但是又要避免给网络造成太大压力的折中方案。

延迟应答

如果接收数据的主机立刻返回ACK应答，这时候返回的窗口可能比较小。

假设接收端缓冲区为1M。一次收到了500K的数据；如果立刻应答，返回的窗口就是500K；
但实际上可能处理端处理的速度很快，10ms之内就把500K数据从缓冲区消费掉了；
在这种情况下，接收端处理还远没有达到自己的极限，即使窗口再放大一些，也能处理过来；
如果接收端稍微等一会再应答，比如等待200ms再应答，那么这个时候返回的窗口大小就是1M

每隔N个包就要应答一次，或者超过最大应答时间也要应答一次。
N一般取2，超时时间取200ms。
窗口越大，网络吞吐量就越大，传输效率就越高。我们的目标是在保证网络不拥塞的情况下尽量提高传输效率。

捎带应答

在延迟应答的基础上，我们发现，很多情况下，客户端服务器在应用层也是 “一发一收” 的。意味着客户端给服务器说了 “How are you”，服务器也会给客户端回一个 “Fine, thank you”；
那么这个时候ACK就可以搭顺风车，和服务器回应的 “Fine，thank you” 一起回给客户端

粘包问题

1. 对于定长的包，保证每次都按固定大小读取即可；例如上面的Request结构，是固定大小的，那么就从缓冲区从头开始按sizeof（Request）依次读取即可；
2. 对于变长的包，可以在包头的位置，约定一个包总长度的字段，从而就知道了包的结束位置；
3. 对于变长的包，还可以在包和包之间使用明确的分隔符。

TCP异常情况

进程终止：进程终止会释放文件描述符，仍然可以发送FIN。和正常关闭没有什么区别。
机器重启：和进程终止的情况相同。
机器掉电/网线断开：接收端认为连接还在，一旦接收端有写入操作，接收端发现连接已经不在了，就会进行reset。即使没有写入操作，TCP自己也内置了一个保活定时器，会定期询问对方是否还在。如果对
方不在，也会把连接释放。

另外，应用层的某些协议，也有一些这样的检测机制。例如HTTP长连接中，也会定期检测对方的状态。
例如QQ，在QQ断线之后，也会定期尝试重新连接。

TCP ： 可靠、有连接、面向字节流