TCP 是一个可靠的传输协议,解决了IP层的丢包、乱序、重复等问题。这其中,TCP的重传机制起到重要的作用。
序列号和确认号
之前我们在讲解TCP三次握手时,提到过TCP包头结构,其中有序列号和确认号,
而TCP 实现可靠传输的方式之一,就是是通过序列号和确认应答。
-
序列号(Sequence Number):
- TCP是基于数据流的,序列号用于标识数据流中的字节位置,它表示数据包中的第一个字节在整个数据流中的位置。
- 接收方在接收到数据包后,会根据序列号对数据包进行排序和重组,确保数据的顺序正确。
-
确认号(Acknowledgement Number):
-
确认号用于确认接收方已经成功接收了数据,并且期望下一个接收到的数据包的序列号是多少。
-
在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
和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的数据