解决跨网访问飞牛影音卡顿问题：启用 TCP BBR 的实践笔记

背景

我有两个房子，通过 OpenVPN 搭建了一个跨网访问环境（服务端位于 192.168.31.1（电信宽带），客户端为 192.168.32.1（移动宽带），两端用的都是爱快的x86系统），用于双向跨网访问家里的服务器资源，如运行在飞牛OS（fnOS）系统上的影音服务（位于 192.168.32.5）。

在使用过程中，我发现访问影音服务时经常出现卡顿转圈圈，尤其是在播放高清视频时。初步检查后，确认问题出在上传速度不对：32.254（32网段上的一台服务器） 和 32.5（飞牛的IP） 的上行速度仅为 51-53 Mbits/sec（约 6.4-6.6 MB/s），远低于预期，而 32.1 的上行速度可达 106 Mbits/sec（约 13.25 MB/s）。这导致影音数据传输不畅，影响体验。

分析过程

为定位问题，我进行了以下步骤：

1. 网络性能测试：

   • 使用 iperf3 测试网络性能：

     • 32.1到31.x网段的上行测试：106 Mbits/sec，符合32网段的上行带宽。

     • 但 32.254 和 32.5 到31.x网段的上行测试：51-53 Mbits/sec，但速度仅为 32.1 的一半。

   • 32.x 内网为 2.5G 网络，用iperf3测试达 2.38 Gbits/sec，排除内网瓶颈。

   • 结论：问题可能出在 OpenVPN 隧道或 32.1 的 NAT 转发。

2. 加密算法检查：

   • 当前使用 BF-CBC（Blowfish，128 位密钥，64 位块）。为测试是否为加密瓶颈，我尝试切换到 AES-128-CBC：

     • 结果：上行速度从 6 MB/s 降至 5 MB/s，性能略有下降。

     • CPU 占用率仅 10%，表明加密算法不是主要瓶颈。

     • 恢复 BF-CBC，速度回升至 6 MB/s，决定继续使用 BF-CBC。

3. 发现 TCP BBR：

   • 在测试中，我发现 32.1 启用 TCP BBR 后，上行速度从 6 MB/s 激增至 18 MB/s（144 Mbits/sec）。但 32.254 和 32.5 未受影响，速度仍为 51-53 Mbits/sec。

   • 检查 32.254（Proxmox）和 32.5（飞牛OS）的拥塞控制算法：

     • 32.254：sysctl net.ipv4.tcp_congestion_control 输出 cubic。

     • 32.5：初始无 sysctl，后找到 /usr/sbin/sysctl，输出 cubic。

   • 结论：32.254 和 32.5 未启用 BBR，导致未充分利用隧道带宽。

4. 飞牛OS 的 sysctl 问题：

   • 32.5（飞牛OS，内核 6.12.18-trim）初始提示 sysctl: command not found。通过查找发现 /usr/sbin/sysctl，确认支持标准 Linux 配置。

   • 推测飞牛OS 为轻量级系统，未默认包含 sysctl 路径或 procps 包。

最终解决方案

通过以上分析，我确定问题根源为 32.254 和 32.5 未启用 TCP BBR，导致上行性能受限。以下是解决方案：

1. 在飞牛OS（32.5）上启用 BBR：

   bash

   sudo modprobe tcp_bbr sudo /usr/sbin/sysctl -w net.ipv4.tcp_congestion_control=bbr sudo /usr/sbin/sysctl -w net.core.default_qdisc=fq echo "net.ipv4.tcp_congestion_control=bbr" | sudo tee -a /etc/sysctl.d/99-bbr.conf echo "net.core.default_qdisc=fq" | sudo tee -a /etc/sysctl.d/99-bbr.conf sudo /usr/sbin/sysctl -p /etc/sysctl.d/99-bbr.conf

   • 验证：sysctl net.ipv4.tcp_congestion_control 输出 bbr。

2. 在 Proxmox（32.254）上启用 BBR：

   bash

   modprobe tcp_bbr sysctl -w net.ipv4.tcp_congestion_control=bbr sysctl -w net.core.default_qdisc=fq echo "net.ipv4.tcp_congestion_control=bbr" >> /etc/sysctl.d/99-bbr.conf echo "net.core.default_qdisc=fq" >> /etc/sysctl.d/99-bbr.conf sysctl -p /etc/sysctl.d/99-bbr.conf

   • 验证：sysctl net.ipv4.tcp_congestion_control 输出 bbr。

3. 验证结果：

   • iperf3 测试（服务端 192.168.31.251 到客户端，反向模式）：

     • 32.254：平均 106 Mbits/sec（约 13.25 MB/s）。

     • 32.5：平均 106 Mbits/sec（约 13.25 MB/s）。

   • 实际使用：影音服务卡顿消失，高清视频流畅播放。

开启BBR后，测速恢复正常

什么是 TCP BBR？为何影响如此显著？

TCP BBR（Bottleneck Bandwidth and Round-trip propagation time）是 Google 开发的 TCP 拥塞控制算法，与传统算法（如 Cubic 或 Reno）相比，具有以下优势：

• 动态带宽估计：BBR 实时测量网络的瓶颈带宽和最小往返时延（RTT），根据实际网络容量调整发送速率，而非仅依赖丢包信号。

• 高效处理丢包：在高丢包场景（如 OpenVPN 隧道，~9000 次重传），BBR 能维持高吞吐量，而 Cubic 因丢包减速显著。

• 低缓冲区占用：BBR 减少了网络设备缓冲区膨胀，降低延迟。

为何影响显著：

• 我的 OpenVPN 隧道存在高丢包（重传 ~9000 次），可能是跨网访问（可能跨国）或网络链路不稳定导致。Cubic 算法在丢包时大幅降低发送速率，导致 32.254 和 32.5 的上行速度受限（51-53 Mbits/sec）。

• BBR 通过优化发送速率，充分利用隧道带宽，使 32.1 的上行速度提升至 144 Mbits/sec。启用 BBR 后，32.254 和 32.5 的 TCP 连接也能动态适应丢包环境，上行速度提升至 106 Mbits/sec，接近 32.1 的性能。

结论

通过启用 TCP BBR，我成功解决了 OpenVPN 跨网访问影音服务时的卡顿问题。32.254（Proxmox）和 32.5（飞牛OS）的上行速度从 51-53 Mbits/sec 提升至 106 Mbits/sec，影音传输流畅。分析过程表明，高丢包的 OpenVPN 隧道是性能瓶颈，BBR 的动态带宽估计和高丢包适应能力显著提升了吞吐量。优化 MTU、NAT 和 OpenVPN 配置进一步巩固了效果。

经验教训：

• 在高丢包或高延迟的 VPN 场景中，优先检查 TCP 拥塞控制算法，BBR 是优选方案。

• 对于精简系统（如飞牛OS），需确认 sysctl 工具可用性。

• NAT 转发可能限制端到端优化，考虑为客户端配置独立 OpenVPN 连接以进一步提升性能。

PS：31.x和32.x还建立了zerotier，但测速并不理想平均只有4-5兆/s（见附图），因此未启用这个通道，只是作为一个备份通道保留。

zerotier通道下的连通速度测试。

作者声明本文无利益相关，欢迎值友理性交流，和谐讨论～