BBR 与 CUBIC 拥塞控制算法深度分析
一、概述
1. 背景介绍
自 2017 年底 BBR（Bottleneck Bandwidth and Round-trip propagation time）发布以来，随着媒体的宣讲，各大站点陆续部署 BBR。很多网友不禁问，BBR 这么好，为什么不替代 CUBIC 成为 Linux 的缺省算法。仅仅因为它尚未标准化，这么好的算法又为什么没被标准化？
2. 核心问题
本文将从技术原理、系统稳定性、公平性、适用场景等多个维度，深入分析 BBR 为什么没有替代 CUBIC 成为 Linux 内核缺省算法。
二、算法对比分析
1. 性能度量的误区
A. 错误的测试方法
包括作者在内的几乎所有人都用过一种错误方法度量 BBR 的"好"：搭建一跳转发的模拟环境，用 tc 配置丢包、时延，用 iperf 对比 BBR 和 CUBIC，得到结论：BBR 的吞吐比 CUBIC 大好多倍，所以 BBR 好。
B. 测试的局限性
这种测试方法存在严重问题：
- 测试环境过于理想化
- 未考虑真实网络环境的复杂性
- 忽略了统计复用网络的基本特性
C. 正确的评价标准
根据 Dropbox 的实际部署经验，一个拥塞控制算法在部署之前，至少要自证两件事：
- 不会引发拥塞崩溃
- 网络流量公平收敛
2. 算法设计哲学差异
A. CUBIC 的设计理念
graph LR
A[CUBIC 算法] --> B[基于丢包反馈]
B --> C[线性系统]
C --> D[可叠加性]
D --> E[稳定收敛]
style A fill:#e1f5ff
style E fill:#c8e6c9
CUBIC 的核心特点：
- 最小依赖：仅依赖丢包事件
- 丢包不会撒谎：任何行为都无法做到 buffer 溢出而不丢包
- 宁可错杀，但绝不遗漏：对拥塞的反应属反向激励
- 线性系统：具备可叠加性，系统问题可控
B. BBR 的设计理念
graph LR
A[BBR 算法] --> B[主动测量带宽]
B --> C[测量 RTT]
C --> D[模型估算]
D --> E[调整发送速率]
A --> F[非线性系统]
F --> G[复杂行为]
G --> H[不可预测性]
style A fill:#fff3e0
style H fill:#ffcdd2
BBR 的核心特点：
- 主动探测带宽和 RTT
- 依赖高精度的准确测量
- 非线性系统，行为复杂
- 对测量误差敏感
三、深入分析
1. 测量精度的陷阱
A. 统计律的本质
统计复用网络本身不可精确测量。这不仅仅是网络异构性的问题，更深层的原因来自于统计律本身。正如你无法把握某个空气分子的动量，但却能测量一坨空气的温度一样。
B. 测量的滞后性
统计方法都有滞后性，对反馈响应之前的这段时间可能就是灾难酝酿的时间。而随后的响应并不覆盖灾难，系统可能滑向不稳定状态，包括拥塞崩溃。
C. BBR 的依赖性
BBR 的正确性依赖高精度的准确的对 bandwidth 和 rtt 的测量，而：
- 高精度取决于实现
- 准确性则依赖网络本身
2. 系统稳定性分析
A. 线性 vs 非线性
graph TB
subgraph 线性系统_CUBIC
A1[流 1] --> C[共享瓶颈]
A2[流 2] --> C
A3[流 N] --> C
C --> D[稳定收敛]
D --> E[公平分配]
end
subgraph 非线性系统_BBR
B1[流 1] --> F[复杂交互]
B2[流 2] --> F
B3[流 N] --> F
F --> G{不确定状态}
G --> H[可能发散]
G --> I[可能收敛]
end
style D fill:#c8e6c9
style G fill:#ffcdd2
CUBIC 源自 Reno，是线性的，线性可叠加性让系统问题变得和单体问题一样可控。不管是同步流还是异步流，系统行为可预测。
BBR 本身是个非线性系统，不能用线性的思维去简单表达。换句话说，这件事本身就凌乱复杂，没有简单到能让人快速画线获得直感的方法。
B. 双流相图分析
文章中的 BBR 双流相图显示，系统状态空间的边界难以确定。某个状态的可达性取决于你对系统的测量结果，而误估导致的行为不可控。
3. 公平性问题
A. CUBIC 的公平性
- 与自身共存：公平收敛
- 与异构流量共存：表现可预期
- 收敛速度：可预期
B. BBR 的公平性挑战
BBR 一个也证明不了：
- 无法自证不会引发拥塞崩溃
- 无法自证网络流量公平收敛
- 在某些场景下可能过度抢占带宽
- 在某些场景下可能被 CUBIC 压制
四、缺省算法的选择标准
1. 设计原则
大道至简，最小依赖，少即是多，这是 CUBIC 作为缺省算法的理由。
A. 普适性
缺省算法不一定甚至一定不是性能最高的，但一定是普适不挑环境的。
B. 公平性
缺省算法的公平性一定是可自证的，无论与自身还是与异构流量共存。
C. 可预期性
缺省算法的收敛速度一定是可预期的，线性系统最符合这个期望。
D. 稳定性
缺省算法一定是稳定的，没有任何正反馈可将系统带到崩溃状态。
E. 兼容性
缺省算法一定经历了广泛使用和长期验证，具备设备兼容性。
F. 保守性
缺省算法一定是保守的。
2. BBR 的定位
graph LR
A[BBR 算法] --> B{网络环境判断}
B -->|稳定长肥管道| C[表现优异]
B -->|抖动不受控| D[不如预期]
B -->|无线场景| E[甚至无法预期]
C --> F[特定场景优化]
D --> F
E --> F
style C fill:#c8e6c9
style D fill:#fff9c4
style E fill:#ffcdd2
style F fill:#e1f5ff
BBR 属于特定网络场景的优化算法：
- 在稳定的长肥管道，BBR 无疑是福音
- 在抖动不受控的网络环境比如无线场景，BBR 就不如预期，甚至无法预期
五、标准化进程
1. BBR 的迭代
A. BBRv1
- 用激进的方式应对 buffer 增长
- 只是个 demo
- 能进 Linux 内核但进不了 RFC
B. BBRv2
- 开始考虑公平性和保守性
- 只有这样才会使 BBR 具备普遍性而被标准化
C. BBRv3
- 依然停留在 draft 阶段
- 尚未被正式标准化
2. L4S 的标准化
在 L4S（Low Latency Low Loss Scalable Throughput）已被标准化的今天，BBR 可能真的只是一个引子。
谁说 AIMD（Additive Increase Multiplicative Decrease）不能做高带宽低时延，配合 ECN（Explicit Congestion Notification）就行。AIMD + ECN 是多么的简单，线性可控。
六、实践启示
1. 测试与验证
A. 避免 tc + iperf 的简单测试
不要使用过于简化的测试方法来评估算法性能，这会得出误导性的结论。
B. 参考实际部署经验
参考如 Dropbox 等公司在实际生产环境中的部署经验，了解算法在真实网络环境中的表现。
C. 多维度评估
从稳定性、公平性、兼容性、适用场景等多个维度综合评估算法。
2. 选择建议
A. 缺省使用 CUBIC
对于大多数场景，继续使用 CUBIC 作为缺省算法是明智的选择。
B. 特定场景使用 BBR
在以下场景可以考虑使用 BBR：
- 稳定的长肥管道网络
- 高带宽长延迟网络
- 丢包率较高的网络
- 数据中心内部网络
C. 谨慎评估
在以下场景需要谨慎评估 BBR 的效果：
- 无线网络环境
- 抖动较大的网络
- 多种拥塞控制算法共存的环境
- 对公平性要求较高的环境
七、总结
1. 核心观点
虽然 BBR 在某些情况下表现优异，它没有取代 CUBIC 的原因主要包括：
A. 标准化
BBR 尚未完成标准化进程，仍处于 draft 阶段。
B. 稳定性
BBR 作为非线性系统，其稳定性难以保证，可能引发拥塞崩溃。
C. 公平性
BBR 无法自证在与自身或异构流量共存时的公平性。
D. 成熟度
BBR 缺乏像 CUBIC 那样广泛的实际部署验证。
E. 兼容性
BBR 在某些网络环境下表现不佳，甚至无法预期。
F. 网络环境多样性
真实网络环境复杂多变，BBR 无法像 CUBIC 那样普适。
2. 未来展望
随着 BBR 的发展和进一步的优化，可能有机会在更多系统中被采用。但作为缺省算法，CUBIC 的地位在可预见的未来难以被撼动。
L4S 的标准化为高带宽低时延传输提供了另一种可能，AIMD + ECN 的方案展示了传统算法的潜力。
正如作者所言，如果哪天来自某大厂的经理力排众议非要把 BBR 设置为 Linux 内核的缺省算法，也是说不准的事。但技术选择应该基于理性分析，而非市场宣传或个人偏好。