自 bbr 发布,它的表现让很多人开始追版本,bbr2,bbr3 何时发布,何时并入 kernel,很多人操心。虽然 bbr2,bbr3 尚未并入 kernel,但网上早就出现五花八门的一键安装脚本,似乎只是升级一下内核的问题,于是人们趋之若鹜。
按版本迭代预期,大家普遍觉得 bbr2 会比 bbr1 表现更好,bbr3 更优秀,但结果让人失望,bbr2,bbr3 都不如 bbr1 … 但即便如此,人们依然觉得这只是暂时的 bug,等经过 bugfix,bbr3 一定起飞。
…
以上说的 “表现” 是吞吐,而不是作为一个 cc 真正该有的表现。
我画个简图解释一下为什么 bbr2,bbr3 吞吐不如 bbr1:
这是 bbr2,bbr3 在本质上不如 bbr1,而不是 bugfix 能解决的,因为吞吐下降根本不是问题,而是解决了问题后的结果。bbr1 连个实验品都算不上,它只验证了不证自明的时延,带宽的正交关系本身,完全无法作为 cc 大规模部署,不多说。
值得再次强调的是作为可大规模部署的 cc,一定至少确保向下兼容,否则最严重可能引起整网崩溃,bbr1 显然无法做到。
bbr1 在大多数人眼里表现好,因为只关注吞吐,它确实好,就像很多人想做却不会编程,会编程却不懂内核那样,他们只想用更大速率发送,而 bbr1 恰好就是这样一个东西。
人们关注的是提高自身的吞吐,而不是拥塞控制。到处都在折腾 “为什么 bbr2 这么差?”,“bbr3 运行报错”,“如何让 bbr 在 probertt 时 inflight 下降不那么厉害”,到处都在魔改,bbr 竟然成了加速机制… 经理会说不这么做就没有绩效,那就胸怀无知拥抱你那可怜的绩效吧。
浙江温州皮鞋湿,下雨进水不会胖。