前言
如果你有订阅一些科技新闻,应该会有看过内核在4.9当中加入了一个新的算法,来解决在有一定的丢包率的情况下的带宽稳定的问题,这个是谷歌为我们带来的干货,新的 TCP 拥塞控制算法 BBR (Bottleneck Bandwidth and RTT),谷歌一向的做法是,先上生产,然后发论文,然后有可能开源,所以这个已经合并到了内核4.9分支当中,算法带来的改变在出的测试报告当中有很详细的数据展示,这个看多了可能反而不知道到底会有什么明显改变,特别是对于我们自己的场景
那么本篇就是来做一个实践的,开看看在通用的一些场景下,这个改变有多大,先说下结果,是真的非常大
实践
还是我的两台机器lab8106和lab8107,lab8106做一个webserver,lab8107模拟客户端,用简单的wget来进行测试,环境为同一个交换机上的万兆网卡服务器
我们本次测试只测试一种丢包率的情况就是1%,有兴趣的情况下,可以自己去做些其他丢包率的测试,大多数写在丢包率20%以上的时候,效果可能没那么好,这个高丢包率不是我们探讨的情况,毕竟不是常用的场景
安装新内核
内核可以自己选择4.9或者以上的进行安装,也可以用yum安装,这里只是测试,就yum直接安装
yum --enablerepo=elrepo-kernel install kernel-ml
修改启动项
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进行控制的,也就是一条命令就可以了,这个还可以做其他很多控制,可以自行研究
tc qdisc add dev enp2s0f0 root netem loss 1%
如果需要取消限制
tc qdisc del root dev enp2s0f0
设置新的算法
讲下面的两个配置文件添加到/etc/sysctl.conf
net.ipv4.tcp_congestion_control=bbr
net.core.default_qdisc=fq
然后执行sysctl -p让它生效
检查是参数是否生效
[root@lab8106 rpmbuild]# sysctl net.ipv4.tcp_available_congestion_control
net.ipv4.tcp_available_congestion_control = bbr cubic reno
检查模块是否开启
[root@lab8106 rpmbuild]# lsmod | grep bbr
tcp_bbr 16384 0
如果需要恢复成默认的就修改成下面这个值,然后执行sysct -p恢复默认
net.ipv4.tcp_congestion_control = cubic
net.core.default_qdisc = pfifo_fast
开始测试
为了避免磁盘本身的写入速度的影响,我们直接将数据wget到内存当中去
[root@lab8107 ~]# cd /dev/shm
写入到这个目录当中的数据就是直接写入内存的
我们先来对比下没有丢包的时候的速度
默认算法,无丢包率
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算法,无丢包率
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%丢包率
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%丢包率
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 |