前言
还是在去年年底的时候得知了kernel 4.9中添加了google推出的的一种新的tcp拥塞控制算法-BBR。当时就在自己的VPS上装上4.9的kernel，打开了BBR，测试了一下发现很好用，youtube一点都不卡。
不过遗憾的是当时并没有去了解这个算法的原理，后来就一直拖着了。这个周末终于不用在实验室加班，有了空闲时间就想找点事做，刚好想起了这个算法，搜索了一下发现中文资料并不多，就索性找到算法的原版论文，来尝试做一次分析。
BBR和现在linux 内核默认的的Cubic以及经典的Reno算法最大的不同在于对网络拥塞模型的理解。Reno以及Cubic都认为出现丢包就发生了网络拥塞，这种假设的前提是网络本身的丢包率非常低，因为这些算法不会区分这两种不同的原因导致的丢包。但是我们知道在现实中很多网络是会存在一定的丢包率的，最典型的的例子就是翻墙上国外的网站的时候。那么当网络丢包率比较高时，原先的这些算法表现如何呢？文尾给出的原始论文中有一张图，指出当网络丢包率达到百分之一时原始的算法几乎就卡住带宽接近于零了（Reno一丢包就慢启动的方式在不稳定的网络链路中根本没法有效的发包）。另外，Cubic和Reno根据丢包判断网络是否拥塞的这种方式还会导致另外一个明显的问题-Bufferbloat（缓冲区膨胀）。Bufferbloat指的是由于网络路径上的路由器都有缓存，Reno在慢启动过程中不仅会将数据包填满网络带宽，同时也会填满路径上所有路由器的缓存，直到缓存填满才会开始丢包减少发包。填满了路由器的缓存会导致后续的数据包排队过长，导致RTT突然增大增加的数据包的延时。这还会导致一个隐含的问题，为了避免丢包产生拥塞，路由器制造商会增大其缓存容量，更大的路由器缓存会导致更加严重的Bufferbloat问题，这样就在一个恶性循环中导致延时越来越大。
在这样的环境中，BBR出现了。BBR采用了跟原来的拥塞控制算法完全不同的模型，它不再根据丢包来判断是否发生拥塞，它直接测量网络的RTT和带宽。这里就要解释下拥塞控制所要达到的最优化目标了，对于一个网络链路，在优的条件下在网络上传输的数据包应该等于时延带宽积，也就是这些数据包完全填满了网络链路而没有填满链路上路由器的缓存。为了计算这个网络的时延带宽积，BBR分别测量的网络的最小时延和最大带宽来得到拥塞控制的最优化目标。
仔细想想，BBR所追求的才应该是拥塞控制的本质，而从Reno开始的一系列算法都是采取填满链路直到丢包的思路，而BBR的实现更加合理一些。
实现介绍
下面就类似Reno的方式简单说说BBR几个阶段和步骤。
首先类似于Reno，BBR也有慢启动过程，但是所不同的是，在慢启动过程初期BBR会测量RTT的值作为RTT的初始值，Reno慢启动过程一直到丢包才结束，而像上面说的BBR不会等到丢包，而是在不停的策略带宽，当带宽不再增长的时候就结束慢启动，将这时测量到的带宽当做带宽的初始值。
因为上一阶段测量慢启动结束点时BBR向网络中多占用了网络，那么就需要在这一阶段将多发出去的网络上的数据包排空，这时BBR进入drain（排空）阶段。指数降低发包的速率，随着网络中的数据包不断被接收排空，时延会不断下降，当时延不再降低时排空阶段结束，进入下一阶段。
排空阶段结束后，BBR进入稳定状态，在稳定转态下BBR交替测量网络的时延和带宽。下面讲讲具体测量的方式：
对于带宽，BBR以8个RTT为一个周期，在第一个RTT中将发包的速率增加25%，在第二个RTT中降低25%，后面六个RTT使用前面测量到的带宽发送数据。
对于时延，BBR以10秒钟作为一个周期，以这10秒钟的RTT的最小值作为新的RTT，如果在这10秒钟没有出现比当前RTT更小的值，那么网络的时延可能已经增大了，这时就进入时延探测阶段，在这个阶段中，BBR只发送4个数据包，用最小的RTT作为新的RTT值。
需要注意的一个点
对上面BBR的算法做点解释：
对于时延和带宽必须交替测量，不能同时测量，因为为了测量最小的RTT值，网络必须没有满，这时的带宽必然不是最大的。而为了测量最大的带宽，网络以满，RTT已经增大。所以这两个量就像是粒子的位置和动量一样没有办法同时测量的。
另外BBR用10秒钟作为一个周期，来测量RTT的值，所以对于短暂的RTT抖动并不敏感，这也是BBR算法和vegas算法不一样的地方。
小结
根据上面的分析，BBR其实比较适合的还是有一定丢包率的网络链路，在这种链路上BBR能够获得更好的带宽和更低的时延。但是尽管有如此多的有点，我们也要清楚BBR并不是万能的，在网络队列比较深的时候，如果Reno算法在BBR规定的10秒内还没有填满路由器的缓存也就是没有发生丢包的时候，BBR是弱于现在使用Reno和Cubic算法的。每种算法都有它合适的场景。
更多的分析可以看看参考链接中给出的论文，很好读也很好懂。