TCP BBR 相信大家都不陌生了，这是一套由 Google 所设计并发布的 TCP 拥塞控制算法。由于锐速迟迟没有提供对新内核的支持，再加上自 Linux 4.9内核开始默认支持 TCP BBR，它开始逐渐成为服务器单边加速的首选。而 BBRplus 则是 CSDN 网友 dog250 针对原版 BBR 进行修改而来的加强版。而 BBRv2 则是原版 BBR 的后续迭代版本，目前仍然处于测试阶段。
不过面对种类繁多的 BBR 衍生版本，网络上却很少能够看到对他们的横向对比评测。现有的一些评价也往往都基于经验和主观印象，或是变量不可控的异地测试。于是 reizhi 决定抽空对 BBR BBRplus 和 BBR2 进行本地横向测试一探究竟。
测试环境
使用 VMware workstation 开启两台 Debian 虚拟机，其中 A 机为服务器，通过 Nginx 架设 Web 服务并放置 100mb 文件供下载测速；B 机为客户机，使用 wget 进行下载。两台虚拟机通过虚拟内部网络连通，且均位于 SSD 固态硬盘上。
测试方法
通过 tc 命令将 A 机网卡设置为延迟 150ms ± 15ms（随机波动），丢包8%用于模拟一般化的网络环境。安装不同 BBR 分支加速后，在 B 机通过 wget 下载 100MB 的测试文件若干次（≥5次），并取最快3次的平均速度。
测试结果
我们直接来看测试结果，目前仍处于测试版本的 BBRv2 是本次测试中最慢的，速度与4.19内核默认的 cubic 算法几乎相同。而令人意外的是，BBRplus 虽然显著快于原版 BBR，却被5.5内核的 BBR 远远甩在身后。
测试中让人非常意外的是，BBRplus 分支在启动下载后速度攀升非常迅速。但不知何种原因，在下载进行到50% ~ 60%左右时，速度会骤然回落。下图完整的记录了 BBRplus 4.14.129 的速度变化情况。
起初 reizhi 以为是测试误差或其他原因，但经过了重启，重装系统，重装内核，手动编译内核开启 BBRplus 等操作后均未改善。在同等测试环境下，BBR 5.5 的速度表现就要稳定得多。
虽然 BBR 5.5.10 起步加速和峰值速度都不如 BBRplus，但在下载全程中均保持了非常不错的速度，最终整体耗时远低于 BBRplus。这是否意味着 BBRplus 更适合于突发小流量而 BBR 则擅长大流量持续吞吐呢？
附注
在本次测试中同样也尝试了锐速及 Net-speeder，不过与 BBR2 类似的，他们的全程速度均只有2位数，在此便没有将结果包纳进来。
以上是 BBR2 的速度情况，由于速度过慢未进行完整下载。
谢谢 谢谢分享
博主好，请问如何安装BBR 5.5.10 ？
我Google了，可是没找到结果
两个办法，一键安装https://github.com/ylx2016/Linux-NetSpeed/releases，或者下载内核手动安装，再启用BBR
BBR 没有5.5.10，你需要搜索如何下载安装内核，以及如何开启 BBR+cake
test100M.1 100%[==============================>] 100.00M 3.92MB/s in 27s
2020-05-22 14:06:46 (3.72 MB/s) – ‘test100M.1’ saved [104857600/104857600]
我用bbrplus并没有重现你的减速的情况
给锐速正个名，在CPU严重超售，延迟300ms，丢包20%左右的机器上，只有锐速或者net-speeder暴力发包管用，其它都不行。延迟 150ms ± 15ms（随机波动），丢包8%，这网络也太好了，CPU应该也很不错。
锐速真的不太稳定~~切身感受
速度是很快 但是不稳定
我现在改用了debian10 +bbr+cake
速度不错，稳定最重要
bbr+cake没有bbr+fq好吧，切换测试过最后还是fq正常点
实验环境结果不能完全反映真实环境使用情况，仅供参考。
我现在用Debian9 自带bbr 也开启了 请问那个fq是什么东西？怎么开启？
fq是队列规则，你的bbr怎么开的？
很好的文章，整理的很清楚
https://github.com/jinwyp/one_click_script/blob/master/KERNEL_CN.md
据观察。在此项目中出现了其他作者制作的4.9-5.17版本的 bbrPlus
并且debian11默认的内核也已经更新至5.10版本（也可以更新至最新的5.17）
所以希望作者看到此留言，可以更新至最新的各版本内核，以及debian11 ubuntu22 的最新默认内核进行测试！
这篇测试完全是理论环境情况下的表现，不能代表真实世界情况。
而且测试后我又查了一些资料，就决定不再更新这个主题了。
请问查询了什么资料？
1.TC 设置延迟需要在接收机上操作，如果按照我当时的操作在发送机上操作，会产生很大误差；
2.TC 对丢包的模拟过于随机，不能体现真实世界的情况。
而且队列算法也不止cake
(1) FQ, (2) FQ-Codel, (3) FQ-PIE, (4) CAKE
这些都是
而且除了bbrplsu和bbr以外还有个新奇玩意
bash <(wget –no-check-certificate -qO- 'https://raw.githubusercontent.com/caippx/bash/master/vvr/vvrv2.sh')
vvr 也可以加入测试