为什么需要 BBR 算法
我们将传统的拥塞控制算法称为基于“丢包设计”的，代表为 TCP CUBIC 和 Reno。
TCP Reno：就是我们在教科书上最常见的拥塞控制算法，即线性增、乘性减。为了方便后文展开，先快速温习一边：
- 窗口增长： 线性的。每个 RTT（往返时间）窗口只增加 1 个 MSS（最大报文段长度）。
- 丢包反应： 发现丢包后，拥塞窗口 cwnd 直接减半。
- 致命弱点： 在高带宽、高延迟网络中效率极低。例如，在 1Gbps 的链路上，如果发生一次丢包，Reno 可能需要几十分钟才能重新填满带宽。
- RTT 公平性差： RTT 短的连接窗口增长快，会抢走 RTT 长的连接的带宽。
TCP CUBIC (Linux 默认)：
为了解决 Reno 在高带宽、高延迟网络表现不佳的问题，CUBIC 的窗口增长遵循一个三次函数：
- 凹函数阶段： 丢包后窗口减小，然后快速回升到上次丢包时的位置。越接近上次丢包点（$W_{max}$），增长越慢。
- 平台期： 在 $W_{max}$ 附近停留较长时间，稳定探测网络容量。
- 凸函数阶段： 如果一直没丢包，它会加速向上探测，寻找新的网络天花板。
同时，其丢包时 cwnd 只变为原来的 70%，比 Reno 稍微激进一些。
但是随着技术进步，现代网络基础设施发生了非常大的变化，最重要的就是随着内存越来越便宜（在今天，由于 AI 浪潮，内存在翻倍的涨价），设备的缓冲区越来越大。
这就产生了一个有趣的现象：如果链路速度不够快，大缓冲区使得数据的丢包概率减小，转而积压在链路的缓冲区中。
接着就是关键问题：传统的基于丢包的算法无法及时响应这种情况，即便数据实际上已经开始堆积，但算法依旧尝试发送大量数据，同时使得估算的RTT极大，因为数据需要很久才从缓冲区中发射出来。这意味着它们本质上倾向于让网络处于高延迟状态。
BBR 模型
BBR 提出了两个关键参数：
- BtlBw (Bottleneck Bandwidth): 瓶颈带宽，即整条链路中最小那一段的带宽。
- RTprop (Round-trip propagation time): 往返传输时间
由此计算得到理想发送速率 BtlBw，$BtlBw=BtlBw * RTprop$。
当然，过往的经验告诉我们，想准确的测量上述两个关键参数以计算发送速率是非常困难的，BBR 最复杂的部分也在这。
具体来说，BBR通过在运行时不断地主动测量和建模，来估计BtlBw和RTprop。
- 测量 RTprop：BBR会周期性地进入ProbeRTT状态，主动降低发送速率，排空网络管道中的排队数据，此时测得的RTT最小值就被认为是当前的RTprop。
- 测量 BtlBw：BBR通过观察发送速率和数据包交付速率（delivery rate）的关系来测量。当发送速率增加，交付速率也随之增加时，说明还没达到瓶颈。当发送速率继续增加，但交付速率不再增加时，此时的交付速率就被认为是BtlBw。
BBR的状态机：
- Startup (启动)：类似慢启动，指数级快速增加发送速率，以快速找到
BtlBw。- Drain (排空)：找到
BtlBw后，发送速率会短暂超过瓶颈，导致产生少量排队。Drain状态会降低发送速率，排空这些队列。- ProbeBW (探测带宽)：这是BBR大部分时间所处的状态。它以一个8个RTT为周期的模式工作，交替使用不同的pacing gain（发送速率增益因子）：
1.25：在1个RTT内，以1.25 * BtlBw的速率发送，主动探测是否有更高带宽。0.75：在下1个RTT内，以0.75 * BtlBw的速率发送，主动排空上一步可能产生的队列。1.0：在剩下的6个RTT内，以1.0 * BtlBw的速率稳定发送，充分利用带宽。- ProbeRTT (探测时延)：当
RTprop一段时间（默认10秒）没有更新时，BBR会进入此状态，将发送窗口降至一个很小的值（4个MSS），持续200ms，以测量真实的物理延迟。
这种设计完美吗？其实不是，关键在于 ProbeRTT 是骤降发送速率导致了两个问题：
- 对其他基于丢包的算法非常不公平：当 BBR 测量 ProbeRTT 时，传统算法比如 CUBIC 会发现丢包概率下降从而快速增加 cwnd。但 BBR ProbeRTT 测试结束后，又开始快速发送数据，CUBIC 又开始面对丢包事件从而降低速率。结果是，CUBIC 每次试图扩张都会被 BBR 打回去，导致 CUBIC 长期“饥饿”，而 BBR 独占带宽。
- 探测 ProbeRTT 对 BBR 自身也意味着存在一个速率骤降的问题，对于游戏等高频系统不可接受。
为此，BBR v2 重新分析丢包事件，如果现在的丢包率超过了某个阈值，它就会认为“模型预测失效”或“严重拥堵”，主动降低速度。