谷歌开发出了一种加速网络传输协议TCP的新算法，这种算法通过优化传输速度，避免路由堵塞现象的产生。BBR利用瓶颈带宽和往返传播时间，被认为是迄今为止跨越不同路由发送数据的最快方法，当数据路由拥挤时，能够更有效地处理流量。目前Google已经将BBR投入YouTube使用。有消息透露，BBR通过优化使YouTube流量平均增长了4%，在其他一些方面则达到了14%。
什么是TCP？
TCP始于1970年，作为协议套件的一部分， TCP / IP将数据格式化成数据包在网络上进行传输。IETF工作人员表示，超过90%的IP流量都通过TCP传输。
在过去的几十年里，为加快TCP / IP的速度，很多人都在为TCP如何处理拥堵的问题不断努力。TCP通过监控传输中丢失的分组数量减慢在感知拥塞时发送流量的速度。由于网络交换机和路由器的小缓冲区与互联网连接的低带宽很匹配，所以BBR的效果还是很不错的。遗憾的是，“基于损失”拥塞控制在当今的环境中并不适用。
BBR优势
BBR以一定速度不断评估多个路由的吞吐量和往返流量时间，得出遍历网络需要的时间。这样一来，BBR以网络可处理的速度发送流量，比最初的TCP拥塞控制更有效果。
BBR还兼容由Google设计的替代传输协议——快速UDP互联网连接(QUIC)，并被IETF作为标准。
BBR并不是工程师们为加速TCP所做出的第一个努力。北卡罗来纳州立大学的研究人员表示，当今开发TCP中使用的最流行的基于丢失的拥塞控制算法之一是二进制增加拥塞控制(BIC)，其次是CUBIC，还有另一种流行的拥塞控制算法叫做Reno。这些算法都是使用分组丢失来确定拥塞的，尽管开发BBR的Google工程师Jacobson表示，在他看来，BBR才是唯一一个通过实际估计流量速度来确定最佳传输速度的TCP算法。
BBR取得初步成功
Mirja Kuhlewind是苏黎世网络系统集团的高级研究员，也是IETF的运输区域主管，负责TCP的维护和改进工作。她表示，在传输与拥堵控制方面建立标准需要很长的时间，在BIC和BBR的发展之前，通过数十次TCP技术改进，才仅有一个成为了标准，拥塞控制计划的标准化不是一件易事。
Reno和CUBIC基于相同的原理工作，将丢失包作出的反应作为拥塞的标志，检测到丢失时降低发送速率。而BBR利用的是分组定时信息来确定链路是否拥塞。
谷歌的一些客户已经意识到BBR的重要性，Wordpress在Google Cloud和Founder中托管了50万个站点，谷歌的CTO Jason Cohen也表示BBR与其他基于丢失的拥塞控制相比提高了2700倍的吞吐量、延迟降低了25倍。
BBR原理简介
拥塞现象是指到达通信子网中某一部分的分组数量过多，使得该部分网络来不及处理，以致引起这部分乃至整个网络性能下降的现象，严重时甚至会导致网络通信业务陷入停顿，即出现死锁现象。这种现象跟公路网中经常所见的交通拥挤一样，当节假日公路网中车辆大量增加时，各种走向的车流相互干扰，使每辆车到达目的地的时间都相对增加（即延迟增加）,甚至有时在某段公路上车辆因堵塞而无法开动(即发生局部死锁)。
拥塞控制就是针对此问题的控制技术/解决方案，但也不能说是解决，控制技术只能起到尽量避免/缓解拥塞的作用。TCP-BBR技术呢，用了一种溢水原理的思想，来预判丢包率，调配发包速率。
假设你有一支较细的U形管，下面还有一堆不可溶的填塞物，你从一边开始大量灌水，如果另一边出水正常，你就可以继续加大灌水量，达到最大带宽。如果另一边发现水时断时有，就证明下面出现了随机拥堵，这时，你就要减小灌水量，等待水位落下。这时如果采用传统继续灌水时，也就会造成水溢出（丢包现象的产生）。所以这是真正的按需发包。当然，这一切是建立在系统预估的情况下。
