TCP的重传机制详解:从序列号到SACK
TCP的重传机制详解:从序列号到SACK
TCP(传输控制协议)是一个可靠的传输协议,它通过重传机制解决了IP层的丢包、乱序、重复等问题。本文将详细介绍TCP的重传机制,包括序列号和确认号的工作原理、超时重传、快速重传以及选择性确认(SACK)等关键技术。
序列号和确认号
在讲解TCP的重传机制之前,我们先回顾一下TCP包头中的序列号(Sequence Number)和确认号(Acknowledgement Number)。
序列号
- 作用:TCP是基于数据流的,序列号用于标识数据流中的字节位置,它表示数据包中的第一个字节在整个数据流中的位置。
- 功能:接收方在接收到数据包后,会根据序列号对数据包进行排序和重组,确保数据的顺序正确。
确认号
- 作用:确认号用于确认接收方已经成功接收了数据,并且期望下一个接收到的数据包的序列号是多少。
- 功能:在TCP通信中,接收方会向发送方发送一个确认数据包,其中包含了确认号,表示接收到的数据包中的最后一个字节的下一个字节的序列号。
通过Wireshark抓包,我们可以直观地看到TCP的序列号和确认号的工作过程:
从上图中可以看出:
- 进行三次握手时,客户端的初始序列号是2924706275,服务端的初始序列号是1859008164。
- 发送第一个包时,序列号是2924706276,是初始序列号+1,表示当前数据是第一个字节,数据长度8字节。
- 服务端回复ACK时,确认号是2924706284,是客户端的初始序列号+9,表示已经接收到前8个字节,现在期待第9个字节。
- 客户端继续发第二个包,序列号2924706284,表示当前数据是第9个字节。
- 服务端回复ACK时,确认号是2924706292,是客户端的初始序列号+17,表示已经接收到前16个字节,现在期待第17个字节。
在Wireshark中,可以显示相对的序列号,可以更直观地看到序列号的变化:
这里我们可以看到,服务端发的包,序列号一直是1,因为当前服务端只是接收数据,并没有发送数据,所以服务端的序列号一直是1,而客户端的确认号也一直是1,表示期待服务端发送第一个字节过来。
重传机制
正常情况下,当发送端的数据到达接收主机时,接收端主机会返回一个确认应答消息,表示已收到消息。但在复杂的网络下,并不一定能顺利的进行数据传输,万一数据在传输过程中丢失了呢?针对数据包丢失的情况,TCP会用重传机制解决。
超时重传
重传机制的其中一个方式,就是在发送数据时,设定一个定时器,当超过指定的时间后,如果还没有收到对方的ACK确认应答报文,就会重发该数据,也就是我们常说的超时重传。
那么这个指定的时间,应该是多久比较合适呢?这里先介绍两个概念:
- 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表示1587060115873581之间的数据是已经收到的,所以客户端只需要重发1586920115870600之间的数据就行了。由于TCP头部大小的限制,在选项中最多能支持四组SACK的数据。