BBR是一种加速TCP的拥堵算法技术。BBR 利用瓶颈带宽和往返传播时间，被认为是迄今为止跨越不同路由发送数据的最快方法，当数据路由拥挤时，能够更有效地处理流量。

　　谷歌开发出了一种加速网络传输协议 TCP 的新算法，这种算法通过优化传输速度，避免路由堵塞现象的产生。BBR 利用瓶颈带宽和往返传播时间，被认为是迄今为止跨越不同路由发送数据的最快方法，当数据路由拥挤时，能够更有效地处理流量。目前 Google 已经将 BBR 投入 YouTube 使用。有消息透露，BBR 通过优化使 YouTube 流量平均增长了 4%，在其他一些方面则达到了 14%。

　　TCP 始于 1970 年，作为协议套件的一部分， TCP / IP 将数据格式化成数据包在网络上进行传输。IETF 工作人员表示，超过 90%的 IP 流量都通过 TCP 传输。

　　在过去的几十年里，为加快 TCP / IP 的速度，很多人都在为 TCP 如何处理拥堵的问题不断努力。TCP 通过监控传输中丢失的分组数量减慢在感知拥塞时发送流量的速度。由于网络交换机和路由器的小缓冲区与互联网连接的低带宽很匹配，所以 BBR 的效果还是很不错的。遗憾的是，“基于损失”拥塞控制在当今的环境中并不适用。

　　BBR 以一定速度不断评估多个路由的吞吐量和往返流量时间，得出遍历网络需要的时间。这样一来，BBR 以网络可处理的速度发送流量，比最初的 TCP 拥塞控制更有效果。

　　BBR 还兼容由 Google 设计的替代传输协议——快速 UDP 互联网连接(QUIC)，并被 IETF 作为标准。

　　BBR 并不是工程师们为加速 TCP 所做出的第一个努力。北卡罗来纳州立大学的研究人员表示，当今开发 TCP 中使用的最流行的基于丢失的拥塞控制算法之一是二进制增加拥塞控制(BIC)，其次是 CUBIC，还有另一种流行的拥塞控制算法叫做 Reno。这些算法都是使用分组丢失来确定拥塞的，尽管开发 BBR 的 Google 工程师 Jacobson 表示，在他看来，BBR 才是唯一一个通过实际估计流量速度来确定最佳传输速度的 TCP 算法。

　　Mirja Kuhlewind 是苏黎世网络系统集团的高级研究员，也是 IETF 的运输区域主管，负责 TCP 的维护和改进工作。她表示，在传输与拥堵控制方面建立标准需要很长的时间，在 BIC 和 BBR 的发展之前，通过数十次 TCP 技术改进，才仅有一个成为了标准，拥塞控制计划的标准化不是一件易事。

　　Reno 和 CUBIC 基于相同的原理工作，将丢失包作出的反应作为拥塞的标志，检测到丢失时降低发送速率。而 BBR 利用的是分组定时信息来确定链路是否拥塞。

　　谷歌的一些客户已经意识到 BBR 的重要性，Wordpress 在 Google Cloud 和 Founder 中托管了 50 万个站点，谷歌的 CTO Jason Cohen 也表示 BBR 与其他基于丢失的拥塞控制相比提高了 2700 倍的吞吐量、延迟降低了 25 倍。

　　拥塞现象是指到达通信子网中某一部分的分组数量过多，使得该部分网络来不及处理，以致引起这部分乃至整个网络性能下降的现象，严重时甚至会导致网络通信业务陷入停顿，即出现死锁现象。这种现象跟公路网中经常所见的交通拥挤一样，当节假日公路网中车辆大量增加时，各种走向的车流相互干扰，使每辆车到达目的地的时间都相对增加（即延迟增加）,甚至有时在某段公路上车辆因堵塞而无法开动(即发生局部死锁)。

　　拥塞控制就是针对此问题的控制技术/解决方案，但也不能说是解决，控制技术只能起到尽量避免/缓解拥塞的作用。TCP-BBR 技术呢，用了一种溢水原理的思想，来预判丢包率，调配发包速率。

　　假设你有一支较细的 U 形管，下面还有一堆不可溶的填塞物，你从一边开始大量灌水，如果另一边出水正常，你就可以继续加大灌水量，达到最大带宽。如果另一边发现水时断时有，就证明下面出现了随机拥堵，这时，你就要减小灌水量，等待水位落下。这时如果采用传统继续灌水时，也就会造成水溢出（丢包现象的产生）。所以这是真正的按需发包。当然，这一切是建立在系统预估的情况下。