What is Google BBR

本文关于BBR的介绍部分摘自Tech.jandow.com,版权归原作者或者来源机构所有。

传统 TCP 拥塞控制算法,基于丢包反馈的协议。

基于「丢包反馈」的协议是一种 被动式 的拥塞控制机制,其依据网络中的丢包事件来做网络拥塞判断。即便网络中的负载很高时,只要没有产生拥塞丢包,协议就不会主动降低自己的发送速度。

这种协议可以 最大程度的利用网络剩余带宽,提高吞吐量。 然而,由于基于丢包反馈协议在网络近饱和状态下所表现出来的侵略性,一方面大大提高了网络的带宽利用率;但另一方面,对于基于丢包反馈的拥塞控制协议来说,大大提高网络利用率同时意味着下一次拥塞丢包事件为期不远了,所以这些协议 在提高网络带宽利用率的同时也间接加大了网络的丢包率 ,造成整个网络的抖动性加剧。

还有谁导致了丢包?

丢包并不总是拥塞导致,丢包可能原因是多方面,比如:

  • 全球最牛的防火墙 GFW 的随机丢包策略
  • 网路中由于多路径衰落(multi-path fading)所造成的信号衰减(signal degradation)
  • 通道阻塞造成的丢包(packet drop),再者损坏的封包(corrupted packets)被拒绝通过
  • 有缺陷的网路硬件、网路驱动软件发生故障
  • 信号的信噪比(SNR)的影响

Goooogle BBR的出现

我们自然不喜欢 GFW 这种人为的随机丢包策略,当路过 GFW 时,数据被丢包,我们在此时应该 立刻重新发包,增大发送的频率,而不希望降低速度,也就是不希望传统的 TCP 拥塞算法去控制。

由此,就出现了基于不丢包的拥塞控制算法 CDG, 以 延迟 作为判断依据,延迟增大说明拥塞, 数据开始在路由器的缓冲中积累. 降低发送窗口 。然而CDG算法与基于丢包的算法不兼容, 只有全球的设备都换上CDG,但这是不可能的,目前市面上的设备不可能一下子都切换到 CDG,因此 Google 就不开心了,Google 的科学家们开发了一种过渡算法来解决这个问题,这个算法的名字就是 BBR(Bottleneck Bandwidth and RTT) ,它是一种全新的 拥塞控制算法 ,BBR 同 CDG 一致的思想是不以丢包作为拥塞控制信号,但是和 CDG 不同的是,BBR 能和 cubic 和 reno 共存。

使用BBR前后网络吞吐量对比图 / By Google

BBR 由 Google 开发,供 Linux 内核的 TCP 协议栈使用,有了 BBR 算法,Linux 服务器可以显著提高吞吐量并减少连接延迟,简单来说 BBR 能加速网络传输速度。此外,部署 BBR 也很容易,因为该算法只需要发送方,而不需要网络或接收方的支持。

堵塞,和缓解

在了解这个玩意之前,我们需要了解什么是拥塞

什么是拥塞

拥塞是指到达通信子网中某一部分的分组数量过多,使得该部分网络来不及处理,以致引起这部分乃至整个网络性能下降的现象,严重时甚至会导致网络通信业务陷入停顿,即出现死锁现象。(摘自百度百科)

而Google TCP-BBR的存在就是为了缓解拥塞现象的发生。

吼,现在我们已经知道了为什么要有BBR的存在。那么BBR这个算法他是如何缓解拥塞的呢?

如何缓解拥塞

首先我们要知道,服务器带宽这条水管他是固定的流量限度。至少我觉得不会有算法那么无聊去给你探测服务商自动帮你花钱增大带宽….
丢包,丢包是怎么样的?丢包就是流量太大了,导致这条水管他的某个地方突然喷出来,而这些喷出来的水还能到达目的地吗?显然不能了。
那么这就很好想了,既然流量太大会溢出,那我不如限流?
是的。Google就是这么想的

Google BBR的原理

Google BBR实际上基于一个溢水模型,但我认为爆水管这个可以形容的通俗一些。
BBR 通过系统发包量预判爆水管现象的发生,控制水管流量。
假设,你在A点往B点灌输水流,你一直灌输不考虑水管的容量。按道理来说在传统TCP拥塞算法下会直接爆,但是有了BBR,他会预判爆水管的发生,从而限流限制到服务器的最大发包量。这样一来,既不会爆水管,也能全力发挥水管的作用。

额外内容:锐速

锐速(Server Speeder)不是限流的算法。但他是“极端的利他主义”
什么意思?
锐速会预测丢包,接着他会把这个包重新再发一遍…依笔者的看法来讲,这点并不能更有效缓解丢包。为啥呢?
因为你重新发出去的包,可能还会增大其他包的丢失率,而且这个的副作用也蛮大的,就是你的服务器会加速损失流量…烧钱啊
以及虽说有人觉得锐速效果挺好,但是会加剧骨干网的负担。造成很多不必要的流量浪费。