1、背景介绍
TCP使用可靠的传输协议,即意味着必须按序、无差错的传送数据到目的端,那么如果在传输过程中发送的包丢失了该怎么办?TCP的重传机制就是:如果发送方认为发生了丢包现象就重发这些数据包。显然,我们需要一个方法去猜测是否发生了丢包。最简单的想法就是,接收方每接收到一个包就向发送者返回一个ACK,表示自己已经收到了这段数据,反过来,如果发送方一段时间内没有收到ACK,就知道很可能是数据包丢失了,紧接着就重发该数据包,直到收到ACK为止。
为什么是猜测呢? 因为即使是超时了,这个数据包也可能并没有丢,它只是绕了段远程,来的很晚而已。毕竟TCP协议是位于传输层的协议,不可能明确知道数据链路层和物理层发生了什么。但是这并不妨碍我们的超时重传机制,因为接收方会自动忽略收到的重复的包。
下面我们具体讲一讲TCP的重传机制:
2、重传--TCP的重要事件
(1)基于计时器的重传---超时重传
这种机制下,每个数据包都有相应的计时器,当超过指定的时间后,没有收到对方的 ACK 确认应答报文就会重发该数据包。
超时时间应该设置为多少
我们先来了解一下 RTT (Round-Trip Time 往返时延)
而超时时间是以 RTO(Retransmission Timeout 超时重传时间)表示。
超时时间不宜设置的过长或过短,否则:
综上可知,RTO设置的值应该略大于RTT的值。
RTO值的计算:
https://blog.csdn.net/JXH_123/article/details/27345151
值得注意的是:每触发一次超时重传,都会将下一次超时时间间隔设为先前值的两倍。遇到超时说明网络环境差,不宜频繁发送。
Wireshark 抓包显示:
超时重传存在的问题是:
当一个报文段丢失时,会等待一定的超时时间后才重传,增加了端到端的时延;
当一个报文段丢失时,在其等待超时的过程中,可能会出现这种情况: 其后的报文段已经被接收端接收但却迟迟得不到确认,发送端就也以为丢失了,从而引起不必要的重传,既浪费时间也浪费资源。(例如: 数据包5丢失,数据包6、7、8、9都已到达接收方,这个时候客户端只能等服务端发送ACK,因此对于客户端来说,它完全不知道丢了几个包,可能就悲观的认为:5后面的数据包都丢了,就重传这5个数据包,这就比较浪费了)。
(2)基于接收方的反馈信息的重传---快速重传
刚刚提到过,基于计时器的重传往往要等待很长时间,而快速重传使用了很巧妙的方法来解决这个问题。
快速重传(Fast Retransmit)机制不以时间为驱动,而是以数据为驱动重传。
由于TCP采用的是累计确认机制,当接收端收到比期望序号大的报文段时,便会重复发送最近一次确认的报文段的确认号,即 冗余 ACK (Duplicate ACK)。
这样,如果在超时重传定时器溢出之前,接收到连续的三个重复冗余 ACK (第一个ACK是正常的,后三个是冗余的),发送端便知晓哪个报文段在传输过程中丢失了,于是重发该报文段,而不需要等待超时重传定时器溢出,大大提高了效率。
Wireshark 抓包显示:
但是,快速重传仍然没有解决第二个问题:到底该重传多少个包?
(3)带选择确认的重传---SACK
改进的方法就是 SACK (Selective Acknowledgment),简单来说就是在快速重传的基础上,返回最近收到的报文段的序列号范围,这样客户端就知道,哪些数据包已经到达服务器了。
看下例子:
存在 SACK 选项时
当500-599报文到达,接收方发送 ACK 200 ,SACK [500,600)
当600-699报文到达,接收方发送 ACK 200 ,SACK [500,700)
当700-799报文到达
当800-899报文到达
当900-999报文到达,接收方累积确认发送 ACK 200 ,SACK [500,1000)
连续收到3个重复ACK,发送方经检查发现200-499的数据丢失了,执行快速重传,待接收方接收到200-499的数据,并返回 ACK 1000时,发送方的所有数据均已确认完毕,移动滑动窗口到1000位置处。
使用 SACK可以告知发送方 收到了哪些数据,发送方收到这些消息后就会知道哪些数据丢失,然后立即重传丢失的部分。
需要注意的是:只有收到失序的分组时才可能会发送SACK。
SACK 包括了两个TCP选项,一个选项用于标识是否支持 SACK(SACK_Permitted),在TCP建立连接时发送;另一种选项则包含了具体的 SACK信息。
(1)SACK_Permitted 选项
该选项只允许在TCP连接建立时,有 SYN标志的包中设置,在连接建立阶段,主动发起连接的一方在它的SYN中指定选项。只有在它从另一方的SYN中收到了这个选项之后,SACK机制才会被使能。
(2)SACK 信息选项
SACK 选项参数告诉对方已经接收到并缓存的不连续的数据块,发送方可据此信息检查究竟是哪个块丢失,从而发送相应的数据块。
Left Edge:本区块的第一个序号。 Right Edge:本区块的最后序号的下一个序号。
[Left Edge, Right Edge)区间的ACK 序号表示本次确认收到的序号。
问题1:SACK选项最多能包含多少个需重传的块?
由于TCP首部的最大长度为 60 byte,而固定首部占用了 20 byte,对于SACK选项本身占用了2 byte,所以剩下 60-20-2=38 byte。而每个块(包括开始和结束)占用 8 byte,所以最多可标识的块数为 38/8 = 4块,所以 SACK 最多可以包括4个需重传的块。同时由于SACK有些时候会和时间戳(占10字节)一起用,因此,此种情况下最多只有3个SACK。
问题2:SACK选项的使用规则是怎么样的?
SACK 的发送方,即 报文的接收端
第一个块需要指出是哪一个到达的报文触发的 SACK
尽可能多的把所有的块填满
SACK 要报告最近接收的不连续的数据块
SACK 的接收端,即 报文的发送端:
数据没有被确认前,都会保持在滑动窗口内
每个数据包都有一个 SACKed 的标志,对于已经标示的报文,再次接收到时会忽略
如果SACK丢失,超时重传之后,重置所有数据包SACKed 标志
(4)带重复选择确认的重传---DSACK
DSACK是在SACK的基础上做了一些扩展,主要用于对收到的重复报文进行了处理。
它的主要作用是:告诉发送方有哪些数据被重复接收了。
DSACK同样使用了与SACK一样的报文格式,唯一区别在于:第一个连续的block指定的是触发DSACK的重复报文的序号空间。如果第一个段的范围被ACK范围所覆盖,那么就是DSACK。或者,第一个段的范围被SACK的第二个段覆盖,那么就是DSACK。
引入DSACK的好处有:
1)可以让发送方知道,是发出去的包丢了,还是回来的ACK包丢了;
2)是不是自己的 timeout 设置太小了,导致重传;
3)网络上出现了先发的包后到的情况(又称数据包失序);
4)网络上是不是把我的数据包给复制了;
总之,DSACK的目的是帮助发送方判断,是否发生了包失序、ACK丢失、包重复或伪重传,让TCP可以更好的做网络流量控制。
3、总结
超时重传机制能解决数据包丢失的问题,但是超时重传机制存在等待时间太长,浪费时间在等待上,降低了传输效率和无法知道需要重传哪些数据包的问题。 快速重传能解决超时重传的等待时间太长的问题,但是对于究竟该重传哪些包的问题仍然不能有效解决。SACK能需要重传哪些数据包的问题,它可以知道哪些包是被确认接收的,客户端能据此判断需要重传的包。DSACK则是作为SACK的一个辅助措施,可以用来判断网络究竟是出现了什么情况,据此做好网络流量控制。