Linux 升级内核开启 TCP BBR 有多大好处

前言

如果你有订阅一些科技新闻，应该会有看过内核在4.9当中加入了一个新的算法，来解决在有一定的丢包率的情况下的带宽稳定的问题，这个是谷歌为我们带来的干货，新的 TCP 拥塞控制算法 BBR (Bottleneck Bandwidth and RTT)，谷歌一向的做法是，先上生产，然后发论文，然后有可能开源，所以这个已经合并到了内核4.9分支当中，算法带来的改变在出的测试报告当中有很详细的数据展示，这个看多了可能反而不知道到底会有什么明显改变，特别是对于我们自己的场景

那么本篇就是来做一个实践的，开看看在通用的一些场景下，这个改变有多大，先说下结果，是真的非常大

实践

还是我的两台机器lab8106和lab8107,lab8106做一个webserver，lab8107模拟客户端，用简单的wget来进行测试，环境为同一个交换机上的万兆网卡服务器

我们本次测试只测试一种丢包率的情况就是1%，有兴趣的情况下，可以自己去做些其他丢包率的测试，大多数写在丢包率20%以上的时候，效果可能没那么好，这个高丢包率不是我们探讨的情况，毕竟不是常用的场景
###安装新内核
内核可以自己选择4.9或者以上的进行安装，也可以用yum安装,这里只是测试，就yum直接安装

1
yum --enablerepo=elrepo-kernel install kernel-ml

修改启动项

1
2
3
grub2-editenv list
grub2-set-default 'CentOS Linux (4.9.5-1.el7.elrepo.x86_64) 7 (Core)'
grub2-editenv list

准备下载数据

准备一个web服务器然后把一个iso丢到根目录下，用于客户端的wget

设置丢包率

这里用tc进行控制的，也就是一条命令就可以了,这个还可以做其他很多控制，可以自行研究

1
tc qdisc add dev enp2s0f0 root netem loss 1%

如果需要取消限制

1
tc qdisc del root dev enp2s0f0

设置新的算法

讲下面的两个配置文件添加到/etc/sysctl.conf

1
2
net.ipv4.tcp_congestion_control=bbr
net.core.default_qdisc=fq

然后执行sysctl -p让它生效

检查是参数是否生效

1
2
[root@lab8106 rpmbuild]# sysctl net.ipv4.tcp_available_congestion_control
net.ipv4.tcp_available_congestion_control = bbr cubic reno

检查模块是否开启

1
2
[root@lab8106 rpmbuild]# lsmod | grep bbr
tcp_bbr                16384  0

如果需要恢复成默认的就修改成下面这个值，然后执行sysct -p恢复默认

1
2
net.ipv4.tcp_congestion_control = cubic
net.core.default_qdisc = pfifo_fast

开始测试

为了避免磁盘本身的写入速度的影响，我们直接将数据wget到内存当中去

1
[root@lab8107 ~]# cd /dev/shm

写入到这个目录当中的数据就是直接写入内存的
我们先来对比下没有丢包的时候的速度
####默认算法，无丢包率

1
2
 wget http://192.168.8.106/FreeBSD-10.2-RELEASE-amd64-dvd1.iso
2017-01-24 12:34:01 (909 MB/s) - ‘FreeBSD-10.2-RELEASE-amd64-dvd1.iso’ saved

BBR算法，无丢包率

1
2
wget http://192.168.8.106/FreeBSD-10.2-RELEASE-amd64-dvd1.iso
2017-01-24 12:36:21 (913 MB/s) - ‘FreeBSD-10.2-RELEASE-amd64-dvd1.iso’ saved

上面的两组数据基本一样，没有什么差别
下面的测试将丢包率控制到1%，然后继续测试

默认算法，1%丢包率

1
2
wget http://192.168.8.106/FreeBSD-10.2-RELEASE-amd64-dvd1.iso
2017-01-24 12:38:47 (142 MB/s) - ‘FreeBSD-10.2-RELEASE-amd64-dvd1.iso’ saved

可以看到在1%丢包率下，速度已经降为正常的1/6左右了，是一个很大的衰减

BBR算法，1%丢包率

1
2
wget http://192.168.8.106/FreeBSD-10.2-RELEASE-amd64-dvd1.iso
2017-01-24 12:40:25 (896 MB/s) - ‘FreeBSD-10.2-RELEASE-amd64-dvd1.iso’

可以看到在1%丢包率下，还能维持接近900MB/s的下载速度，相对于默认算法，相差了真是非常非常的大，google在很多情况下技术甩了其他公司真的是几条街了

总结

上面的测试通过一个简单的场景来验证了bbr算法对于丢包情况下的带宽的优化，这个对于一些提供下载服务，并且有一定的丢包率的场景的情况下，能够有很大的改善，所以算法对于技术的改变还是非常大的，很多时候就是这种异常情况下的差别，才是真正的差别

顺便提一句微博的技术经理@来去之间说的一句话：

曾经有同事问我，为啥有些新业务给老员工做，交学费，而不是市场上招人更有效率。。。俺说渣浪业务起起伏伏，如果所有战线都用雇佣兵，顺的时候势如破竹，逆的时候兵败山倒了。。公司和员工都是相互扶持的，有些新业务，员工有能力做，只是经验不足，公司多付出一些，就当给未来不顺的时候上一份保险了

相关链接

Linux Kernel 4.9 中的 BBR 算法与之前的 TCP 拥塞控制相比有什么优势？
Linux 升级内核开启 TCP BBR 实现高效单边加速

变更记录

Why Who When
创建 武汉-运维-磨渣 2017-01-24