TCP BBR算法与锐速（serverSpeeder）在网络加速场景中效果的对比
服务器地点：Vultr日本东京机房
本地网络环境：浙江电信 100M 光纤
服务器系统：CentOS 6.8 Final
服务端程序：Shadowsocks rss python manyuser
首先在开始测试之前先测试本地网络到服务器的路由情况
我们可以看到在第9至10跳通过NTT骨干网络时产生了较大延迟，同时也有部分丢包，导致直连vultr东京服务器速度极为缓慢
Ⅰ. 直连
这是wget无任何加速插件服务器上一个100MB测试文件时的速率
观看Youtube 1080P视频
从Github（Amazon S3）上下载一个674.94 MB的ZIP文件
通过以上测试可以看出直连的情况下网络基本“炸裂”了，基本无法正常使用。
Ⅱ. 锐速
这是wget锐速服务器上一个100MB测试文件时的速率
观看Youtube 1080P视频
从Github（Amazon S3）上下载一个674.94 MB的ZIP文件
可以看出锐速抢占宽带的能力非常之强，通过违背TCP/IP公平性原则超量发包带来的速度提升非常明显
Ⅲ.TCP BBR
关于此算法的详细介绍可以看这里
同时我参考了这里提供的配置方法
这是wget TCP BBR服务器上一个100MB测试文件时的速率
观看Youtube 1080P视频
从Github（Amazon S3）上下载一个674.94 MB的ZIP文件
虽然从数据上可以看出启用BBR之后链接速度有数十倍的提升，但需要指出的是在三项测试过程中出现多次卡顿（链接速度突然变为0，等待数秒后又恢复）的情况，怀疑是受到本地网络连接至服务器的延迟波动造成的
TCP BBR试图解决两个问题：
在有一定丢包率的网络链路上充分利用带宽。
降低网络链路上的 buffer 占用率，从而降低延迟。
它并不能解决在客户端宽带都极为有限（超售）的情况下与服务器链接产生的延迟与丢包。
打个这么样个比方，中国国际网络（尤其是电信）就像一个生了病的病人，serverSpeeder就像一剂猛药，效果很明显但会伤了身子；BBR就像中药，有时候有效果有时候没效果看不同人不同地区。
Ⅳ. 总结
TCP BBR更适合部署于商业服务（视频、下载、CDN以及跨数据中心传输等）中，对于私人科学上网这些而言，除非你有国内CN2中转节点，或非电信用户，否则还是推荐使用锐速来加速跨国线路，虽然不道德，但无可奈何（摊手）
PS & 吐槽：
中国电信国际出口仅为3817Gbps（2016.6数据，来源是这里），我们假设电信全部将这些宽带开放使用（当然这是不可能的），并假设1.2亿宽带用户（数据来源这里）中只有1/20的人会有海外上网需求，那么人均宽带是多少呢？
X=3817*1024/(120000000/20)=0.65Mbps
即使我们将需求比例降至1/100人均宽带也仅有3.3Mbps，更不要提实际分配给民用的宽带远小于这个数
尤其是在民用大宽带普及率高的地方，如上海（最高200M），广东（最高1000M），国际宽带资源耗尽的情况更是频繁