TCP 拥塞控制拾遗

快重传和快恢复的过程？

参考
借用这篇博客的一张图，我觉得这张图画出了很多讲快重传和快恢复的文章中没有讲到的细节。

快重传

快重传的触发是有收到连续3个相同的ACK，就开始进行快重传阶段。
快重传所做的操作就是更新 cwnd 和 ssthresh 的值：

• cwnd = cwnd / 2
• ssthresh = cwnd
  执行完这两个操作之后就开始进入快恢复阶段

快恢复

快恢复要做的操作如下：

• cwnd = ssthres + 3 * MSS
• 重传 duplicated ACKs 指定的数据包
• 如果再收到 duplicated ACKs ，cwnd = cwnd + 1
• 如果收到新的ACK，就令 cwnd = ssthresh ，然后就退出快恢复阶段，进入拥塞避免算法（TCP Reno）

为什么有些快恢复的算法拥塞窗口设置为 ssthresh + 3 MSS？

书上的意思是，因为触发快重传是有3个重复的ACK，这也就表明接收端已经收到了目前发送窗口内的另外3个报文段，这样也就意味着，目前发送窗口内的报文段已经确认有3个报文段被接收端收到了，这样的话，为了能够发送更多的报文段，发送端的发送窗口可以相应的扩大3个报文段。
可是我好像都没有看到有关这种做法所带来的效率提升的分析。

TCP New Reno 相比于 TCP Reno 的改进？

TCP Reno 的问题

正如第一节讲到的快恢复的过程。当接收方收到一个不是之前被重复3次的ACK之后，就退出了快恢复过程，进入拥塞避免算法。那我们来考虑下面这个场景：

网络拥塞情况比较严重，有大量的包在传输过程中丢失。在发送方目前保持着的发送窗口内有多个包丢失，这样的话在收到新的ACK，就结束快恢复。可是这个新的ACK可能是另一个丢失的包的重传请求ACK，这样在重复收到3个同样ACK之后，又会进入快重传和快恢复阶段。

这样的话如果存在大量的丢包，那会多次触发快重传机制，发送窗口会迅速下降，这个效果会跟慢开始的效果差不多。

TCP New Reno 的改进

发送发会记录目前已经发出的最大的序列号，假设在已发出的报文段中只有一个报文段丢失了，这样的话在执行完快恢复之后所获得的第一个非重复ACK，应该是对之前记录的最大已发送报文段的确认。
如果收到的第一个非重复ACK不是发送端记录的最大序列号的确认，那就说明还有其他报文段也在发送过程中丢失了，这样的话就不能立即退出快恢复过程，而应该发送接着发送该ACK所确认的报文段的下一个报文，不用等到连续收到3次同样ACK之后才进行处理。