Google bbr

BBR（”Bottleneck Bandwidth and Round-trip propagation time”）是 Google 提出的一种新型拥塞控制算法，可以使 Linux 服务器显著地提高吞吐量和减少 TCP 连接的延迟。

BBR解决了两个问题：
一、在有一定丢包率的网络链路上充分利用带宽。非常适合高延迟，高带宽的网络链路。
二、降低网络链路上的buffer占用率，从而降低延迟。非常适合慢速接入网络的用户。

项目地址:https://github.com/google/bbr

google-bbr2

google-bbr3

算法对比

人类的公式都太依赖时间t了，人们总是希望在我们生存的三维空间里尽量压缩时间来提高效率。谈到效率，那么决定效率的一定是分母时间t吗？不然，这个哲学问题有太多其他的答案了。

而之前的Reno/CUBIC之所以蒙蔽了人类这么久，正是因为程序员和CS科学家都是一群事件驱动的群体。他们在为TCP建立性能模型的时候，总是希望通过用Time-series/RTT-series analysis来查到一个连接最快能跑多少数据。

但是这些都是错的，我们奉为神明的时间t的产物时间轴，具有滞后性这一致命的缺点。自从1973年卡恩与瑟夫开发出了TCP/IP协议中最核心的两个协议：TCP协议和IP协议提出之后，诸如Reno/CUBIC等经典TCP拥塞算法的目标都是收敛于一个逻辑滞后的收敛点，不断地增加数据的传输，试图填满整个网络以及网络上的所有缓存，以为这样就会达到比较高的带宽利用率，直到发现丢包，然后迅速降低数据发送量，之后重新向那个错误的收敛点前进，如此反复。这就是锯齿的根源。而BBR则在一个不随时间滑动的大概10秒的时间窗口中采集最小RTT，如果有更多的带宽，那么就利用它，如果没有，就退回到之前的状态。

以上就是Reno/CUBIC和BBR的区别，它们同样完成了”To find current bandwidth”, “To avoid congestion”, “To probe more bandwidth”的逻辑，只是一个是事件驱动的被动实现，一个是反馈驱动的主动实现。

升级内核

如果是centos8操作系统，内核版本默认是4.18，比如：4.18.0-147.el8.x86_64
centos8默认支持BBR，可以不用升级内核

如果是centos7操作系统，开启BBR要求4.10以上版本 Linux 内核，可使用如下命令查看当前内核版本：

uname -r
3.10.0-1062.4.1.el7.x86_64

rpm --import https://www.elrepo.org/RPM-GPG-KEY-elrepo.org
rpm -Uvh http://www.elrepo.org/elrepo-release-7.0-2.el7.elrepo.noarch.rpm
yum --enablerepo=elrepo-kernel install kernel-ml

执行后会提示：

包名: kernel-ml
版本: 5.3.10-1.el7.elrepo.x86_64
yum源: elrepo-kernel 
包大小: 49 M

关于Linux内核版本：可以在 https://www.kernel.org/ 查看持续更新的版本。

安装完成后，查看已安装的内核：

rpm -qa | grep kernel

kernel-tools-3.10.0-1062.12.1.el7.x86_64
kernel-headers-3.10.0-1062.12.1.el7.x86_64
kernel-3.10.0-1062.4.1.el7.x86_64
kernel-ml-5.3.10-1.el7.elrepo.x86_64
kernel-tools-libs-3.10.0-1062.12.1.el7.x86_64
kernel-3.10.0-957.1.3.el7.x86_64
kernel-3.10.0-1062.12.1.el7.x86_64
kernel-debug-devel-3.10.0-1062.12.1.el7.x86_64

在输出中看到 kernel-ml-5.3.10-1.el7.elrepo.x86_64 类似的内容，表示安装成功。

修改linux grub2引导

执行以下shell命令:

egrep ^menuentry /etc/grub2.cfg | cut -f 2 -d \'

会得到如下结果:

CentOS Linux (5.3.10-1.el7.elrepo.x86_64) 7 (Core)
CentOS Linux (3.10.0-1062.4.1.el7.x86_64) 7 (Core)
CentOS Linux (3.10.0-957.1.3.el7.x86_64) 7 (Core)
CentOS Linux (0-rescue-05cb8c7b39fe0f70e3ce97e5beab809d) 7 (Core)

由于序号从0开始，设置默认启动项为1并重启系统：

grub2-set-default 0
reboot

重启完成后，重新登录并重新运行uname命令来确认你是否使用了正确的内核：

uname -r

得到如下结果则升级成功： 5.3.10-1.el7.elrepo.x86_64

开启 bbr 功能

执行以下命令：

echo 'net.core.default_qdisc=fq' | tee -a /etc/sysctl.conf
echo 'net.ipv4.tcp_congestion_control=bbr' | tee -a /etc/sysctl.conf
sysctl -p

完成后,分别执行如下命令来检查BBR是否开启成功:

sysctl net.ipv4.tcp_available_congestion_control
输出应为 net.ipv4.tcp_available_congestion_control = bbr cubic reno
sysctl -n net.ipv4.tcp_congestion_control
输出应为 bbr
lsmod | grep bbr
输出应类似tcp_bbr  20480  4

速度测试

在服务器centos7和centos8上分别执行以下命令：

dd if=/dev/zero of=1024MB.zip bs=1024k count=1000
python -mSimpleHTTPServer 8081

说明:centos7和centos8操作系统的/文件系统类型都是xfs,网卡都是千兆

centos7:

cat /etc/redhat-release
CentOS Linux release 7.6.1810 (Core)
uname -a
Linux host1.net 3.10.0-957.5.1.el7.x86_64

centos8:

cat /etc/redhat-release
CentOS Linux release 8.1.1911 (Core)
uname -a
Linux host1.net 4.18.0-147.el8.x86_64

通过浏览器下载1024MB.zip
host1.net/1024MB.zip 需要1分35秒
host2.net/1024MB.zip 需要1分8秒
我尝试把host2的bbr功能关闭，测试下载时间需要1分35秒

10 Gigabit Ethernet link, sending over a path with a 100 ms round-trip time (say, Chicago to Berlin) with a packet loss rate of 1%

结论

开启BBR之后,速度提升明显。

10 Gigabit Ethernet link, sending over a path with a 100 ms round-trip time (say, Chicago to Berlin) with a packet loss rate of 1%
Google的测试环境是10G的网卡，RTT是100ms，相当于美国芝加哥到德国柏林的RTT，丢包率是1%

According to Google’s tests, BBR’s throughput can reach as much as 2,700x higher than today’s best loss-based congestion control; queueing delays can be 25x lower.
根据Google的测试数据，BBR的吞吐性能是cubic的2700倍，延迟比cubic低25倍

最后需要提示一点，TCP拥塞控制算法是数据的发送端决定发送窗口，因此在哪边儿部署就对哪边儿发出的数据有效。举个栗子说明就是：如果是下载，就应在Server端部署；如果是上传，就应在Client端部署。

centos7操作系统如何开启BBR功能

Table of Contents