聊聊网络加速的东东

1. 概述

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

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

1.1 单边加速

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

1.2 双边加速

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

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

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

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

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

2. 单边加速

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

2.1 部署

2.1.1 Google BBR

地址：https://github.com/google/bbr

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

#安装yum源rpm -Uvh http://www.elrepo.org/elrepo-release-6-8.el6.elrepo.noarch.rpm
#更新到最新版的内核yum --enablerepo=elrepo-kernel install kernel-ml
#vim修改grub.conf的启动首选项，修改为安装内核所在顺序（顺序从0开启）

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

2.1.2 ZetaTCP（LotServer锐速）

地址：官网或者网上第三方提供（一键安装）

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

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

2.1.3 TCP Vegas(优化版)部署

地址：https://github.com/marywangran/qvegas

安装部署：

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

2.1.4 KernelPCC部署

地址：https://github.com/giltu/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.kolsmod | grep TA#查看可用的拥塞控制算法sysctl net.ipv4.tcp_available_congestion_control#切换拥塞控制算法到TAsysctl -w net.ipv4.tcp_congestion_control=TA#核实在用的拥塞控制算法sysctl net.ipv4.tcp_congestion_control

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

2.2 加速测试

主要测试在不同的丢包率和延时情况下，采用不同的加速方式，测算其最终吞吐量（由于广域网环境复杂，测试并不能完全代表实际环境）

2.2.1 测试方法 

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

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

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

2.2.2 测试结果

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

(1) 对比曲线

(2) 详细数据

(3) 小结

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

3. 双边加速

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

3.1 部署

3.1.1 kcptun

地址：https://github.com/xtaci/kcptun

安装部署：

#直接下载二进制文件https://github.com/xtaci/kcptun/releases
#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

地址：https://github.com/d1sm/finalspeed

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

3.1.3 UDPspeeder

地址：https://github.com/wangyu-/UDPspeeder

安装部署：

#下载编译好的二进制文件，解压到本地和服务器的任意目录。https://github.com/wangyu-/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) 详细数据

说明:

2. 下载速度的单位为KB/S
3. 下载速度为0代表无法正常下载，下载速度为0

(3) 小结

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

4. 总结

上面是笔者选取了几款单边加速和双边加速软件进行实际测试的结果。不知道是不是双边加速参数调整的问题，测试的结果显示双边加速的优化效果大都不及单边加速（也有可能是因为测试的文件是采用多次压缩的问题，无法发挥双边加速的数据压缩特性）。

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

测试显示大多加速软件（包括单双边）都有其一定的适用范围：

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

END

加群交流在后台回复“加群”，添加小编微信，小编拉你进去猜您喜欢往期精选▼Linux 进程管理之四大名捕
搭建本地YUM仓库
Linux 系统安全与优化配置
Linux 命令行下的好东西
系统加固之Linux安全加固
必知必会的 crontab 从入门到精通

END

「运维圈」 知识星球 是一个网络、系统、安全的星球！主要分享、整理 运维相关的资源以及工具等。知识星球原定价：66元/年（服务时间为一年，自加入日期顺延一年）。福利目前仅需：36元/年（服务时间为一年，自加入日期顺延一年）。如何加入：扫描下方二维码，扫码付费即可加入