BBR,解决海外VPS网络堵塞问题

2022-5-16 18:48| 发布者: Hocassian| 查看: 84| 评论: 0|原作者: 樱花庄的白猫

摘要:
C:\Users\Administrator\Downloads\2019-10-14-0-25-44-134316832006099-樱花庄的白猫 ねこ・しろ・ましろ-采集的数据-后羿采集器.html

标题

BBR,解决海外VPS网络堵塞问题

标题链接

https://2heng.xin/2017/10/04/bbr/

post-date

发布于 2017-10-04

post-meta

8,836 热度

评价数

7 条评论

分类

野生技术协会

正文

BBR allows the 500,000 WordPress sites on our digital experience platform to load at lightning speed. 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. Network innovations like BBR are just one of the many reasons we partner with GCP.

— Jason Cohen, Founder and CTO, WP Engine

BBR让500,000个建立在我们平台上的WordPress站点以闪电般的速度访问成为了可能。在Google的测试中,BBR的吞吐量最高可以达到目前基于丢包的最好的TCP协议的2700倍,排队延时可以降低25倍。像BBR这样的网络创新只是我们与GCP (Google Cloud Platform)合作的许多原因之一。

那么BBR究竟是什么呢?简单说,BBR ("Bottleneck Bandwidth and Round-trip propagation time",直译“瓶颈带宽和往返传播时间”)是Google开发的一种新型拥塞控制(TCP协议)算法。

黑科技BBR
BBR好处都有啥? 谁说对了就给他。——网站加速,Shadowsocks/ShadowsocksR加速,只要是流量都能加速。

前段时间一直收到全国各地的反馈,很多说我博客访问速度慢,有人直言是我网站优化差。虽然优化肯定不敢说好,但是也不至于会导致几十秒的加载时间吧?一番调查后发现反映基本是来自电信用户的,我真的是帮电信背锅了啊。 #—_—

我的初步判断电信方面的QoS设置造成了严重的丢包,当时我测试的结果是电信网络下丢包率达到了50%以上。服务器一直使用的是Vultr的VPS,最开始我使用的是他们的欧洲线路,试过伦敦、法兰克福两个机房,速度都很快(即使是电信),后来因为需要日本IP上一些网站,所以换到了东京机房,结果从此之后就出现了电信网络下使用Shadowsocks访问变慢的情况(20M的带宽下Shadowsocks速度只能达到1M的水平)。补充一下,我的服务器上同时也搭载了Shadowsocks服务(我会说只是顺便搭个博客地吗),所以对速度要求是很高的,所以实际上通过Shadowsocks是最有效的服务器访问速度测试方法(博客一个网页就那么几百k,怎么测速,笑话)。

那么QoS又是什么呢?QoS(Quality of Service,服务质量)指一个网络能够利用各种基础技术,为指定的网络通信提供更好的服务能力, 是网络的一种安全机制, 是用来解决网络延迟和阻塞等问题的一种技术。 在正常情况下,如果网络只用于特定的无时间限制的应用系统,并不需要QoS,比如Web应用,或E-mail设置等。但是对关键应用和多媒体应用就十分必要。当网络过载或拥塞时,QoS 能确保重要业务量不受延迟或丢弃,同时保证网络的高效运行。

What's TCP?

据此可以推断,从欧洲进入中国的流量并不多,因此Vultr欧洲服务器没有怎么受到电信QoS的影响,至少白天是这样的,所以一直有说法”Vultr美服欧服白天极快晚上贼慢“,这一点用欧洲机房时我是深有体会的。但是于日本服务器就很不一样了,用MTR追踪了三大运营商及校园网到Vultr日本服务器的路由信息,结果如下:

电信宽带

|------------------------------------------------------------------------------------------|
| WinMTR statistics |
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| 101.95.122.54 - 0 | 8 | 8 | 4 | 19 | 93 | 12 |
| 101.95.122.53 - 0 | 8 | 8 | 2 | 18 | 94 | 9 |
| 124.74.209.101 - 0 | 8 | 8 | 4 | 20 | 93 | 9 |
| 101.95.120.238 - 0 | 8 | 8 | 5 | 19 | 93 | 9 |
| 202.97.57.233 - 20 | 5 | 4 | 2 | 12 | 27 | 17 |
| 202.97.90.57 - 0 | 8 | 8 | 3 | 18 | 86 | 10 |
| 202.97.51.62 - 20 | 5 | 4 | 98 | 114 | 163 | 99 |
| ae-0.r30.tokyjp05.jp.bb.gin.ntt.net - 20 | 5 | 4 | 88 | 117 | 196 | 93 |
| ae-16.r01.tokyjp05.jp.bb.gin.ntt.net - 0 | 7 | 7 | 114 | 125 | 186 | 114 |
| No response from host - 100 | 1 | 0 | 0 | 0 | 0 | 0 |
| vl625-ds1-b5-1810.tyo1.choopa.net - 0 | 8 | 8 | 89 | 101 | 163 | 93 |
| No response from host - 100 | 1 | 0 | 0 | 0 | 0 | 0 |
| 45.xx.xx.xxx - 0 | 8 | 8 | 88 | 101 | 163 | 93 |
|________________________________________________|______|______|______|______|______|______|

移动宽带

|------------------------------------------------------------------------------------------|
| WinMTR statistics |
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| . - 0 | 4 | 4 | 2 | 8 | 14 | 7 |
| . - 0 | 4 | 4 | 2 | 5 | 10 | 10 |
| . - 0 | 4 | 4 | 3 | 16 | 28 | 28 |
| 221.176.19.49 - 0 | 4 | 4 | 10 | 17 | 26 | 10 |
| 221.176.22.10 - 0 | 4 | 4 | 3 | 11 | 18 | 10 |
| No response from host - 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| ae-3.r01.tkokhk01.hk.bb.gin.ntt.net - 0 | 2 | 2 | 95 | 95 | 96 | 95 |
| ae-3.r01.tkokhk01.hk.bb.gin.ntt.net - 0 | 4 | 4 | 40 | 71 | 107 | 42 |
| ae-18.r30.tokyjp05.jp.bb.gin.ntt.net - 0 | 4 | 4 | 88 | 90 | 95 | 89 |
| ae-16.r01.tokyjp05.jp.bb.gin.ntt.net - 0 | 2 | 2 | 88 | 89 | 90 | 90 |
| ae-0.choopa.tokyjp05.jp.bb.gin.ntt.net - 0 | 4 | 4 | 87 | 97 | 107 | 103 |
| vl625-ds1-b5-1810.tyo1.choopa.net - 0 | 4 | 4 | 88 | 94 | 110 | 88 |
| No response from host - 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 45.xx.xx.xxx - 0 | 1 | 1 | 88 | 88 | 88 | 88 |
|________________________________________________|______|______|______|______|______|______|

联通4G

|------------------------------------------------------------------------------------------|
| WinMTR statistics |
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| MAshiro - 0 | 4 | 4 | 3 | 3 | 5 | 3 |
| MAshiro - 0 | 4 | 4 | 28 | 34 | 43 | 28 |
| No response from host - 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 27.115.81.1 - 0 | 2 | 2 | 34 | 40 | 47 | 34 |
| 139.226.197.109 - 0 | 4 | 4 | 33 | 40 | 52 | 41 |
| 219.158.6.161 - 0 | 2 | 2 | 60 | 78 | 97 | 60 |
| 219.158.5.158 - 0 | 1 | 1 | 98 | 98 | 98 | 98 |
| 219.158.3.182 - 0 | 4 | 4 | 47 | 65 | 98 | 47 |
|xe-0-2-0-3-3.r01.osakjp02.jp.bb.gin.ntt.net - 0 | 4 | 4 | 135 | 139 | 148 | 137 |
| ae-6.r24.osakjp02.jp.bb.gin.ntt.net - 0 | 4 | 4 | 140 | 148 | 158 | 158 |
| No response from host - 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| ae-16.r01.tokyjp05.jp.bb.gin.ntt.net - 0 | 4 | 4 | 140 | 151 | 173 | 148 |
| No response from host - 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| vl625-ds1-b5-1810.tyo1.choopa.net - 0 | 4 | 4 | 140 | 147 | 162 | 147 |
| No response from host - 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 45.xx.xx.xxx - 0 | 4 | 4 | 138 | 149 | 172 | 144 |
|________________________________________________|______|______|______|______|______|______|

校园网

TracePing report for: 45.xx.xx.xxx:
#: Hop IP address snt/rcv loss% StDevRTT min/avg/max Jitter avg/max, ms
1: 0.0.0.0 0/0 0% 0 0.0/0/0 0/0
2: 192.168.202.177 219/151 31% 25 1/6/213 8/212
3: 192.168.200.18 220/139 36% 15 2/4/133 5/131
4: 10.255.29.1 220/147 33% 23 2/7/185 6/183
5: 10.255.249.81 221/135 38% 15 2/5/153 4/150
6: 10.255.249.45 221/128 42% 15 2/5/154 5/151
7: 10.255.38.250 221/141 36% 19 2/7/142 6/139
8: 202.112.27.1 221/140 36% 9 2/4/88 3/85
9: 101.4.115.174 221/112 49% 16 3/5/174 4/171
10: 101.4.117.30 208/118 43% 13 21/28/153 9/126
11: 101.4.116.118 221/110 50% 17 26/35/144 0/94
12: 101.4.112.69 41/0 100% 0 0.0/0/0 0/0
13: 101.4.117.173 38/0 100% 0 0.0/0/0 0/0
14: 101.4.117.98 29/0 100% 0 0.0/0/0 0/0
15: 101.4.117.214 19/0 100% 0 0.0/0/0 0/0
16: 66.110.59.181 219/120 45% 16 186/190/328 6/141
17: 66.110.59.9 218/124 43% 19 198/203/354 9/155
18: 63.243.251.2 217/102 52% 26 198/203/369 12/171
19: 63.243.205.74 220/82 62% 29 199/207/352 16/152
20: 63.243.205.2 219/133 39% 22 199/203/402 7/202
21: 209.58.116.22 220/147 33% 20 199/206/349 11/150
22: 129.250.3.162 220/123 44% 42 203/210/645 16/442
23: 129.250.6.118 218/127 41% 18 203/207/360 8/157
24: 129.250.5.77 218/103 52% 31 136/181/410 19/253
25: 129.250.7.85 211/99 53% 45 139/187/552 25/367
26: 45.xx.xx.xxx 1/1 0% 0 286/291/295 NA/NA

查询上面的路由IP,发现电信从上海的节点(202.97.90.57)直连了位于东京的电信出口(202.97.51.62);联通通过北京的国际出口(219.158.3.182)出境,跳转至日本NTT.COM的骨干网;移动通过香港的 出口跳转到NTT.COM的骨干网;而校园网是先汇总到北京,通过洛杉矶的教育网网国际出口(101.4.117.214),再通过Tata的一系列线路绕回日本的。

所以总结下来,因为移动和联通使用的是位于国内的骨干网络出口连接到境外网络的,而电信使用了其位于境外的骨干网络出口,所以当境外流量过大时,电信的国外接口显然时没有能力保障访问速度的,因而出现了严重丢包(因为我已经启用了BBR,所以以上的MTR数据的丢包并不严重)。另外值得一提的时教育网,可能很少有人 意识到它的存在吧?尝试过各个国家的网站,似乎教育网出境流量都必须到美国绕一圈。像我们学校的校园网限速270kb/s,听说有的学校又是每月限流量,为什么限制呢?足以说明其承载量不高,估计他们的QoS也比电信好不到哪去。

所以呢,对于这种运营商QoS造成的网络不畅,唯一的办法就是从TCP协议上入手。那么我所要使用的TCP协议,就是今天要推荐的BBR了。据说"BBR has significantly increased throughput and reduced latency for connections on Google's internal backbone networks and google.com and YouTube Web servers." 然而嘛,国内是直连不了的,所以你通过各种VPN代理之后代理隧道流量的TCP协议是遵循你的代理服务器的。对于Shadowsocks/ShadowsocksR的加速,网上也有好多方法(据说百度上Shadowsocks被关键词屏蔽了? :huaji: ),其中主流的是什么伪装成80端口流量啊(SS/SSR默认的是443 SSL流量),恕我直言太麻烦。而且今天我要解决的还有网站访问速度,https流量怎么伪装? :huaji:

毕竟不是专业的,关于BBR,我也不能介绍更多。BBR这项技术详细记载于 Neal Cardwell, Yuchung Cheng, C. Stephen Gunn, Soheil Hassas Yeganeh, Van Jacobson 等人今年2月发表在ACM上的这篇学术论文:

BBR: Congestion-Based Congestion Control

该技术最终被Google发扬光大,并且已经整合到Linux内核里了。下面是一键替换为BBR内核的脚本(请先看注意事项):

$ sudo su
# Debian / Ubuntu 14.04 +
$ wget -N --no-check-certificate https://raw.githubusercontent.com/ToyoDAdoubi/doubi/master/bbr.sh && chmod +x bbr.sh && bash bbr.sh
# CentOS 6+ / Debian 7+ / Ubuntu 12+
$ wget -N --no-check-certificate https://github.com/teddysun/across/raw/master/bbr.sh && chmod +x bbr.sh && bash bbr.sh

由于是更换Linux内核,所以更新后需要重启,同时存在一定无法启动的风险,所以请注意:

  1. 使用前一定备份重要数据;
  2. 建议用于VPS(另注意BBR不支持Openvz虚拟化技术,具体咨询你的主机商);
  3. 当系统环境比较复杂时,善用Snapeshot功能,以Vultr为例,可以免费创建系统快照,然后把快照装到一个Instance上测试;

安装后可再次运行脚本检测是否安装成功。

实际检测下来,更换BBR内核后,同一时间内,相同的电信网络下,通过ShadowsocksR访问YouTube的速度能从几十Kb/s提升到3.2 Mb/s(我的带宽上限),博客首页的加载速度也明显提升。所以说BBR无疑是个黑科技。

参考

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

如果你希望手动更换内核请看这些:
Linux内核源文件
开启TCP BBR拥塞控制算法
Debian/Ubuntu TCP拥塞控制技术
TCP BBR Quick-Start: Building and Running TCP BBR on Google Compute Engine
Increase your Linux server Internet speed with TCP BBR congestion control

更多关于BBR的技术细节可以看这些:
BBR: Congestion-Based Congestion Control
BBR, the new kid on the TCP block
TCP BBR congestion control comes to GCP – your Internet just got faster
【知乎】Linux Kernel 4.9 中的 BBR 算法与之前的 TCP 拥塞控制相比有什么优势?
中国电信CN2网络介绍

Q.E.D.

作者

Mashiro


路过

雷人

握手

鲜花

鸡蛋

最新评论

返回顶部