自 2017 年底 bbr 发布以来，随着媒体的宣讲，各大站点陆续部署 bbr，很多网友不禁问，bbr 这么好，为什么不替代 cubic 成为 linux 的缺省算法。仅仅因为它尚未标准化？这么好的算法又为什么没被标准化？
首先，如何定义 “好”。包括我自己在内的几乎所有人都用过一种错误方法度量 bbr 的 “好”：搭建一跳转发的模拟环境，用 tc 配置丢包，时延，用 iperf 对比 bbr 和 cubic，得到结论，bbr 的吞吐比 cubic 大好多倍，所以 bbr 好。幸运的是，我很快意识到错误并改正，但直到现在很多领域专家(自诩的专家，实际上只是经理)仍在用 tc + iperf 验证 bbr。
通过下面一篇文章可继续领略什么是 “好”：Evaluating BBRv2 on the Dropbox Edge Network
bbr 是个拥塞控制算法，它的部署环境是统计复用的去中心分布式网络，任何一种拥塞控制算法在部署之前都要至少自证两件事：
- 不会引发拥塞崩溃；
- 网络流量公平收敛。
正如你所见，这是最小约束。不必要求一个算法可以解决拥塞，但求不添乱。这很容易理解，如果一个算法没用，自然选择会淘汰它，但一个算法有副作用，便会带来灾难。很遗憾，bbr 一个也证明不了。
bbr 的正确性依赖高精度的准确的对 bandwidth 和 rtt 的测量，而高精度取决于实现，准确性则依赖网络本身。我频繁啰嗦的那句 “统计复用网络本身不可精确测量” 不管你信不信它就是无法精确测量，异构性只是最不重要的方面，不可测量的核心来自于统计律本身，正如你无法把握某个空气分子的动量但却能测量一坨空气的温度一样。
统计律只能按统计的方法来，而任何统计方法都有滞后性，对反馈响应之前的这段时间可能就是灾难酝酿的时间，而随后的响应并不覆盖灾难，系统可能滑向不稳定状态，这种不稳定状态包括拥塞崩溃。不管 bbr 官方的论述还是我个人所做的仿真，大前提都是网络可精确测量，这显然把最难的部分绕过去了。
反过来看看 cubic。cubic 无疑是最小依赖的，仅依赖丢包事件。如范雅各布森所说，任何主动的显式机制都可能被误用，但丢包不会。如果有一种显式拥塞通知机制，但它故障了，发生拥塞时并没发出通知，网络就可能崩溃，然而丢包就是丢包，任何行为都无法做到 buffer 溢出而不丢包，你能谎称丢包，但结果还是收敛。
cubic 的误判对拥塞属反向激励，对拥塞的反应 “宁可错杀，但绝不遗漏”，但 bbr 对带宽的过估或低估带来的结果将不可控。看一个 bbr 双流相图：
如图所示，请问 4 怎么画？4 的位置取决于你对系统的测量结果。为什么说误估导致的行为不可控？
bbr 本身是个非线性系统，不能用线性的思维去简单表达，换句话说，这件事本身就凌乱复杂，没有简单到能让人快速画线获得直感的方法。而衍自 reno 的 cubic 则是线性的，线性可叠加性让系统问题变得和单体问题一样可控，不管是同步流还是异步流。
大道至简，最小依赖，少即是多，这是 cubic 作为缺省算法的理由：
- 缺省算法不一定甚至一定不是性能最高的，但一定是普适不挑环境的；
- 缺省算法的公平性一定是可自证的，无论与自身还是与异构流量共存；
- 缺省算法的收敛速度一定是可预期的，线性系统最符合这个期望；
- 缺省算法一定是稳定的，没有任何正反馈可将系统带到崩溃状态；
- 缺省算法一定经历了广泛使用和长期验证，具备设备兼容性；
- 缺省算法一定是保守的。
bbr 属于特定网络场景的优化算法，如果在稳定的长肥管道，bbr 无疑是福音，但在抖动不受控的网络环境比如无线场景，bbr 就不如预期，甚至无法预期。
bbr 属于 1988 算法后的一个新路子，为应对 buffer 增长给出的负向反馈。bbr1 首先用激进的方式应对，它只是个 demo，能进 linux 内核但进不了 rfc，bbr2 开始考虑公平性和保守性，只要这样才会使 bbr 具备普遍性而被标准化，但迭代到 bbr3 的状态依然停留在 draft BBR Congestion Control。
虽然 bbr 在某些情况下表现优异，它没有取代 cubic 的原因主要是在于标准化，稳定性，成熟度，兼容性，以及网络环境的多样性等因素。随着 bbr 的发展和进一步的优化，可能有机会在更多系统中被采用。
而在 l4s 已被标准化的今天，bbr 可能真的只是一个引子。谁说 aimd 不能做高带宽低时延，配合 ecn 就行，aimd + ecn 是多么的简单，线性可控。
但 linux 内核早被各厂经理污染，妹忒内儿卷客大行其道，如果哪天来自某大厂的经理妹忒内儿力排众议非要把 bbr 设置为 linux 内核的缺省算法，也是说不准的事。
浙江温州皮鞋湿，下雨进水不会胖。
扫一扫
578
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
