BBR 与 TCP 原生拥塞控制算法的对比

1. 什么是拥塞控制？

要解释拥塞控制，那就要解释拥塞是什么。简单来说，拥塞是指由于带宽不足（或其他原因，但主要是带宽），导致包的主动或被动的丢失。而拥塞控制就是尽可能的减少包的丢失。

假设说没有拥塞控制算法的情况下，A 想发送 100 个数据包，由于拥塞，丢失了 99 个数据包，在这种条件下，A 只能重新传输 99 个数据包，接下来，可能又有 98 个丢失…每一次发送都会有成本，为了避免不必要的浪费，拥塞控制算法就很有必要了。

TCP 作为传输层的协议，提供了拥塞控制算法，名字叫 Tahoe(version 1)/Reno(version 2)。他们的核心思想是：将传输速度按一定速度增加，当出现丢包等问题的时候，我们就降低传输速度(减半/变为 1)，然后再次增加，如此循环。

TCP 的拥塞控制算法从代码层面比较好写，但是也有个明显的缺陷。

我们都知道，传输的流量为

传 输 数 据 量 实 时 网 速

而从上面的图可知，TCP 的拥塞算法，不可能完全利用带宽，从好的方面思考则是为其他的 TCP 连接留有空间，但是从另一个角度来说，这是一种浪费。

那么如何完美利用我们的带宽呢？

BBR (基于 Bottleneck Bandwidth and Round-trip 的拥塞算法) 是 Google 开源的拥塞控制算法，它的核心思想是：通过测量网络的带宽和延迟，来决定传输速度。说人话就是，我们测量出当前网络的带宽，然后就按照这个速度一直跑流量。

BBR 会在一定的时间试探当前网络能否发送更多数据包，如果能，则增加单位时间发送的数据包，如果不能，则保持当前速度。

如图所示，BBR 算法会试探当前网络的带宽，如果能够发送更多的数据包，则会增加单位时间发送的数据包，如果不能，则保持当前速度。这样，理论情况下，我们可以完美的利用我们的带宽。

Google 的全球广域网（B4）在 2016 年就已经将全部 TCP 流量从 CUBIC 切换到 BBR，吞吐提升了 2~25 倍；在做了一些配置调优之后，甚至进一步提升到了 133 倍。