为了搜集足够的数据来精确地估算当前的RTT，TCP对每个报文都记录下发送出的时间和收到的确认时间。每一个（发送时间，确认时间）对就可以计算出一个RTT测量值的样本（Sample RTT）。TCP为每一个活动的连接都维护一个当前的RTT估计值。该值是对已经过去的一个时间段内该连接的RTT了两只的加权平均，并作为TCP对连接当前实际的RTT值的一种估计。RTT估计值将在发送报文段时被用于确定报文段的RTO。为了保证它能够比较准确地反应当前的网络状态，每当TCP通过测量获得了个新的RTT样本时，都将对RTT的估计值进行更新。不同的更新算法或参数可能获得不同的特性。
最早的TCP曾经用了一个非常简单的公式来估计当前网络的状况，如下
R<-aR+(1-a)MRTP=Rb其中a是一个经验系数为0.1，b通常为2。注意，这是经验，没有推导过程，这个数值是可以被修改的。这个公式是说用旧的RTT(R)和新的RTT (M)综合到一起来考虑新的RTT(R)的大小。但又可以看到，这种估计在网络变化很大的情况下完全不能做出“灵敏的反应”，于是就有下面的修正公式：
Err=M-AA<-A+gErrD<-D+h(|Err|-D)RTO=A+4D，这个递推公式甚至把方差这种统计概念也使用了进来，使得偏差更加的小。而且，必须要指出的是，这两组公式更新，都是在 数据成功传输的情况下才进行，在发生数据重新传输的情况下，并不使用上面的公式进行网络估计，理由很简单，因为程序已经不在正常状态下了，估计出来的数据 也是没有意义的。
TCP使用可靠的传输协议，即意味着必须按序、无差错的传送数据到目的端，那么如果在传输过程中发送的包丢失了该怎么办？TCP的重传机制就是：如果发送方认为发生了丢包现象就重发这些数据包。显然，我们需要一个方法去 猜测是否发生了丢包 。最简单的想法就是，接收方每接收到一个包就向发送者返回一个ACK，表示自己已经收到了这段数据，反过来，如果发送方一段时间内没有收到ACK，就知道 很可能是数据包丢失 了，紧接着就重发该数据包，直到收到ACK为止。
为什么是 猜测 呢？ 因为即使是超时了，这个数据包也可能并没有丢，它只是绕了段远程，来的很晚而已。毕竟TCP协议是位于传输层的协议，不可能明确知道数据链路层和物理层发生了什么。但是这并不妨碍我们的超时重传机制，因为接收方会自动忽略收到的重复的包。
下面我们具体讲一讲TCP的重传机制：
这种机制下，每个数据包都有相应的计时器，当超过指定的时间后，没有收到对方的 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个数据包，这就比较浪费了）。
刚刚提到过，基于计时器的重传往往要等待很长时间，而快速重传使用了很巧妙的方法来解决这个问题。
快速重传（Fast Retransmit）机制 不以时间为驱动，而是以数据为驱动重传。
由于TCP采用的是累计确认机制，当接收端收到比期望序号大的报文段时，便会重复发送最近一次确认的报文段的确认号，即 冗余 ACK (Duplicate ACK)。
这样，如果在超时重传定时器溢出之前，接收到连续的三个重复冗余 ACK (第一个ACK是正常的，后三个是冗余的)，发送端便知晓哪个报文段在传输过程中丢失了，于是重发该报文段，而不需要等待超时重传定时器溢出，大大提高了效率。
Wireshark 抓包显示：
但是，快速重传仍然没有解决第二个问题：到底该重传多少个包？
改进的方法就是 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 标志
DSACK是在SACK的基础上做了一些 扩展 ，主要用于对收到的 重复报文 进行了处理。
它的主要作用是：告诉发送方有哪些数据被重复接收了。
DSACK同样使用了与SACK一样的报文格式，唯一区别在于： 第一个连续的block指定的是触发DSACK的重复报文的序号空间。如果第一个段的范围被ACK范围所覆盖，那么就是DSACK。或者，第一个段的范围被SACK的第二个段覆盖，那么就是DSACK。
引入DSACK的好处有：
1）可以让发送方知道，是发出去的包丢了，还是回来的ACK包丢了；
2）是不是自己的 timeout 设置太小了，导致重传；
3）网络上出现了先发的包后到的情况（又称数据包失序）；
4）网络上是不是把我的数据包给复制了；
总之，DSACK的目的是帮助发送方判断，是否发生了包失序、ACK丢失、包重复或伪重传，让TCP可以更好的做网络流量控制。
超时重传机制能解决数据包丢失的问题，但是超时重传机制存在等待时间太长，浪费时间在等待上，降低了传输效率和无法知道需要重传哪些数据包的问题。 快速重传能解决超时重传的等待时间太长的问题，但是对于究竟该重传哪些包的问题仍然不能有效解决。SACK能需要重传哪些数据包的问题，它可以知道哪些包是被确认接收的，客户端能据此判断需要重传的包。DSACK则是作为SACK的一个辅助措施，可以用来判断网络究竟是出现了什么情况，据此做好网络流量控制。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）