BBR是Google公司提出的拥塞控制算法,关于BBR的详细介绍,可以看博主之前的一篇文章:对于谷歌BBR拥塞控制算法个人研究

这篇文章主要围绕两个关键问题解释,也是对BBR进行简单的介绍:

  • BBR为什么可以这么快
  • 如此快速的速度是否影响了网络的公平性

1、传统拥塞控制方式机理与局限

TCP-Reno

TCP-CUBIC

上图:《计算机网络》谢希仁版所描述的TCP-RENO方式和现在最常见的TCP-CUBIC方式

思路大概都是让自己的发送速率尽量逼近拥塞门限值,直到监测到丢包之后才降速,然后再开始逐渐增加速率。

局限性

传统方式在没有出现丢包时会不停地增加拥塞窗口的大小,向网络注入流量,将网络设备的缓冲区填满,直到检测到丢包,认定产生拥塞才开始降速。

由于缓冲区长期趋于饱和状态,新进入网络的的数据包会在缓冲区里排队,增加无谓的排队时延,而且缓冲区越大,时延就越高。

BBR的思路

可以看到上图的红圈区域就是链路宽带被填满的区域,继续增加发送速率只会去填充缓冲区然后继续在网络设备中排队并不会发送到链路上传送,因此此时时延会因为有排队所以增加

因此BBR的目标就是控制发送速率让网络链路一直保持在红圈的区域,也就是清空排队的队列,让所有发送的数据包都可以进入链路传输而不是排队。而判定标准就是时延是否增加,若增加发送速率之后时延增加了,则我们可以认定这增加的数据包进入了缓冲区排队而不是传送,那么这时候就应该降速。

可见BBR是一种基于时延的拥塞控制方式而不是传统的基于丢包方式的拥塞控制方式。


2、BBR的具体四个阶段

要达到上面所描述的效果,BBR定义了4个阶段

这里只做简单的介绍,详细的大家可以参照CSDN的dog250大神的博客

Start-UP

类似于慢启动,发送窗口按照一定的增益系数不断增加,并且时刻记录RTT值与最大带宽,当增加速率后RTT增加了之后,判断管道满载,新增加的数据进入排队队列,此时应当排空多发送的数据包

Darin

将Start-UP阶段多发送的部分进行排空,之后进入Probe_BW阶段

Probe_BW

类似于稳定阶段,也是BBR中时间最长的阶段,如下图,仍然会去试探性的增加窗口,并且根据时延的反馈进行调整

仔细观察绿色的波峰,那就是一次尝试增加速率然后看延迟信息。

  • 如果延迟增加了,则降速,这样就产生了图中最左边的几个波峰
  • 如果延迟没有增加,那么就不降速,保持这个增加过后的速度,如图中间的绿色部分,infight也就是在途数据量明显增加了,而且都被有效的传送出去
Probe_RTT阶段

当上面任何一个阶段超过设定的时间内没有采集到最小的时延后进入,此时将发送窗口降低至很小的值持续200ms,并且只发送4个数据包,也就是进行了一次让步,只为不让链路中的缓冲区队列存在数据包,此时延迟会回归正常水平,如下图绿线

之后再根据情况进入startup或者Probe_BW阶段。


3、为什么这么快

可以看到,因为传统方式检测到丢包就会降速,那么在1%丢包率的时候速率就已经非常低了,如上图红线。

而BBR并不会对丢包产生反应,所以可以在一定丢包率的网络中保持自己的速度,如上图绿线。

所以这就解释了为什么我们在海外的服务器上面搭载BBR后为什么速度可以这么快。而且BBR获得的速度都是CUBIC算法自己退让出来的速度。

那么这看上去BBR似乎不太公平,事实真的是这样吗?看下一节。


4、 BBR的公平性

1、与其他BBR竞争的场景

可以看见因为BBR有自己的让步机制,因此多个连接最终会收敛到一个一样的速度,从而保证了公平性。

2、与传统算法竞争的场景

之前就提到了BBR在一定丢包率的链路上速率会比CUBIC快很多,那这样对CUBIC来说公平吗?

毫无疑问是公平的,因为CUBIC在没有丢包率的链路中,会不断地往缓冲区填充数据包,而在这个条件之下BBR会因为得不到最小的延迟而不断地让步,从而导致全盘皆输的情况。

而CUBIC往缓冲区里面填充数据包,很明显是非常不合理的,因为增加了无谓的时延。在一定丢包率的链路中CUBIC因为自己的策略让出来的那部分速率,也是完全没有必要的,因此此时链路没有填满,链路的利用率仍然很低。而BBR正是为了增加链路的利用率而理所应当的占满CUBIC所让出来的部分的。在我看来CUBIC在这种环境下根本谈不上竞争,而是为自己的恶性付出的代价而已。

如果说TCP-CUBIC是一种传统拥塞控制方式,那么BBR更像是一种拥塞避免控制方式,因为只要网络设备缓冲区不存在排队数据包,那么拥塞就不可能发生。

而CUBIC往缓冲队列里面填充数据的不合理行为,让它对比于BBR显得更加破坏了网络竞争的公平性


5、关于BBR的一些其他事情

因此文章开头两个问题我们可以回答了

  • 为什么BBR可以做到比CUBIC快这么多的速度

    • 答:不再去关注丢包,不会因为丢包而降速
  • 如此快速的速度是否影响了网络的公平性

    • 非常公平,甚至自己还有点劣势

另外BBR 由Google在 2016 年底于ACM queue期刊上发表,发表的时候Google已经在 YouTube 服务器和谷歌跨数据中心广域网上部署BBR,继承了Google“先在生产环境上部署,再开源和发论文”的研究传统。

而且据 YouTube 官方数据称,部署 BBR 后,在全球范围内访问 YouTube 的延迟降低了 53%,在时延较高的发展中国家,延迟降低了 80%。

可见BBR虽然目前还存在一些其他的问题,但是是一个非常有潜力的新思想的提出,对以后改善长胖网络与国际互联网链路环境的帮助非常大。

一些杂谈

现在也出现了一些魔改BBR或者一些相关的东西,这些只是更改了BBR内置的一些参数,让BBR破坏公平性的去采用更加激进的方式增加速率而已,而并不是一种合理的拥塞控制方式

例如我们可以修改Probe_BW时期的发送窗口试探

也可以修改Start-UP阶段的增益与Drain排空的速率

也可以修改Probe_RTT阶段的时间参数

大家对源码有兴趣的,可以去GitHub上瞧一瞧:GitHub-BBR

Last modification:May 27th, 2021 at 10:40 am