TCP的重传机制

TCP 是一个可靠的传输协议，解决了IP层的丢包、乱序、重复等问题。这其中，TCP的重传机制起到重要的作用。

序列号和确认号

之前我们在讲解TCP三次握手时，提到过TCP包头结构，其中有序列号和确认号，
而TCP 实现可靠传输的方式之一，就是是通过序列号和确认应答。

1. 序列号(Sequence Number):

   • TCP是基于数据流的，序列号用于标识数据流中的字节位置，它表示数据包中的第一个字节在整个数据流中的位置。
   • 接收方在接收到数据包后，会根据序列号对数据包进行排序和重组，确保数据的顺序正确。

2. 确认号(Acknowledgement Number)：

   • 确认号用于确认接收方已经成功接收了数据，并且期望下一个接收到的数据包的序列号是多少。

   • 在TCP通信中，接收方会向发送方发送一个确认数据包，其中包含了确认号，表示接收到的数据包中的最后一个字节的下一个字节的序列号。

     

我们可以用wireshark抓包来看一下TCP的序列号和确认号：

通过上图我们可以看到：

1. 进行三次握手时，客户端的初始序列号是2924706275，服务端的初始序列号是1859008164。
2. 发送第一个包时，序列号是2924706276，是初始序列号+1，表示当前数据是第一个字节，数据长度8字节。
3. 服务端回复ACK时，确认号是2924706284，是客户端的初始序列号+9，表示已经接收到前8个字节，现在期待第9个字节。
4. 客户端继续发第二个包，序列号2924706284，表示当前数据是第9个字节。
5. 服务端回复ACK时，确认号是2924706292，是客户端的初始序列号+17，表示已经接收到前16个字节，现在期待第17个字节。

在wireshark中，可以显示相对的序列号，可以更直观地看到序列号的变化：

这里我们可以看到，服务端发的包，序列号一直是1，因为当前服务端只是接收数据，并没有发送数据，所以服务端的序列号一直是1，而客户端的确认号也一直是1，表示期待服务端发送第一个字节过来。

重传机制

正常情况下，当发送端的数据到达接收主机时，接收端主机会返回一个确认应答消息，表示已收到消息。
但在复杂的网络下，并不一定能顺利的进行数据传输，万一数据在传输过程中丢失了呢？针对数据包丢失的情况，TCP会用重传机制解决。

超时重传

重传机制的其中一个方式，就是在发送数据时，设定一个定时器，当超过指定的时间后，如果还没有收到对方的ACK确认应答报文，就会重发该数据，也就是我们常说的超时重传。

那么这个指定的时间，应该是多久比较合适呢？
这里先介绍两个概念：RTT和RTO

• RTT(Round-Trip Time) 往返时延，指的是数据发送时刻到接收到确认的时刻的差值，也就是包的往返时间
• RTO(Retransmission Timeout)，就是超时重传时间。

通常RTO应该略大于RTT：

• 如果RTO太短，有可能数据没有丢失就重发，增加网络拥塞。
• 如果RTO太长，重发就慢，性能差。

由于网络的不稳定，RTT是经常变化的，导致RTO也会是一个动态变化的值。

如果超时重发的数据，再次超时的话，下一次重传的时间间隔则会加倍。
超时重传存在的问题是，超时周期可能相对较长。那是不是可以有更快的方式呢？

TCP用快速重传机制来解决超时重发的时间等待。

快速重传

发送方发包的时候，并不总是等待ACK的响应再发送下一个包，而是会在窗口大小内，连续发多个包：

如果其中一个包丢失了，而后续的包到达时，接收方会发丢失的包的ACK给发送方。当发送方连接收到三个相同的ACK时，就知道这个包丢失了，于是不用等重传定时，直接就可以重新发送了：

通过wireshark抓包，在过滤器中输入tcp.analysis.fast_retransmission，我们可以观察到快速重传的现象：

SACK

快速重传机制解决了超时时间的问题，但是它面临着另外一个问题：那就是重传的时候，是重传一个包，还是重传所有的包？像上面的例子，客户端发出19个包，当触发快速重传的时候，客户端只知道第2个包丢失了，那其他包是否丢失，客户端并不清楚，这时候有两种选择：

• 重发2~19所有的包，显然会造成数据的浪费，因为后面17个包都是已经收到的。
• 只重发第2个包。但如果第3个包也丢失的话，那么又得等到三次ACK才能重发第3个包，效率较低。

这时候，SACK(Selective Acknowledgment)，选择性确认，就可以起作用了。
这种方式需要在TCP头部选项字段里加一个SACK的选项，它可以将已收到的数据的信息发送给发送方 ，这样发送方就可以知道哪些数据收到了，哪些数据没收到，知道了这些信息，就可以只重传丢失的数据了 。

在这个例子中，SACK表示15870601~15873581之间的数据是已经收到的，所以客户端只需要重发15869201~15870600之间的数据就行了。

由于TCP头部大小的限制，在选项中最多能支持四组SACK的数据