前言
其实很长的一段时间，我一直都想着怎么利用BBR提升服务器的上传速度来达到更好的体验，为此我调整了内核的网络参数，又在各个流控算法（fq、fq_pie、cake、fq_codel）里来回选择，最后似乎也看不出什么特别好的算法，后来我一想，既然各种算法都不能非常好的加快我的VPS到国内的速度，那就使用非常暴力的锐速吧，虽然不大稳定，但是至少速度上去了。
于是，为了安装锐速，我又折腾内核，让其与版本和锐速匹配，结果显而易见：新内核降级到旧内核，引发了一堆兼容性问题，然后又折腾各个软件的兼容性…
终于，最后折腾了半天，在非常暴力的设置下，高峰终于可以跑到100Mbps了，看起来似乎是艰辛万苦的大胜利，但是慢慢的，我发觉，自己曾经的这些想法似乎并不是那么正确的。随着越来越多的深入了解，我现在对自己曾经的一些无知的行为感到十分羞愧。
我想在这里借此，发表一些我现在的见解，也是想防止别人误读一些文章，走了很多的弯路。
锐速暴力发包很完美？
我相信，能够接触到锐速的人，都是在这个圈子里的元老级别人物了，锐速其实一直有一个出了名的缺点：断流。没错，每当你打开sftp终端，想着有了锐速加持可以开心愉悦地从服务器上高速拉取文件的时候，还没到拉取完成，突然下载速度降为0KB/s，之前的努力全部白费，是一种什么心情。
是的，很多情况下，我们过多地看重了下载速度本身，而忘记了至关重要的传输稳定性，一个不遵守互联网传输基本规则的流氓，无关骨干网的拥堵情况，无差别地暴力发包，最终会受到各大ISP骨干路由的制裁（直接掐断连接），这种现象就是断流。使用锐速从道义上来说，本来就是不道德的，它只会为了自己的利益持续增加骨干网本已日益严重的拥堵情况，被制裁也是情理之中的事情。
锐速的副作用广从这里来看就已经不值得再使用，但是事实上，锐速的副作用不仅限于对骨干网造成的影响，对于服务端的用户本身也极不友好。我相信很多朋友在使用锐速的时候都会发现锐速对CPU的要求颇高，这对于手头预算有限的朋友来说实在是太难了。
到此，我们看出来，评价一个堵塞算法的好坏，不仅应该看它的速率，也应该看它的资源占用情况。但是还有一大因素，叫做流量有效率，即计算发出去的包能够有多少达到目标主机，如果可以全部到达，则为100%，它应该越小越好。未经过严格的测试，仅在日常互联网的文件拉取测试中，就可以发现锐速的流量消耗远远超过cubic、reno、BBR和BBR2等算法，锐速不管路由的拥堵情况，一直不予妥协，疯狂发包，终究要付出惨痛的代价。为了提升10%的速度，却要忍受只有约40%的流量有效率，这样的浪费是无法接受的。
所以，锐速早就应该随着时代被丢弃了，一个好的算法应该均衡考虑到延时抖动（稳定性）、平均速率、资源占用（主要是CPU占用），而锐速过于偏科，它是不及格的，也无法给用户带来良好的体验，而且相比于开源的reno和BBR系列算法，锐速的算法闭源，是否暗藏私货也不得而知。
BBR一定可以战未来？
我相信很多朋友在测试自己的VPS的时候，都会在BBR和BBR2之间来回测试，最后发现BBR的速度远超过BBR2的速度，最后选择抛弃BBR2。在很多人眼里，BBR2真的太慢了，慢到和reno看起来也就稍微快了50%，这让用户果断相信BBR2是个半成品，而且很“垃圾”。
其实BBR和锐速在一些方面有着异曲同工之妙，但因BBR比锐速更加追求公平性，和智能根据TTL来判断当前网络是否已经拥堵，来决定是增加发送宽带还是反之减少，这种行为对路由更加友好，所以不容易被封杀，故断流的情况大大减少，所以很多人选择了BBR作为主要算法。
但是BBR对CPU的占用要求依旧比较高（相对BBR2来说），而且更为重要的一点是：BBR天生对弱WIFI信号下的客户端非常不友好，你可以尝试一下在WiFi发射的2.4Ghz频段下（信号只有1-2格），拉取BBR为拥塞控制的服务器上的文件，在完全没有网络拥堵的情况下，cubic和reno轻松的胜过了BBR，这使得BBR的使用场景受限，这不是我们真的想看到的。
BBR2这么慢，我应该如何在BBR和BBR2之间选择？
BBR2解决了WiFi的性能问题，你可以认为，它正在成为一个全场景的万金油，最有希望替换reno的下一代拥堵算法，一个对资源开销很小、具有高稳定性且能更合理且有效的利用骨干网可用宽带的冗余提高传输速率的算法，才是真正值得认可的算法。
BBR2的延时抖动目前是所有算法里控制的最好的，它可以做到更低的延时。流量的有效利用率，它也是表现最好的，多数情况下接近99%，虽然速度没有BBR快，但是这是好事。
现在的ISP路由算法也在与时俱进，欢迎更加“君子”的算法，排斥无脑、暴力的算法，BBR2目前在电信、联通、移动的网络下，反而成为了大多数场景下传输速率普遍很快且不容易断流的算法。BBR已经不再那么“万金油”了——至少在除了Amazon、GCP等大厂直连线路以外的普通国际线路里的优势正在慢慢缩减。
BBR2对于国内互联的改善也有较大的帮助，开启BBR可能反而起到的是劣化的作用，所以对于国内机器来说，如果你不想使用原版的cubic和reno协议，不妨试试BBR2，或许会带给你更多的惊喜。
目前专为 Linux 桌面端设计的内核 Xanmod 已采用了BBR2 算法+fq_Pie 包队列的组合来改善客户端的网络情况，据用户反馈效果不错。
总结
BBR 的优势正在慢慢被消耗，尽管Github上的 BBR2 分支显示仍在开发中(Technical/Alpha)，光以目前的效果来看，前途无量，很有可能会在不远的未来成为替代 reno 和 BBR 算法的下一代算法。
如果想要体验最新 BBR2 算法所带来的体验，可以安装 xanmod 内核（自带 BBR 和 BBR2 两种内核），另有全新的 CPU 调度算法，但是对于内存开销要求较高。如果需要只含有BBR2的版本，可以前往Github自行编译内核。
BBR v2 IPv4 TCP C 源码: https://github.com/google/bbr/blob/v2alpha/net/ipv4/tcp_bbr2.c
如何编译内核
RPM系可以参考：https://www.skyzyw.com/article/71.html
DEB系可以参考：https://zgh.im/archives/bbr-v2-installation/
本文转自： https://leo.moe/daily/bbrv2-introduce.html
本站仅做收录，版权归原作者所有。