实测 BBRv3：吞吐跟 v1 差不多，重传少了一大截

Ubuntu 26.04 的 7.0 内核自带的 bbr 还是 v1。手上正好有一个打了 Google BBRv3 补丁的 7.0 内核，就把 CUBIC、BBRv1、BBRv3 放在一样的条件下跑了一遍，主要想看看丢包和缓冲小的时候差多少。

结论先放前面，v3 的吞吐跟 v1 差不多，有一组低了 8% 左右，但重传少了很多。CUBIC 在有随机丢包的线路上基本跑不动。

怎么测的

在一台 KVM 虚拟机里，用网络命名空间搭了发送端、路由器、接收端三段，瓶颈放在中间的路由器上。数据方向用 netem 限速，需要丢包就再加上随机丢包，回程的 ACK 加上往返延迟。

缓冲大小按带宽乘往返延迟来算，1 BDP 就是刚好能装下一个往返的数据量，0.2 BDP 只有它的五分之一，算是缓冲很小的线路。

每次只跑一条连接，一组 20 秒，最后一组跑了 60 秒。吞吐按实际送达的数据算，后半段吞吐是去掉刚开始加速那段之后的速度，重传率是重发的数据占总发送量的比例。

路由器上的设置大概是这样，这是 100M、往返 40ms、缓冲正常的那组：

# 发往接收端的方向：限速 100M，缓冲 331 个包（这组没加丢包）
tc qdisc replace dev r-rcv root netem rate 100mbit limit 331
# 回程方向：加上 40ms 往返延迟
tc qdisc replace dev r-snd root netem delay 40ms limit 100000

CUBIC 在两个内核上都跑了，结果几乎一样，下面只放自带内核那组。

100M，往返 40ms，不丢包，缓冲正常

三个都能跑满，区别在延迟上。CUBIC 会把缓冲塞满，RTT 从 40 涨到了 73，两个 BBR 基本贴着 40 走。

100M，往返 40ms，不丢包，缓冲只有五分之一

吞吐都差不多。v1 的重传到了 2.19%，缓冲一小它就容易自己把缓冲打爆，这是老问题了。v3 降到了 0.42%。

100M，往返 100ms，随机丢包 1%

CUBIC 只有 1.4，基本没法用。v3 比 v1 慢一些，全程低 8% 左右，后半段差得更多。不过 v1 的重传有 3.38%，比线路本身 1% 的丢包高出一大截，多出来的部分是它自己挤爆缓冲造成的。v3 的 1.03% 基本就是线路本身的丢包。

50M，往返 150ms，随机丢包 0.1%，跑 60 秒

延迟一高，就算只有千分之一的丢包，CUBIC 也只剩 5.7 了。两个 BBR 都接近 50M 的上限，v3 的重传只有 v1 的十分之一左右，代价是平均 RTT 多了 20ms 左右，会在缓冲里多排一点队。

说几句

线路干净、缓冲够大的时候，三个其实差不多，BBR 的好处主要是延迟低。一旦线路有丢包，BBR 比 CUBIC 强太多，这跟用 v1 还是 v3 关系不大。v1 和 v3 真正的差别在重传上，v3 更克制，不会自己把缓冲打爆，跟别人共用一条线路时更友好。如果线路丢包比较高，又只在乎单条连接能跑多快，v1 可能还会快一点。

这次只测了单连接，没测多条连接抢带宽的情况，每组也只跑了一次，没看波动。毕竟是在虚拟机里用 netem 模拟的，只能看出相对的差别，不代表真实线路上能跑到这个速度。想自己试的可以照着上面的 tc 命令改改参数。