拥塞算法CUBIC和BBR

经典的 TCP 拥塞控制算法

网络层 TCP 协议提供的主要能力之一就是拥塞控制。TCP 协议的拥塞控制主要有以下两种算法组成:

  • TCP Tahoe(现在已废弃):
    • 慢开始(慢启动)
    • 拥塞避免
    • 快重传
  • TCP Reno:
    • 慢开始(慢启动)
    • 拥塞避免
    • 快重传
    • 快恢复

拥塞算法整体过程示意图

慢开始

  • cwnd 指数增大:慢开始的窗口是指数增长的,慢开始中的“慢”字却是有点误导性,慢更多指的是开始的点是慢的,阈值为 2,cwind=1
  • 到达阈值后进入拥塞避免阶段:到达阈值后进入拥塞避免阶段

慢启动缺点

不适用于短连接的场景:慢启动对于一些短暂的连接性能并不好,一些较旧的网页浏览器会建立大量连续的短暂链接,通过快速开启和关闭链接来请求获得文件,这使得大多数链接处于慢启动模式,导致网页响应时间差。所以现在新的网页浏览器,会通过向特殊的服务器,开启一条链接来请求获得全部的文件,而避免频繁新建大量短暂链接。不过这样对一些非请求网站所提供的服务,例如广告跟踪脚本、社交分享功能脚本、网络分析脚本等,并不适用

tips: 注意流控和拥塞控制的差别。流控强调发送和接收方之间的流量控制。过快的发送可能导致接收方来不及处理。拥塞控制对象是整个网络,通过配置、流量控制、准入控制来避免网络中存在太多数据包降低了网络的性能。

拥塞避免

  • 线增积减(AIMD): 这个概念是拥塞避免阶段针对 cwnd 大小行为的说明。cwnd 线性增加,乘法减小。乘法减小具体和拥塞算法相关。tahoe 中 cwnd=1,reno 中 cwnd 直接等于减半后的 ssthresh

快速重传

  • 接收方立即确认:接收方不是等下一次发送数据捎带 ack,而是立即返回确认
  • 发送方立即重传:不等超时重传计时器,收到 3 个重复确认后立即重传丢失的数据包
  • 重传时 ssthresh 减半
  • 重传后 tahoe 实现中 cwind=1 进入慢开始
  • 重传后 reno 实现中 cwind=ssthresh 直接进入拥塞避免

快恢复

  • reno 实现中重传后直接进入拥塞避免称为快恢复

通过问题加深理解

有了快重传 RTO 还奏效吗?

答:奏效,满足 RTO 时间,两种拥塞算法都是将拥塞窗口降为 1 个 MSS,然后进入慢启动阶段。这也可以理解,满足 RTO 说明可能真的比较网络堵塞严重,没必要再执行快恢复了。快恢复对于偶尔网络抖动导致的丢包具有比较好的容错

参考资料