上一篇介绍 TCP 的文章「

但是对于客户端来说，它不知道发生了哪种情况，选错情况的结果就是 RTT 偏大/偏小，影响到 RTO 的计算。（最简单粗暴的解决方法就是忽略有重传的数据包，只计算那些没重传过的，但这样会导致其他问题。。详见 Karn's algorithm）

标准方法

说实话这个标准方法比较，，，麻烦，我就直接贴公式了：

​ SRTT <- (1 - α)·SRTT + α·RTT //跟基本方法一样，求 SRTT 的加权平均

​ rttvar <- (1 - h)·rttvar + h·(|RTT - SRTT |) //计算 SRTT 与真实值的差距（称之为绝对误差|Err|），同样用到加权平均

​ RTO = SRTT + 4·rttvar //估算出来的新的 RTO，rttvar 的系数 4 是调参调出来的

这个算法的整体思想就是结合平均值（就是基本方法）和平均偏差来进行估算，一波玄学调参得到不错的效果。如果想更深入了解这个算法，参考「RFC6298」。

重传——TCP的重要事件

基于计时器的重传

这种机制下，每个数据包都有相应的计时器，一旦超过 RTO 而没有收到 ACK，就重发该数据包。没收到 ACK 的数据包都会存在重传缓冲区里，等到 ACK 后，就从缓冲区里删除。

首先明确一点，对 TCP 来说，超时重传是相当重要的事件（RTO 往往大于两倍的 RTT，超时往往意味着拥塞），一旦发生这种情况，TCP 不仅会重传对应数据段，还会降低当前的数据发送速率，因为TCP 会认为当前网络发生了拥塞。

简单的超时重传机制往往比较低效，如下面这种情况：

假设数据包5丢失，数据包 6,7,8,9 都已经到达接收方，这个时候客户端就只能等服务器发送 ACK，注意对于包 6,7,8,9，服务器都不能发送 ACK，这是滑动窗口机制决定的，因此对于客户端来说，他完全不知道丢了几个包，可能就悲观的认为，5 后面的数据包也都丢了，就重传这 5 个数据包，这就比较浪费了。

快速重传

快速重传机制「

但快速重传仍然没有解决第二个问题：到底该重传多少个包？

带选择确认的重传

改进的方法就是 SACK（Selective Acknowledgment），简单来讲就是在快速重传的基础上，返回最近收到的报文段的序列号范围，这样客户端就知道，哪些数据包已经到达服务器了。

来几个简单的示例：

• case 1：第一个包丢失，剩下的 7 个包都被收到了。

  当收到 7 个包的任何一个的时候，接收方会返回一个带 SACK 选项的 ACK，告知发送方自己收到了哪些乱序包。注：Left Edge，Right Edge 就是这些乱序包的左右边界。

              Triggering    ACK      Left Edge   Right Edge              Segment               5000         (lost)              5500         5000     5500       6000              6000         5000     5500       6500              6500         5000     5500       7000              7000         5000     5500       7500              7500         5000     5500       8000              8000         5000     5500       8500              8500         5000     5500       9000 

• case 2：第 2, 4, 6, 8 个数据包丢失。

  • 收到第一个包时，没有乱序的情况，正常回复 ACK。

  • 收到第 3, 5, 7 个包时，由于出现了乱序包，回复带 SACK 的 ACK。

  • 因为这种情况下有很多碎片段，所以相应的 Block 段也有很多组，当然，因为选项字段大小限制， Block 也有上限。

           Triggering  ACK    First Block   2nd Block     3rd Block           Segment            Left   Right  Left   Right  Left   Right                              Edge   Edge   Edge   Edge   Edge   Edge            5000       5500           5500       (lost)           6000       5500    6000   6500           6500       (lost)           7000       5500    7000   7500   6000   6500           7500       (lost)           8000       5500    8000   8500   7000   7500   6000   6500           8500       (lost)

不过 SACK 的规范「RFC2018」有点坑爹，接收方可能会在提供一个 SACK 告诉发送方这些信息后，又「食言」，也就是说，接收方可能把这些（乱序的）数据包删除掉，然后再通知发送方。以下摘自「RFC2018」：

Note that the data receiver is permitted to discard data in its queue that has not been acknowledged to the data sender, even if the data has already been reported in a SACK option. Such discarding of SACKed packets is discouraged, but may be used if the receiver runs out of buffer space.