BBR解决OpenWRT下Wireguard组网中TCP速率问题
Nov. 13, 2025Wireguard或基于Wireguard的组网服务（比如Netbird、Tailscale）是现在很多人的选择，特别是支持P2P的组网服务，能够免去中转产生的延迟和限速。 但广泛基于UDP的P2P组网的实际性能却更容易收到网络环境的影响，本文介绍一个我遇到的因为网络环境导致的Netbird速率不佳的问题。以及BBR也可以在VPN隧道中提高网络性能。
问题
我是用Netbird将工位上的局域网络和宿舍的局域网相连，两边的路由器都是OpenWRT，一边（工位）是BPI R3MINI，另一边（宿舍）则是TR3000，三者之间都能建立P2P连接。
有一天发现访问工位上的网络很慢。因为工位上网络有大约100M~300M的上传速度，BPI R3MINI和TR3000之间iperf3测速也可以接近这个上限，但是TR3000到R3MINI的网络内的PC却只有这个速度的30%，实际只能跑到30M左右。
而在云服务器上得到测速结果却是正常的（PC、R3MINI上传到云服务器的速度都能接近上限）。
分析
因为工位（R3MINI）上是校园网，宿舍（TR3000）是联通家庭网，所以如果两个网络之间有限制的话就没办法了。
然后又对了下比云服务器上和TR3000上的iperf3 TCP测速结果，iperf3的另一端是R3MINI网络里的PC。
云服务器测速：
-----------------------------------------------------------
Server listening on 5201 (test #1)
-----------------------------------------------------------
Accepted connection from 10.33.87.47, port 59272
[ 5] local 192.168.2.249 port 5201 connected to 10.33.87.47 port 59284
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 15.4 MBytes 129 Mbits/sec 69 134 KBytes
[ 5] 1.00-2.00 sec 14.8 MBytes 124 Mbits/sec 66 119 KBytes
[ 5] 2.00-3.00 sec 9.12 MBytes 76.5 Mbits/sec 4 110 KBytes
[ 5] 3.00-4.00 sec 10.0 MBytes 83.9 Mbits/sec 12 89.9 KBytes
[ 5] 4.00-5.00 sec 13.0 MBytes 109 Mbits/sec 3 127 KBytes
[ 5] 5.00-6.00 sec 11.4 MBytes 95.4 Mbits/sec 12 91.1 KBytes
[ 5] 6.00-7.00 sec 13.1 MBytes 110 Mbits/sec 6 127 KBytes
[ 5] 7.00-8.00 sec 13.5 MBytes 113 Mbits/sec 5 116 KBytes
[ 5] 8.00-9.00 sec 11.8 MBytes 98.6 Mbits/sec 20 80.3 KBytes
[ 5] 9.00-10.00 sec 11.2 MBytes 94.4 Mbits/sec 19 125 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.01 sec 123 MBytes 103 Mbits/sec 216 sender
TR3000测速：
----
Server listening on 5201 (test #2)
-----------------------------------------------------------
Accepted connection from 10.33.12.197, port 51052
[ 5] local 192.168.2.249 port 5201 connected to 10.33.12.197 port 51060
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 3.88 MBytes 32.5 Mbits/sec 20 72.0 KBytes
[ 5] 1.00-2.00 sec 3.25 MBytes 27.3 Mbits/sec 0 94.7 KBytes
[ 5] 2.00-3.00 sec 4.25 MBytes 35.7 Mbits/sec 0 121 KBytes
[ 5] 3.00-4.00 sec 5.25 MBytes 44.0 Mbits/sec 0 145 KBytes
[ 5] 4.00-5.00 sec 4.88 MBytes 40.9 Mbits/sec 6 125 KBytes
[ 5] 5.00-6.00 sec 5.38 MBytes 45.1 Mbits/sec 0 149 KBytes
[ 5] 6.00-7.00 sec 4.88 MBytes 40.9 Mbits/sec 4 126 KBytes
[ 5] 7.00-8.00 sec 4.12 MBytes 34.6 Mbits/sec 5 109 KBytes
[ 5] 8.00-9.00 sec 4.62 MBytes 38.8 Mbits/sec 0 136 KBytes
[ 5] 9.00-10.00 sec 4.38 MBytes 36.7 Mbits/sec 5 82.7 KBytes
[ 5] 10.00-10.03 sec 256 KBytes 82.8 Mbits/sec 0 82.7 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.03 sec 45.1 MBytes 37.8 Mbits/sec 40 sender
TR3000的测速结果中，拥塞窗口似乎较前者的波动更大些。
使用iperf3进行UDP测速时却发现其实是可以跑到不错的速度的：
iperf3 -c 192.168.2.249 -R -u -b 100M
Connecting to host 192.168.2.249, port 5201
Reverse mode, remote host 192.168.2.249 is sending
[ 5] local 10.33.12.197 port 46254 connected to 192.168.2.249 port 5201
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-1.00 sec 10.2 MBytes 85.3 Mbits/sec 0.206 ms 1477/10173 (15%)
[ 5] 1.00-2.00 sec 10.3 MBytes 86.4 Mbits/sec 0.153 ms 1365/10164 (13%)
[ 5] 2.00-3.00 sec 10.4 MBytes 87.1 Mbits/sec 0.210 ms 1330/10196 (13%)
[ 5] 3.00-4.00 sec 10.3 MBytes 86.7 Mbits/sec 0.188 ms 1369/10190 (13%)
[ 5] 4.00-5.00 sec 10.4 MBytes 86.9 Mbits/sec 0.147 ms 1284/10133 (13%)
[ 5] 5.00-6.00 sec 10.2 MBytes 85.9 Mbits/sec 0.215 ms 1463/10211 (14%)
[ 5] 6.00-7.00 sec 10.4 MBytes 86.8 Mbits/sec 0.186 ms 1327/10165 (13%)
[ 5] 7.00-8.00 sec 10.3 MBytes 86.8 Mbits/sec 0.188 ms 1357/10190 (13%)
[ 5] 8.00-9.00 sec 10.4 MBytes 87.2 Mbits/sec 0.211 ms 1290/10164 (13%)
[ 5] 9.00-10.00 sec 10.4 MBytes 86.9 Mbits/sec 0.182 ms 1341/10185 (13%)
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-10.02 sec 119 MBytes 100 Mbits/sec 0.000 ms 0/101997 (0%) sender
[SUM] 0.0-10.0 sec 138 datagrams received out-of-order
[ 5] 0.00-10.00 sec 103 MBytes 86.6 Mbits/sec 0.182 ms 13603/101771 (13%) receiver
iperf Done.
TR3000到R3上的延时达到了24ms上下，而且抖动比较明显，而云服务器到R3只有8ms左右，抖动比较小。如此考虑可能是是TCP拥塞控制的问题，TCP算法发现延迟突然增加时，会立即将此视为拥塞，并迅速减小拥塞窗口（Cwnd），导致速度下降。
查看TR3000的TCP拥塞控制：
sysctl net.ipv4.tcp_congestion_control
net.ipv4.tcp_congestion_control = cubic
查看PC的TCP拥塞控制：
sysctl net.ipv4.tcp_congestion_control
net.ipv4.tcp_congestion_control = cubic
R3MINI上已经开启了BBR。
两边都是cubic，考虑换成bbr后再看下情况。
解决
理论上TR3000这边下行速度应该只和PC的拥塞控制有关，所以只需要让PC使用bbr。
sudo sysctl net.core.default_qdisc=fq
sudo sysctl net.ipv4.tcp_congestion_control=bbr
然而启用之后，速度仍然没有明显变化。
之后在TR3000上更新了带BBR的固件。
再进行测速，iperf3测速却取得了明显的提升：
-----------------------------------------------------------
Server listening on 5201 (test #5)
-----------------------------------------------------------
Accepted connection from 10.33.12.197, port 33946
[ 5] local 192.168.2.249 port 5201 connected to 10.33.12.197 port 33956
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 10.5 MBytes 88.0 Mbits/sec 1021 281 KBytes
[ 5] 1.00-2.00 sec 10.8 MBytes 90.2 Mbits/sec 771 249 KBytes
[ 5] 2.00-3.00 sec 10.0 MBytes 83.9 Mbits/sec 908 217 KBytes
[ 5] 3.00-4.00 sec 10.5 MBytes 88.1 Mbits/sec 806 138 KBytes
[ 5] 4.00-5.00 sec 9.62 MBytes 80.7 Mbits/sec 741 60.0 KBytes
[ 5] 5.00-6.00 sec 10.2 MBytes 86.0 Mbits/sec 827 242 KBytes
[ 5] 6.00-7.00 sec 10.4 MBytes 87.0 Mbits/sec 685 223 KBytes
[ 5] 7.00-8.00 sec 10.0 MBytes 83.9 Mbits/sec 586 247 KBytes
[ 5] 8.00-9.00 sec 10.5 MBytes 88.1 Mbits/sec 558 233 KBytes
[ 5] 9.00-10.00 sec 9.88 MBytes 82.8 Mbits/sec 641 211 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.01 sec 102 MBytes 85.8 Mbits/sec 7546 sender
结论
- Wireguard不会处理丢包问题，因此Wireguard的UDP丢包也会引起其中的运行的TCP协议丢包，因此基于丢包的TCP拥塞控制仍然能够影响速度。
- 链路上的延迟和抖动会对导致cubic的性能下降。
- 基于RTT和带宽的BBR能够忽略由隧道转发和WAN链路引入的微小抖动，稳定地将TCP窗口开到带宽所需的理论值。
- 对于HTTP连接，如果使用基于UDP的QUIC/HTTP3，理论上也可以接近速度上限。
我遇到的这个问题比我一开始想象的复杂些，因为我是在TR3000开启BBR后，从PC到TR3000的传输速度才有了明显提高，可能有如下原因：
- BBR+fq改善了TR3000返回ACK的平滑度（ACK Pacing）。能够配合PC上的BBR对链路有更精确的估计。
- TR3000开启BBR后，自身的接收窗口更大，因此协商的总窗口也更大。
做以上测试的时候的网络状况可能也比较特殊，Nebtird在ipv4或ipv6两种直连情况下的表现也有区别，之后我再想复现出那时候的状况都不太成功，只能暂且记录下以上经验以供后续补充。
