本文主要是介绍bbr 是真不行，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
bbr 作为 mimd 实例如何收敛到公平请看 瓶颈带宽的公平收敛，但这只是公平收敛，并不是 buffer 收敛。
上午跟朋友讨论了一个有趣的问题，感觉有必要揭露一下 bbr 的 buffer 不收敛。若不是有 probertt，多流共享瓶颈链路场景下，无限 buffer 会被无限占领，说实话，仅靠 probebw 状态的 drain 阶段是无法 buffer 收敛的，本质原因说过好多次，只要挤 buffer，总能挤出 bandwidth，drain 掉的仅仅是 “1/4old_maxbwminrtt - 挤出的 bw” 之外的 inflight。
都在下图(这是经典的收敛图，建议掌握)：
话说能不能缩短 probertt 间隔，先看看 bbr 标准 怎么说：
An ProbeRTTInterval of 5 secs is short enough to allow quick convergence if traffic levels or routes change, but long enough so that interactive applications (e.g., Web, remote procedure calls, video chunks) often have natural silences or low-rate periods within the window where the flow’s rate is low enough for long enough to drain its queue in the bottleneck.
根本就没提 buffer，可能根本就没有认识到 bbr 只能靠 probertt 来收缩 buffer。那么缩短 probertt interval 呢？
标准里说了 interactive applications 的事，但大文件或持续流呢？probertt 期间，链路 queue 被 drain 掉了，可 host write buffer 却堆积了。bbr 隐约知道 probertt 状态下 drain 太狠了，严重影响端到端 p99 latency，在 bbr2/3 中将其妥协成了 50% inflight，然而这就无法保证尽力 drain 掉 queue 了。
bbr 开合跳幅度过大但却不协调，maxbw 和 minrtt 两个量正交，根本无法同时测的，它们之间 gap 越大，queue 就倾向于越大。maxbw 取 10-round filter，minrtt 则长达秒级，cwnd = 2 maxbw*minrtt 覆盖的动态范围过大，多亏了 probertt，否则绝对跑飞。
总之，bbr 是真不行，它吸引人的点在于它的高吞吐，显然这是依靠大摆王八拳获得的。bbr 有个结界，想公平收敛又 buffer 收缩，则趋向和 cubic 一致，吞吐自然也就下来了，而追求大吞吐，则必然放弃公平性和 buffer 收缩，靠猛挤就完了。
很多人发现 bbr3，bbr2 的吞吐不如 bbr1，人们升级 bbr 到 bbr3 的动机便不大了。
bbr 还是没有找对操作点，maxbw 和 minrtt 无法同时测得，那就别测了，best_E = max(bw / delay) 才是正确的操作点，它只有一个值。我们发现，当只有一条流的单流独享链路时，它等同于 bbr，无任何代价，不占任何 buffer，但多流共享链路时，best_E 的代价就是 buffer，而既然是 best_E，则 delay 倾向于更小。bbr 试图不付出任何代价收敛到 maxbw/minrtt，只能说是奢望，但在单流场景，它确实可以，因此 bbr 只是个单流算法。
姿势掌握了吗？
浙江温州皮鞋湿，下雨进水不会胖。
这篇关于bbr 是真不行的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
