重传的讲究

目的

发送方的发送窗口是受接收方的接收窗口和网络的影响，其中限制更严的因素起决定作用。接收窗口的影响方式非常简单，只要在包里用“Win=”告知对方即可，而网络的影响方式较为复杂，本节需要了解网络对发送窗口的影响方式。掌握增大拥塞窗口的两种形式——慢启动和拥塞避免。掌握重传的两种方式——超时重传和快速重传，以及它们对拥塞窗口的影响。

原理

网络之所以能限制发送窗口，是因为它一口气收到太多数据时就会拥塞。拥塞的结果是丢包，这是发送方最忌惮的。能导致网络拥塞的数据量称为拥塞点，发送方希望把发送窗口控制在拥塞点以下，这样就能避免拥塞了。但连网络设备都不知道自己的拥塞点，针对这种情况，有以下两种方案：

• 方案1. 发送方知道自己的网卡带宽，能否以此推测该连接的拥塞点？

  不能。因为发送方和接收方之间还有路由器和交换机，其中任何一个设备都可能是瓶颈，而且网络带宽是多个连接共享的，其它连接也会占用一定带宽。

• 方案2. 逐次增加发送量，直到网络发生拥塞，这样得到的最大发送量能否定为该连接的拥塞点？

  这是一个好方法，但没那么简单。拥塞点是一个随时改变的动态值，之前试探出的拥塞点不能代表未来。

遗憾的是，目前还没有一个完美的方案。幸好经过几代人的努力，有了一个最靠谱的策略。这个策略是在发送方维护一个虚拟的拥塞窗口，并利用各种算法使它尽可能接近真实的拥塞点。网络对发送窗口的限制，就是通过拥塞窗口实现的，拥塞窗口的维护过程如下：

• 连接刚刚建立的时候，发送方为避免遭遇拥塞，会把拥塞窗口的初始值定得很小。 RFC的建议是2~4个 MSS，具体视MSS的大小而定。
• 如果发出去的包都得到确认，表明还没有到拥塞点，可以增大拥塞窗口。由于这个阶段发生拥塞的概率很低，所以增速可以快一些。RFC建议的算法是每收到n个确认，可以把拥塞窗口增加n个MSS。比如发了2个包之后收到2个确认，拥塞窗口就增大到2+2=4，接下来是4+4=8，8+8=16······这个过程增速很快，但是由于基数低，传输速度比较慢，所以称为慢启动过程。

• 慢启动过程持续一段时间后，拥塞窗口达到一个较大的值。这时候传输速率较快，触碰拥塞点的概率也大，所以不能采用翻倍的慢启动算法，而是缓慢一点，每次增加1个MSS。比如发了16个包后全部确认了，拥塞窗口就增加到16+1=17，接下来是17+1=18，18+1=19······这个过程称为拥塞避免。从慢启动过渡到拥塞避免的临界窗口值很有讲究。如果之前发生过拥塞，就以该拥塞点值的一半作为临界窗口值。如果从来没有拥塞过就可以取相对较大的值，甚至和最大接收窗口相等。全过程可以用图1表示。

  
  image.png

拥塞之后，对发送方来说，就是发出去的包不像往常一样得到确认了。不过得不到确认也可能是网络延迟所致，所以发送方需要等待一小段时间后再判断。假如迟迟收不到确认，就认定包已经丢失，只能重传了，这个过程称为超时重传，发出原始包到重传该包的等待时间称为 RTO。

为了不给刚发生拥塞的网络雪上加霜，重传之后的拥塞窗口需要及时调整，RFC建议把拥塞窗口降到1个MSS，然后再次进入慢启动过程。这一次的临界窗口值就有参考依据了。Richard Stevens在《TCP/IP Illustrated》中把临界窗口值定为上次发生拥塞时的发送窗口的一半。而RFC 5681则认为应该是发生拥塞时没被确认的数据量的一半，但不能小于2个MSS。比如发出了19个包，但只有三个包收到确认，那么临界窗口值就被定为19-3=16个包携带的数据量的一半。图2显示了发生超时重传时拥塞窗口的变化。

image.png

可见超时重传对传输性能有严重影响，一是在RTO阶段不能传数据，相当于浪费了一段时间；二是拥塞窗口急剧减小，相当于接下来传得慢多了。即便是万分之一的超时重传对性能的影响也非同小可。

有时候拥塞很轻微，只有少量的包丢失，还有些偶然因素如校验码不对，会导致单个丢包。这两种丢包症状和严重拥塞不一样，因为后续有包能正常到达。当后续的包到达接收方时，接收方会发现其Seq号比期望的大，所以它每收到一个包就Ack一个期望的Seq号，以此提醒发送方重传。当发送方收到3个或以上重复确认时，就意识到相应的包丢失了，从而立即重传它。这个过程称为快速重传，因为它不像超时重传那样需要等待一段时间。

发生快速重传后，并不需要像发生超时重传那样处理拥塞窗口，因为后续的包都到达了，说明网络没有严重拥塞，接下来传慢一点就可以了。RFC 5681的建议是，将临界窗口值设为发生拥塞时还没被确认的数据量的一半，但不能小于2个MSS，然后将拥塞窗口设置为临界窗口值加3个MSS，继续保留在拥塞避免阶段。这个过程称为快速恢复，其拥塞窗口的变化大概可用图3表示。

image.png

[步骤]¶

注意：此实验数据包存放在桌面【ppa3ecaptures_updated】压缩文件夹中。本实验主要是对数据包重传方法讲解，具体操作可参考实验中的方法。

先解压桌面上的【ppa3ecaptures_updated.tar】压缩包，打开wireshark,点击【文件】->选择【ppa3ecaptures_updated】文件夹下【ppa3ecaptures】文件夹中的【activeosfingerprinting.pcapng】文件进行抓包。

在Wireshark的抓包结果中查看重传情况：首先单击菜单栏中的“分析（Analyze）”，选择“专家信息（Expert Info Composite）”，在弹出的对话框中的Severity列找到“Note”，Summary中的信息为“This frame is a (suspected) retransmission”的即为重传包的记录。点开左侧的三角符号还能看到具体是哪些包发生了重传，如图4所示。点击具体的重传记录可以快速在结果中定位该条记录。

image.png

图5是触发快速重传的例子，4791号包是IP地址为123.125.23.172的服务器向IP地址为192.168.1.109的客户发送的包，其序列号Seq=80000。但注意上一次客户向服务器发送的4790号包，其确认号Ack=78796，说明Seq=78796的包丢失了，因此到达客户的三个包：4791、4793和4795连续触发了3个Ack=78796。于是服务器意识到丢包了，在4800号包快速重传了Seq=78796。图中的“TCP Previous segment not captured”表示这个包的Seq号大于前一个包的Seq+Len，即这个包前缺失了数据，且在目前的网络包中都找不到。“TCP Dup ACK No.#n”表示收到的Seq号比期望的Ack号大，即数据段丢失，其中No.是重复确认的Ack号的包号，n代表重传次数。当发送方收到3个或以上相同的重传确认时，就会触发快速重传，“TCP Fast Retransmission”即为快速重传的标志。

image.png

规定凑满3个是因为网络包有时会有乱序，乱序的包一样会触发重复的Ack，但是为了乱序而重传没有必要。由于一般乱序的距离不会相差太大，所以限定成3个或以上可以在很大程度上避免因乱序而触发快速重传。图6是乱序触发的重复Ack，即4853号包。但仅触发了一次重复的Ack，客户就收到了迟到的4854号包，“TCP Out-Of-Order”表示这个包的Seq号小于前一个包的Seq号，此时Wireshark会认为是乱序。4855号包的Ack号等于4852号包的Seq+Len=74153，证明缺失的包已经到达了，因此没有触发快速重传。

image.png

更为复杂的情况是，很多时候丢的包不止一个。比如1~8号包中，2号和3号包丢失，但1、4、5、6、7和8号都到达了接收方并触发Ack=2。对于发送方来说，只能通过Ack=2知道2号包丢失了，但并不知道还有那些包丢失，在重传2号包后，接下来该传哪一个呢？

方案1. 把3~8号6个包都重传一遍。这个方案简单直接，但丢一个包的后果就是多个包被重传，效率较低。
方案2. 接收方收到重传的2号包之后，回复一个Ack=3，因此发送方可以推断出3号包也丢了，就会把3号也重传一遍。当接收方收到重传的3号包后，因为丢的包都已经补齐了，所以回复一个Ack=9，这样发送方就可以传新的包了。这个方案称为 NewReno，由RFC 2582和RFC 3782定义。NewReno在这个例子中看上去很理想，但当丢包量很大的时候，就需要花费多个往返时延（RTT）来重传所有丢失的包。
方案3. 接收方在发送Ack=2的时候，顺便把收到的包号告诉发送方。所以这些Ack包应该是这样的：

收到4号包时，告诉发送方：“已收到4号，请给我2号。”

收到5号包时，告诉发送方：“已收到4、5号，请给我2号。”

收到6号包时，告诉发送方：“已收到4、5、6号，请给我2号。”

······

这样发送方对丢包细节了如指掌，在快速重传2号包之后，它可以接着传3号，然后再传9号包。这个非常直观的方案称为 SACK ，由RFC 2018定义。图7是上个快速重传的例子中，第三个重传包的SACK实例。按照图7中的路径即可找到SACK记录。把“SACK 80000-83072”和“Ack=78976”两个条件综合起来，发送方就知道8000083072已经收到了，而前面的7897679999反而没有收到。

image.png

• 总结

  本节的信息量有点大，有些部分一时不理解也无妨，记住导出的以下结论也是很有用的。

• 没有拥塞时，发送窗口越大，性能越好。所以在带宽没有限制的条件下，应该尽量增大接受窗口，比如启用Scale Option，Windows上可参考 KB 224829。

• 如果经常发生拥塞，那限制发送窗口反而能提高性能，因为即便万分之一的重传对性能的影响都很大。在很多操作系统上可以通过限制接受窗口的方法来减小发送窗口，Windows上同样可以参考 KB 224829。

• 超时重传对性能影响最大，因为它有一段时间（RTO）没有传输任何数据，而且拥塞窗口会被设成一个MSS，所以要尽量避免超时重传。

• 快速重传对性能的影响小一些，因为它没有等待时间，而且拥塞窗口减小的幅度没那么大。

• SACK和NewReno有利于提高重传效率，进而提高传输性能。

• 丢包对极小文件的影响比大文件严重。因为读写一个小文件需要的包数很少，所以丢包时往往凑不满3个重复的Ack，只能等待超时重传了。而大文件有较大可能触发快速重传。