Google BBR拥塞控制算法背后的数学解释

杭州待了一段时间，回到深圳过国庆假期，无奈温州皮鞋?厂老板过节要回温州和上海，不在深圳，也就没有见着，非常遗憾！

国庆节当天，就写这个了。经理不会弹琴，但是经理会弹琴。

我原本可能会在想国庆节的凌晨到大清早写点什么呢，现在不用想了，就写BBR拥塞控制算法背后的数学吧，这个事情我是在杭州回深圳的路上突然找到了最终结果的，我必须把它记录下来。其实在找到这个结果之前，很久很久，我就在思考这个问题了。

背景和动机

2016年大概十月中下旬，同事推荐了一个视频：
Making Linux TCP Fast：https://www.youtube.com/watch?v=hIl_zXzU3DA
跟随视频后的链接netdevconf的链接，还有一些slides和paper可以看：
https://netdevconf.org/1.2/session.html?yuchung-cheng
我也是那时，或者更早些一点，大概九月份的时候，接触了Google的BBR算法，应该算是国内第一批次的了，随后的一段相当长的时间，我对该算法进行了相对深入的剖析以及思考，从解释Paper，分析源码，设计到优化，反正不知花了多少周五的通宵。

随着后续这个BBR算法的逐渐普及，加入讨论的人也越来越多了，从最初的如何用起来到后面的各路大神的各路神技，可谓热闹非凡，我当时讲，TCP被你们玩坏掉了，BBR也难逃劫难…

和CUBIC背后那精湛简介的数学收敛模型不同，BBR是基于测量的一个算法，它甚至没有一个数学上的解释以证明 为什么这样做就是最好的，以至于，很多人开始盲改，最终的效果和自己的预期，当然是大相径庭。

我一直在思考BBR背后的数学，我总觉得能用数学公式表达的东西才是真正确定的，所以我希望在我长时间思考后，能有一个数学上的解释，来解释BBR为什么是高效率的，为什么只能这样做。

这几天，我感觉成功了一点，所以不敢独享这回报，写此文以分享。

插曲

先来个插曲。

很多人看到BBR不排队的特征后，第一想到的就是 不排队甚好，但稍微在缓存队列里堆点数据包也不错，不然怎么能赢了那些不守规矩的流呢？  于是乎就出现了各类所谓的 BBR优化，无一例外地都是把Reno/CUBIC那一套算法的 精髓 照搬到BBR，于是BBR就被玩坏了！

我也干过这种事，后来我跟BBR的作者Neal Cardwell交流，他告诉我 这增加了算法的复杂性，并且破坏了BBR的根本。

…

我退出了 BBR优化队伍，我也不玩了，我潜下心希望能 从数学上证明BBR不排队就是最优的，只要排队就不行，一点队列也不行。本文写作前一天，我得了一些结论。记录这些结论并记录我是怎么想的，就是本文的主要内容。

温州皮鞋厂老板促使我开了场，让我第一次用数学来描述BBR算法。

当时是要计算一下 ***为什么BBR在Startup阶段的gain是$2ln22ln2$1，而此时，Inflight的值就是所谓的$BDP=wmax\times tmin=fc=1B$