依据bbr堵塞调控的云盘提速实行,聊聊互连网加快的东东

  1. 概述

CentOS 7 开启 BBR 为VPS加速

基于bbr拥塞控制的云盘提速实践,bbr拥塞云盘提速

女主宣言

云盘的速度是业界硬指标,是产品口碑和形象。传统的提速手段是大多基于代理服务器,用合适的代理连接用户与存储服务器。此方式有一定效果,但未结合国内网络情况和网络原理进行解决。bbr拥塞控制算法针对长肥网络有很好的疗效,非常适合广域网情况,实践后速度迅猛提升。本文来自奇虎360云盘事业部,让我们来了解下,360云盘是怎样通过bbr拥塞控制算法来实现提速的。

PS:丰富的一线技术、多元化的表现形式,尽在“HULK一线技术杂谈”,点关注哦!

引言

云盘作为数据存储产品,无论个人还是公司使用,其速度均是第一指标,也是用户评判云盘好坏的关键因素。速度上的提升会带来好的用户体验,以及用户粘连性。所以提速成为迫切需求。

传统tcp拥塞控制

1

广域网络环境

目前广域网普遍属于高带宽,高延迟,存在一定丢包率。网络丢包存在两种情况,第一为拥塞丢包,第二为错误丢包。错误丢包可能是网络传输过程中异常导致,大概有十万分之一的概率。

国内有很多二级运营商,它们大多为共享带宽,其网络buffer也是共享,网络共享buffer打满,会导致丢包,此类丢包造成滑动窗口折半,发送速率骤降。实则各用户带宽并未完全打满。

此类网络以下统称为长肥网络:即往返时间长,但带宽较大。

2

传统tcp拥塞控制算法

传统tcp拥塞控制目的是最大化打满网络带宽。一条链路就像水管,装满此水管需要估算管内容量。

管内容量 = 水管粗细(链路带宽) * 水管长度(往返延迟)

拥塞控制过程:慢启动、加性增、乘性减。开始指数增加发送窗口,遇到丢包快速折半发送窗口,降低发送速率。

3

 tcp拥塞控制无法解决如下问题

无法定位丢包原因

无法区分丢包是拥塞导致还是错误导致,如果是网络传输错误导致丢包,其实还未打满带宽。在有一定丢包率的长肥网络中发送窗口会收敛到很小,导致发包速率很小。

缓冲区膨胀问题

网络缓冲区膨胀,网络中有一些buffer,用于吸收波动的流量。开始阶段以指数级速率快速发包,导致buffer快速打满,buffer满后会产生丢包。丢包造成发送窗口骤降,而后发送窗口和buffer都会逐渐下降收敛。此情况未能打满带宽以及buffer使用率。认为此类丢包是带宽打满,实则不然,只是开始过快的增长导致buffer打满丢包而已。

图2.1 缓冲区膨胀现象

bbr拥塞控制

1

解决上述两类问题

  1. 不考虑丢包情况,因为无法区分拥塞丢包,错误丢包。

2. 缓冲区膨胀现象是同时估计带宽和延迟导致的。因为发送窗口需要这两参数计算出管内容量,但同时计算会导致不准。例如:要测最大带宽需灌满水管,此时延迟必然高,因为缓冲区占满,包排队需时间。而要测最低延迟,需网络流量低,此时缓冲区基本为空,延迟低,但此时管内带宽估值也低。所以无法同时测量带宽和延迟的最好情况,即最大带宽和最低延迟。这就是本质,为什么传统tcp在长肥网络中很难打满带宽。

解决办法:分别估算带宽和延迟,以计算出最合适的管内容量。

2

bbr拥塞控制过程

慢启动

指数增长发包,不理会丢包,不折半窗口,只检查有效带宽是否还再增长,直到有效带宽不再增长为止。有效带宽是指还未开始占用buffer。

排空阶段

慢启动后,发包量依然有3倍管内容量,此时降低发包速率,以免管中多余包占满buffer,导致丢包。

带宽探测阶段

每8个往返为一个周期,第一个往返,bbr尝试以 5/4速率增大发包,以估算带宽是否打满,第二个周期以 3/4速率降低发包,以排空buffer中的冗余包,避免发生膨胀。剩下6个往返以新的带宽估算速率发包。如此为一个周期,不断探测直到打满真实带宽,如图3.1所示。

延迟探测阶段

每隔10秒,如果未发现新的最低延迟。此时发送窗口减到4个包,以此段时间发包的最低延迟作为估值。然后发送窗口回到之前的状态。

图3.1 带宽检测持续增长,绿色为发包数量,蓝色为延迟

图3.2 丢包率和有效带宽示意图。绿色为bbr,红色为传统tcp

3

bbr小结

bbr开始阶段不会迅猛打满管道,主要是避免缓冲区膨胀带来的丢包和延迟,后续交替探测带宽和延迟。探测带宽时,先增大发送速率后减小,也是避免缓冲区膨胀问题,丢包率降低不断收到有效ack,进而持续增大发送窗口,如此轮回得到最大带宽。探测延迟时,发送窗口降为4个包,此时缓冲区未占满,管内通畅,探测到的延迟也是低而准的。交替探测带宽和延迟得到准确的管内容量,排空方式能避免缓冲区膨胀带来的丢包和延迟。

4

bbr适合场景

  1. 存在一定丢包率的高带宽,高延迟网络。

  2. buffer较小的慢接入网络。

bbr在云盘中的实践

内核升级

代理服务器内核升级到4.9以上

开启bbr拥塞控制算法

echo "net.core.default_qdisc=fq" >> /etc/sysctl.conf

       echo "net.ipv4.tcp_congestion_control=bbr" >> /etc/sysctl.conf

       sysctl -p

       sysctl net.ipv4.tcp_available_congestion_control

       sysctl -n net.ipv4.tcp_congestion_control

调整tcp内核参数

调整tcp内核参数,让滑动窗口大小突破64kb

sysctl net.ipv4.tcp_window_scaling=1

提速结果

人均速度提升

图4.1 人均速度图

人均速度提升:50%左右

速度区域占比提升

图4.2 速度区域占比图,蓝色为1M/s- 2M/s,绿色为2M/s以上

1M以上人数占比提升:100%左右

参考文献:

[1] Cardwell, Neal, et al. "BBR: Congestion-Based Congestion Control." Queue14.5 (2016): 50.

扫描下方二维码了解更多内容

一谈到网络加速,网友的第一反应就是网游加速器。例如最近热门的游戏绝地大逃杀,热门主播们在玩游戏前经常会挂上一款网游加速器。尤其是在欧服,美服,更是必不可少。网游加速器主要用于改善网络丢包率,降低网络延时,提升客户端和游戏服务器之间链接的稳定性。

什么是BBR

TCP BBR是谷歌出品的TCP拥塞控制算法。BBR目的是要尽量跑满带宽,并且尽量不要有排队的情况。BBR可以起到单边加速TCP连接的效果。替代锐速再合适不过,毕竟免费。

Google提交到Linux主线并发表在ACM queue期刊上的TCP-BBR拥塞控制算法。继承了Google“先在生产环境上部署,再开源和发论文”的研究传统。TCP-BBR已经再YouTube服务器和Google跨数据中心的内部广域网(B4)上部署。由此可见出该算法的前途。

TCP-BBR的目标就是最大化利用网络上瓶颈链路的带宽。一条网络链路就像一条水管,要想最大化利用这条水管,最好的办法就是给这跟水管灌满水。

网游加速器当然是可以归属到网络加速范围内,且网络加速器所用的技术众多,包括协议优化,数据压缩,数据重发,路由自动择优等等。网游加速器只是网络加速的上层应用,笔者这里聊的是稍微是底层一些的技术,主流的网络加速技术大致可以分为单边加速双边加速

BBR解决了两个问题:

再有一定丢包率的网络链路上充分利用带宽。非常适合高延迟,高带宽的网络链路。

降低网络链路上的buffer占用率,从而降低延迟。非常适合慢速接入网络的用户。

项目地址:

Google 在 2016年9月份开源了他们的优化网络拥堵算法BBR,最新版本的 Linux内核(4.9-rc8)中已经集成了该算法。

对于TCP单边加速,并非所有人都很熟悉,不过有另外一个大名鼎鼎的商业软件“锐速”,相信很多人都清楚。特别是对于使用国外服务器或者VPS的人来说,效果更佳。

网上有很多在 Debian 和 Ubuntu 系统下启用 BBR 的教程,我就不粘贴了,我自己一直用的是 CentOS,本文介绍一下在 64位 CentOS 7 系统下开启BBR的方法。

升级内核

1.1 单边加速

第一步首先是升级内核到支持BBR的版本:

# 下载 linux 内核 4.9-rc8 的 deb 包wget 加压缩下载好的 deb 包ar x linux-image-4.9.0-rc8-amd64-unsigned_4.9~rc8-1~exp1_amd64.deb# 执行完上面的命令后,会得到 *control.tar.gz*, *data.tar.xz*, *debian-binary* 三个文件# 继续解压 *data.tar.xz* 文件tar -Jxf data.tar.xz# 执行完这一步的命令之后,会得到 *boot*, *lib*, *usr* 三个文件夹# 安装可引导的内核镜像install -m644 boot/vmlinuz-4.9.0-rc8-amd64 /boot/vmlinuz-4.9.0-rc8-amd64# 复制内核模块cp -Rav lib/modules/4.9.0-rc8-amd64 /lib/modules/# 分析可载入模块的相依性,产生模块依赖的映射文件depmod -a 4.9.0-rc8-amd64# centos 6 以上版本执行这条命令dracut -f -v --hostonly -k '/lib/modules/4.9.0-rc8-amd64'/boot/initramfs-4.9.0-rc8-amd64.img 4.9.0-rc8-amd64# 更新 grub2 的配置文件grub2-mkconfig -o /boot/grub2/grub.cfg

故名思议,只需要在tcp的一端部署的加速技术。因为部署容易,变动不大,所以应用范围较广,包括目前各种商业的的动态加速技术,也大都包含单边加速技术。但也正因为其在tcp一端部署的特性,其必须兼容标准的tcp协议,导致其能优化和调整的地方不如双边加速那么多。绝大大多数的单边加速都是通过优化tcp的拥塞控制算法来实现tcp加速的。

调整GRUB启动顺序

在安装好新版本内核以后,要先用新安装的内核引导系统看看能否正常启动,下面是直接调整 GRUB2 启动顺序的命令:

# 查看可用的启动项cat /boot/grub2/grub.cfg |grep CentOS

执行完这条命令以后,能看到多条以 menuentry 开头的项目,每一项都是一个内核引导选项,紧跟在 menuentry 后面,以单引号包围的部分就是这一条启动项的 “title”,比如我的是:

menuentry 'CentOS Linux (4.9.0-rc8-amd64) 7 (Core)' --class rhel fedora --class gnu-linux ....menuentry 'CentOS Linux (3.10.0-327.36.3.el7.x86_64) 7 (Core)' --class rhel fedora --class gnu-linux ...menuentry 'CentOS Linux (0-rescue-731edbf944d54068a3249dee56ed3727) 7 (Core)' --class rhel fedora --class gnu-linux --class gnu ...

可以看到第一条单引号中的就是我们新安装的 4.9-rc8 内核,我们要使用这一项来引导。

# 设置默认 4.9-rc8 的引导项为默认引导项grub2-set-default "CentOS Linux (4.9.0-rc8-amd64) 7 (Core)"# 验证一下,如果上一条命令执行成功,执行下面的命令应该能看到 `saved_entry=CentOS Linux (4.9.0-rc8-amd64) 7 (Core)`grub2-editenv list# 重新生成 grub2 的配置文件grub2-mkconfig -o /boot/grub2/grub.cfg# 重启系统reboot

1.2 双边加速

修改sysctl 开启 BBR

重启系统之后,通过 uname -a 或者其它命令可以看到我们的内核已经是 4.9.0-rc8-amd64 了,接下来开启 BBR

echo "net.core.default_qdisc=fq" >> /etc/sysctl.confecho "net.ipv4.tcp_congestion_control=bbr" >> /etc/sysctl.conf# 加载 /etc/sysctl.conf 文件中的参数并显示,主要看看有没有报错的设置(显示的结果与你的配置文件内容有关)sysctl -p# 验证 bbr 是否开启,如果成功,应该会看到 net.ipv4.tcp_congestion_control = bbrsysctl net.ipv4.tcp_available_congestion_control# 依然是验证,如果成功,应该会看到类似 tcp_bbr163843 这样的文字lsmod | grep bbr

7 开启 BBR 为VPS加速 什么是BBR TCP BBR是谷歌出品的TCP拥塞控制算法。BBR目的是要尽量跑满带宽,并且尽量不要有排队的情况。BBR可以起...

相较于单边加速,双边加速是双端部署,如果是服务器对服务器,那么两边的服务器上都要进行部署,如果是服务器对客户端,那么除了服务器端部署外,客户端也要安装软件。

因为是双边,所以基本上可以说自己的天下了。可以采用各种优化加速技术,例如实现自己更高效的传输协议,数据缓存,流量压缩,多路径转发等。

因为双边加速并未明确的标准或者规范限制,所以各厂商的具体实现也往往不同,但是实现原理大多相同。

笔者自己也经常会使用一些网络加速软件,但是具体加速性能好坏也从来没有对比过,这里主要选择了几款开源单边和双边加速软件,对其效果进行测试对比。我们线上业务也有采用类似BBR的单边加速,尤其是针对移动端效果显著,而网宿,腾讯之类的商业CDN厂商更是很早就已经支持,可以针对特定的网络场景进行优化。

接下来是无聊的部署和测试数据,不感兴趣的可以直接跳到总结。

  1. 单边加速

常用的单边加速有FastTCP,ZetaTCP,TCP Vegas, KernelPCC以及最近谷歌开源的BBR等。

2.1 部署2.1.1 Google BBR

地址:

安装配置:开启BBR优化算法内核版本必须 4.9 以上,可以使用elrepo的yum源,直接yum安装

#安装yum源 rpm -Uvh -release-6-8.el6.elrepo.noarch.rpm #更新到最新版的内核 yum enablerepo=elrepo-kernel install kernel-ml #vim修改grub.conf的启动首选项,修改为安装内核所在顺序

#reboot重启服务器,切换拥塞控制算法到bbr sysctl -w net.ipv4.tcp_congestion_control=bbr #核实在用的拥塞控制算法 sysctl net.ipv4.tcp_congestion_control

2.1.2 ZetaTCP

地址:官网或者网上第三方提供

安装配置:安装安装说明,一路安装,注意选择跟自己内核相同或者相近的选项。安装成功后不需要重启服务器自动生效

注意:ZetaTCP为商业闭源产品,建议在线上环境上使用时要慎重。

2.1.3 TCP Vegas(优化版)部署

地址:

安装部署:

#升级系统内核到4.9后,切换到qvegas的源代码目录,编译,告警信息可以忽略 make #加载内核模块 insmod tcp_qvegas.ko lsmod | grep qvegas #查看可用的拥塞控制算法 sysctl net.ipv4.tcp_available_congestion_control #切换拥塞控制算法到qvegas sysctl -w net.ipv4.tcp_congestion_control=bbr #核实在用的拥塞控制算法 sysctl net.ipv4.tcp_congestion_control

2.1.4 KernelPCC部署

地址:

安装部署:

#升级系统内核到4.9后,编辑tcp_TA.c,替换NET_INC_STATS_BH为NET_INC_STATS,替换NET_ADD_STATS_BH为NET_ADD_STATS,保存。 #切换到KernelPCC的源代码目录,编译,告警信息可以忽略 make #加载内核模块 insmod tcp_TA.ko lsmod | grep TA #查看可用的拥塞控制算法 sysctl net.ipv4.tcp_available_congestion_control #切换拥塞控制算法到TA sysctl -w net.ipv4.tcp_congestion_control=TA #核实在用的拥塞控制算法 sysctl net.ipv4.tcp_congestion_control

注意:代码中的name即为算法名称

2.2 加速测试

主要测试在不同的丢包率和延时情况下,采用不同的加速方式,测算其最终吞吐量

2.2.1 测试方法

开箱即用,不调整任何参数,即使用默认的参数。测试在两台千兆服务器之间进行wget下载测试,服务器的地址分别位于河北和江苏。测试文件为100M文件。统计下载时间,三次测试取其平均值作为有效值。

分别测试各加速软件在延时17ms,50ms和100ms,其丢包率分别为0%, 10%,30%,50%网络环境下的下载表现。

采用tc模拟丢包率和延时。

2.2.2 测试结果

NOMAL:河北-江苏 丢包0% 延时17ms

(1) 对比曲线

(2) 详细数据

(3) 小结

各阻塞控制算法在低延迟和低丢包率的情况下表现最优,其中bbr的下载性能最好。随着延时的增加,各下载软件的下载性能也随之降低。其中bbr和zetatcp在高延时的网络环境下表现良好,bbrzetatcp。随着丢包率的增加,各下载软件的下载性能也随着降低。其中zetatcp和bbr在高丢包的网络环境下表现良好。如果是高延时和高丢包环境下,zetatcp表现良好。3. 双边加速

常用的双边加速有kcptun,finalspeed以及UDPspeeder等。

3.1 部署3.1.1 kcptun

地址:

安装部署:

#直接下载二进制文件 #KCP 客户端 ./client_linux_amd64 -r KCP_SERVER_IP:4000 -l :8388 -mode fast2 #KCP 服务段 ./server_linux_amd64 -t TARGET_IP:8388 -l :4000 -mode fast2

上面命令会给8388端口建立端口转发,具体数据流如下

应用- KCP 客户端(8388/tcp) - KCP 服务端(4000/udp) - 目标服务器端(8388/tcp)

将原始链接封装进隧道

应用 - 目的服务器 (8388/tcp)

3.1.2 finalspeed

地址:

安装部署:该地址已经暂停更新,根据页面信息已经改是闭源改为商业产品了。可以使用第三方提供的一键安装包。

3.1.3 UDPspeeder

地址:-/UDPspeeder

安装部署:

#下载编译好的二进制文件,解压到本地和服务器的任意目录。 -/UDPspeeder/releases #在server端运行: ./speederv2 -s -l0.0.0.0:4096 -r127.0.0.1:7777 -f20:10 -k passwd #在client端运行: ./speederv2 -c -l0.0.0.0:3333 -r x.x.x.x:4096 -f20:10 -k passwd

现在client和server之间建立起了tunnel。想要连接x.x.x.x:7777,只需要连接 127.0.0.1:3333。来回的所有的udp流量会被加速。

默认情况下只能加速udp流量,如果是其他协议的流量需要配合vpn之类的使用。

3.2 加速测试3.2.1 测试方法

测试方法同单边加速

3.2.2 测试结果

(1) 对比曲线

(2) 详细数据

说明:

下载速度的单位为KB/S下载速度为0代表无法正常下载,下载速度为0

(3) 小结

其中正常下载的下载性能在低延时和低丢包率的网络环境下最好。随着延时的增加,各下载软件的下载性能也随之降低。其中kcptun和finalspeed在高延时的网络环境下表现良好。随着丢包率的增加,各下载软件的下载性能也随着降低。其中kcptun和finalspeed在高延时的网络环境下表现良好。如果是高延时和高丢包环境下,kcptun表现良好。4. 总结

上面是笔者选取了几款单边加速和双边加速软件进行实际测试的结果。不知道是不是双边加速参数调整的问题,测试的结果显示双边加速的优化效果大都不及单边加速。

注意:双边加速大多都有采用多发的策略,如果部署双边加速,一定要留意服务器是否按照流量进行收费。

测试显示大多加速软件都有其一定的适用范围:

对于低延时低丢包率的网络情况,不采用任何加速或者使用bbr或者zetatcp加速比较ok。在中等丢包率使用bbr无疑是最好的选择。高丢包率高延时(100ms)的网络环境下,使用zetatcp或者双边加速kcptun比较合适。尤其是zetatcp和双边加速kcptun在延时100ms,丢包率50%的情况下都能发出会良好的下载加速效果,实在是让人印象深刻。

原文来自微信公众号:运维军团

本文由澳门威斯尼人平台登录发布于服务器&运维,转载请注明出处:依据bbr堵塞调控的云盘提速实行,聊聊互连网加快的东东

相关阅读