TCP BBR之全局同步

缘起于一场技术交流，我以一篇短文作为总结。

---

先给一个TCP魔数：

rtt=(1−α)×rtt+α×rttnow r t t = ( 1 − α ) × r t t + α × r t t n o w

其中 α α 是 18 1 8 ，为什么是 18 1 8 而不是 19 1 9 ？答案是调得一手好参数！这显然是一个很谢特的回答。

  然而我接受这坨谢特，因为我无法证明我有更加完美的。TCP的代码中到处充斥着这种魔术数字，近的说Google BBR吧，为什么ProbeBW内部状态机是6个匀速，为什么ProbeRTT的忍耐周期是10秒，等等等等，使我不得开心颜。

  好吧，你会说这是经验值，我并不反对，因为我没有理由反对，你说这是实测数据所得，我也无话可说，你说10就是10，你说8就是8，这个你说了算，我和作者的分歧点不在这，我们的分歧在于，这种魔术数是作为常量起作用还是作为概率期望起作用，换句话说，给定数字8，你会认为8就是8，而我会认为大概率会是8，但仍然正态分布为7或者9，6或者10…，我的理解有误吗？

  我发现一个可以类比的现象，即军队过桥，一般都会取消正步，代之以碎步通过，就是为了避免共振造成桥梁坍塌。但这一点是不是可以用于非桥梁的情况呢？我是讨厌整齐划一的，所以我喜欢美军的方式，结果导向，而不是PLA那般的过程管理，跑步跑得齐其意义是什么，我至今不知道。

  TCP BBR拥塞控制算法里面的诸多魔数，让我感知到了全局同步，虽然桥梁是否坍塌还有待观察。每一条BBR流就是一个军人，他必须不能和其它军人的步伐协调一致…我不知道这样做是不是正确。我无法证明，但可以事实证明。

---

请按照下列建议修改BBR代码：

• 移动指数平均之外的所有魔数全部作为统计期望而不是常数；
• 期望值保持和常数值完全一致，不要自行修改。

解释一下第二点。

  不要觉得自己多么高明，把 54 5 4 改成 64 6 4 就能有什么进展，这都是臆想和YY，你要知道这些魔数的来历，而你可能根本就没有导出这些魔数的环境，特别是在国内，完全没有这种环境。所以，除了相信它，不要质疑它。

  你以为让BBR Startup探测更加猛烈一些就能取得更好的效果吗？你错了，你没有找到平衡点，偶尔的场景你会觉得高效，但大多数情况下，你忽略了更差的表现，不是吗？

  我并没有试图推翻这些魔数，而只是代之以期望。你想要的是17个10，我却认为以下的序列更合理：8,8,9,9,9,10,10,10,10,10,10,10,11,11,11,12,12。

  你，认为呢？