本文主要是介绍bbr 的 “最优操作点”，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
最近做一组测试，我复现了一组结果准备阐释另一个事。先看这个测试结果：
常规的一个 wrk2(expected_latency_timing 改为 actual_latency_timing 计数) 压 nginx 的测试，调整 -R 参数，Req/sec 同步增加，当 Req/sec 不再增加，nginx CPU 已 100%，处理饱和，在此之前 latency 几乎不变，在此之后，latency 剧烈增大。于是 Req/sec 开始不再增加的 R 值就是 “nginx 最优操作点”，在该点，Request 的处理具有最小时延，总吞吐最大。
可这是对 nginx 来说的，对 wrk，我是靠不断调 -R，肉眼观察找到这个 -R 值的，设它为 r。如果有 n 个互不可见的 wrk 在不同地方同时压 nginx，这个 r = r0 + r1 + … rn 将怎样在所有 wrk 间分配，每一个 wrk 实例有办法找到自己的 r_i 吗？如何确保 r 的分配对所有 wrk 实例是公平的？ 这个问题的解就是 bbr 问题的解。
看一个更现实的例子。
如何判定找到一家好吃的饭店？很多人说看哪家饭店排队多。但这是非常矛盾的，为了一口好吃的，难道非要付出排队的代价吗？如果大家都想吃好吃的却又都不想排队，有没有什么办法找到一家不用排队，但大堂里只剩下一个位置的饭店呢？
事实上满座率 = 100%，等待率 = 0 的饭店才是最好的饭店。但更为现实的场景是，几乎所有饭店，要么外面排着等待就餐的长队，要么里面服务员比顾客人多，几千年人们都没有办法找到工作在 “最佳操作点” 的饭店。
把范围缩小到公司食堂范围，即使经理已经给出了针对不同部门的不同 “建议就餐时间”，当某个特定的人去吃饭时依然会看到有些档口排着长队，有些档口门可罗雀。除非经理为每个特定个人安排特定就餐时间，但这会增加经理成本，人员稍有变动就要重新来一遍，如此成本加持，“最佳操作点” 就不再最佳了。
除非你知道其它所有人的策略，否则对于单独个人，如果找不到 “最佳操作点”，不如说它根本不存在。
bbr 基于单流测速的一厢情愿方案注定只是一意孤行，在现实中各个领域，人们到处都在试图解决相同的问题，人们试图在统计的世界中寻找精确的解，但几千年都没找到。
人们憧憬 “刚刚好”，但现实给予的要么太多，要么不够。
很难找到一辆只剩下一个座位的公交车，如果你找到了并且坐到了那个仅剩的位置，下一个上来的就大概率要站着了，如果到达某站点，可能一下下去很多人，留出很多空位而不是恰好一个。
不存在 “刚刚好” 的期望会导致人们很多误判，而误判的结果具有累积效果，这种积累效果反过来让现实越发偏离 “刚刚好” 的期望，如此滚雪球一般。
形成判断要基于数据，凡是基于数据的分析都要承担滞后性风险，风险的累积性来自于单向时间，1 + 1 = 2，却不允许减法将 2 消除，只能靠除法将它稀释，在很久之后 2 / 10000000 约等于 0。要么过多，要么不够，不能将 “未来的过多” 沿着时间轴往前搬，以弥补 “现在的不够”，现在过多，万一未来也过多，就累积了，大致就这么解释。时间的单向是统计突发的根源。
最近关于时间借贷的想法亦来自于此，《利息原理》恰恰给出并深入分析了一个实际例子。
按照单向时间分析，结论很明显，如果网络提供了 buffer 用以吸收统计突发，只能将 “当前的过多” 沿时间轴向后搬，以弥补 “未来的不足”，在不可预测的未来同样过多时，buffer 则堆积，buffer 的大小影响的只是堆积程度。换句话说，buffer 倾向于 “总是会被填满”。
观察自然界，持续大流量河流附近特别是汇集处，非常容易形成湖泊，大自然是时间不耐。bbr 的问题等同于下面的描述。一条大河上有座大坝，如何才能让大坝不蓄水，就好像没有这座大坝一样，答案很简单，把大坝拆了，因为本来就没有这座大坝。如果在大坝上游再引入一条河注入，让大坝不蓄水就很难。为什么非要让大坝不蓄水呢，大坝本身的蓄水就是对枯水期的借贷，一种常平仓而已。bbr 对 buffer 的纠结等同于让大坝不蓄水。
展示一下问题：
图中夸大了 probe_gain 比例，意在突出重点，诚然，maxbw window，cruise 周期长度都会影响图中 buffer 膨胀程度，虽然 bbr 状态机承诺了 queue 总会 drain 掉，但掩盖不了图中前半段的事实，或者，可以从另一方面理解，reno/cubic 难道不也是承诺总会 drain 掉 queue 吗？
多流 bbr 的流程必须围绕 buffer 展开，10 rounds or 更小的 N rounds 周期并不改变围绕 buffer 膨胀的本质。 事实上当 deliver_rate < gain * pacing_rate 就足以说明发生了 buffer 挤占(时间借贷)，要彻底 drain，而不仅仅归还 5 / 4 * old_maxbw * min_rtt - new_maxbw * min_rtt，此时的 new_maxbw 是 buffer 作用下带宽重新分配的结果而不是空闲带宽。
bbr 的基本假设在事实上根本不存在。
前面餐厅的例子有个附加条件，好吃的餐厅才会排队，事实上这个条件完全可以去掉，任何统计复用系统，只要它将要满载，那么排队就是必然的，对于独立排队实体而言，该排队是不可预测和不可分析的(但对服务台却可以预测和分析)，即使不基于排队论分析，从单向时间也能自然推导出这一结论。
还是相同的论点，包括 bbr (作为统计复用实体)在内的端到端 cc 对系统状态的预判存在上限，该上限距离理论 “最优操作点” 甚远。无论怎么做都抓不到它，当你压缩 persist 度，规模也缩小了，当你放大它，却又模糊了。
皮鞋没有蹬上，露着白袜子。
浙江温州皮鞋湿，下雨进水不会胖。
这篇关于bbr 的 “最优操作点”的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
