所谓快速重传时相比超时重传而言的 , 重发等待时间会降低并且后续尽量避免慢启动 , 来保证性能损失在最小的程度 , 如图所示:

文章插图
快速重传和超时重传的区别在于cwnd在发生拥塞时的取值 , 超时重传会将cwnd修改为最初的值 , 也就是慢启动的值 , 快速重传将cwnd减半 , 二者都将ssthresh设置为cwnd的一半 。
从二者的区别可以看到 , 快速重传更加主动 , 有利于保证链路的传输性能 , 但是有研究表明3个ACK的机制同样存在问题 , 本文就不做深入阐述了 , 感兴趣的读者可以自主查阅 。
快速重传是基于对网络状况没有那么糟糕的假设 , 因此在实际网络确实还算好的时候 , 快速重传还是很有用的 , 在很差的网络环境很多算法都很难保证效率的 。
- 快速恢复
4.5 TCP算法版本和拥塞控制实际上TCP算法有很多版本 , 每个版本存在一些差异 , 在这里简单看一下维基百科的介绍:
- 算法命名规则
- TCP Tahoe 和TCP Reno
这两个算法代号取自太浩湖Lake Tahoe和里诺市 , 两者算法大致一致 , 对于丢包事件判断都是以重传超时retransmission timeout和重复确认为条件 , 但是对于重复确认的处理两者有所不同 , 对于超时重传RTO情况两个算法都是将拥塞窗口降为1个MSS , 然后进入慢启动阶段 。
TCP Tahoe算法:如果收到三次重复确认即第四次收到相同确认号的分段确认 , 并且分段对应包无负载分段和无改变接收窗口的话 , Tahoe算法则进入快速重传 , 将慢启动阈值改为当前拥塞窗口的一半 , 将拥塞窗口降为1个MSS , 并重新进入慢启动阶段 。
TCP Reno算法:如果收到三次重复确认 , Reno算法则进入快速重传只将拥塞窗口减半来跳过慢启动阶段 , 将慢启动阈值设为当前新的拥塞窗口值 , 进入一个称为快速恢复的新设计阶段 。TCP New Reno
TCP New Reno是对TCP Reno中快速恢复阶段的重传进行改善的一种改进算法 , New Reno在低错误率时运行效率和选择确认SACK相当 , 在高错误率仍优于Reno 。
- TCP BIC 和TCP CUBIC
TCP BIC旨在优化高速高延迟网络的拥塞控制 , 其拥塞窗口算法使用二分搜索算法尝试找到能长时间保持拥塞窗口最大值 , linux内核在2.6.8至2.6.18使用该算法作为默认TCP拥塞算法 。
CUBIC则是比BIC更温和和系统化的分支版本 , 其使用三次函数代替二分算法作为其拥塞窗口算法 , 并且使用函数拐点作为拥塞窗口的设置值 , Linux内核在2.6.19后使用该算法作为默认TCP拥塞算法 。
- TCP PRR
TCP PRR是旨在恢复期间提高发送数据的准确性 , 该算法确保恢复后的拥塞窗口大小尽可能接近慢启动阈值 。在google进行的测试中 , 能将平均延迟降低3~10%恢复超时减少5% , PRR算法后作为Linux内核3.2版本默认拥塞算法 。TCP BBR
TCP BBR是由Google设计于2016年发布的拥塞算法 , 该算法认为随着网络接口控制器逐渐进入千兆速度时 , 分组丢失不应该被认为是识别拥塞的主要决定因素 , 所以基于模型的拥塞控制算法能有更高的吞吐量和更低的延迟 , 可以用BBR来替代其他流行的拥塞算法 。
Google在YouTube上应用该算法 , 将全球平均的YouTube网络吞吐量提高了4% , BBR之后移植入Linux内核4.9版本 。其中比较有名的Vegas算法是大约在1995年由亚利桑那大学的研究人员拉里·彼得森和劳伦斯·布拉科夫提出 , 这个新的TCP拥塞算法以内华达州最大的城市拉斯维加斯命名 , 后成为TCP Vegas算法 。
文档对Vegas算法和New Reno做了一些对比 , 我们从直观图形上可以看到Vegas算法更加平滑 , 相反New Reno则表现出了较大的波动呈锯齿状 , 如图所示:
推荐阅读
- 轻松学习http知识让枯燥的内容变得生动有趣:TCP/IP四层模型
- Java中的BigDecimal,你真的会用吗?最强指南
- 为何视频流/网游大都使用UDP协议,而不用TCP协议?
- TCP粘包、拆包与解决方案
- 地球最强悍的生物 超级地球上有生命
- ICMP ARP协议 TCP&UDP协议相关介绍,两分钟快速掌握
- TCP粘包的解决方案
- TCP 拥塞避免算法
- 看一遍忘一遍的网络七层模型与TCP/UDP,重新总结出来
- 世界上最烈的啤酒排名是什么?
