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:#c8e6c9CUBIC 的核心特点：最小依赖：仅依赖丢包事件丢包不会撒谎：任何行为都无法做到 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:#ffcdd2BBR 的核心特点：主动探测带宽和 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:#ffcdd2CUBIC 源自 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:#e1f5ffBBR 属于特定网络场景的优化算法：在稳定的长肥管道，BBR 无疑是福音在抖动不受控的网络环境比如无线场景，BBR 就不如预期，甚至无法预期五、标准化进程1. BBR 的迭代A. BBRv1用激进的方式应对 buffer 增长只是个 demo能进 Linux 内核但进不了 RFCB. 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 内核的缺省算法，也是说不准的事。但技术选择应该基于理性分析，而非市场宣传或个人偏好。参考资料BBR 为什么没有替代 CUBIC 成为 Linux 内核缺省算法Evaluating BBRv2 on the Dropbox Edge Network