TCP的重传机制

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

序列号和确认号

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

  1. 序列号(Sequence Number):

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

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

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

      确认和应答

我们可以用wireshark抓包来看一下TCP的序列号和确认号:
seq
通过上图我们可以看到:

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

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

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

重传机制

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

超时重传

重传机制的其中一个方式,就是在发送数据时,设定一个定时器,当超过指定的时间后,如果还没有收到对方的ACK确认应答报文,就会重发该数据,也就是我们常说的超时重传。
超时重传
那么这个指定的时间,应该是多久比较合适呢?
这里先介绍两个概念:RTTRTO

  • 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
在这个例子中,SACK表示15870601~15873581之间的数据是已经收到的,所以客户端只需要重发15869201~15870600之间的数据就行了。

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


TCP的重传机制
https://blog.supersource.top/TCP_retransmission_mechanism/
作者
看热闹的咸鱼
发布于
2024年5月27日
许可协议