Loading... # 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 的设计理念 ```mermaid graph LR A[CUBIC 算法] --> B[基于丢包反馈] B --> C[线性系统] C --> D[可叠加性] D --> E[稳定收敛] style A fill:#e1f5ff style E fill:#c8e6c9 ```  CUBIC 的核心特点： - 最小依赖：仅依赖丢包事件 - 丢包不会撒谎：任何行为都无法做到 buffer 溢出而不丢包 - 宁可错杀，但绝不遗漏：对拥塞的反应属反向激励 - 线性系统：具备可叠加性，系统问题可控 ### B. BBR 的设计理念 ```mermaid 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 非线性 ```mermaid 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 的定位 ```mermaid 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 内核的缺省算法，也是说不准的事。但技术选择应该基于理性分析，而非市场宣传或个人偏好。 *** ## 参考资料 1. [BBR 为什么没有替代 CUBIC 成为 Linux 内核缺省算法](https://blog.csdn.net/dog250/article/details/142650492) 2. [Evaluating BBRv2 on the Dropbox Edge Network](https://dropbox.tech/infrastructure/evaluating-bbrv2-on-the-dropbox-edge-network) 最后修改：2026 年 01 月 18 日 © 允许规范转载 赞 如果觉得我的文章对你有用，请随意赞赏