在 5G NR 时代，我们真的该大规模部署 TCP BBR 了
背景
自从 Speedtest.net 在 2 年前增加了下载与上传时的 ping 测试后，我们往往会在 LTE / 5G 上观测到其下载和上传占满空口带宽后出现了延迟大幅飙升的情况，而这一情况在使用 WiFi 时影响非常小，但在使用基于 10G EPON / XGPON的有线ISP（有限速）中几乎不存在。这就导致我们使用 Hotspot WiFi 分享或是使用 5G CPE 转 WiFi 在家庭或办公室进行多人多应用的网络分享时，往往会因为这一问题导致一人处于下载状态时，其他人的 VoIP会议 / Zoom / SSH / RDP 等应用将因为延迟增加出现严重卡顿的情况。一个简单的解决方法是对单一客户端进行限速，然而，5G空口可用带宽是在时刻变化的，因此，对网络进行测量了解其产生的原因并提出可能的解决方案对 5G Home Internet 等场景将具有其意义。我初步考虑其原因可能与 TCP 拥塞控制算法有关，毕竟 TCP Cubic 是当前 Linux Kernel 中默认使用的 TCP 拥塞控制算法，因此我将对 TCP Cubic 与 TCP BBR 在不同 ISP 以及不同 5G UE 下的表现进行测试。
初步对比 Speedtest.net 5G / WiFi / 10G EPON
10G EPON Home Broadband
1200Mbps Download, 240Mbps Upload limited by ISP
WiFi 802.11ax 80MHz BW
Same ISP with 240Mbps Upload limited
5G NR
我们可以看出，家庭宽带在带宽占满时 ping 几乎不变，而 WiFi 出现了延迟升高，但不足 100ms 对除游戏外的大多数应用很难有明显的感知，但在 5G NR 中却增加到了 825ms，对于很多应用，例如 SSH / RDP / VoIP 等已经能导致非常影响使用的Lag。
实验
为了探究这个延迟增加与 TCP 拥塞控制算法的关系，我进行了以下实验：
- 在5G UE端（手机）接收服务器发送的 4 线程 TCP 流模拟网络满载情况
- 探索 5G UE 端带宽被 iperf 满载时另一个独立的 ICMP 数据流的延迟
实验设置
TCP发送端：北京阿里云节点，2C CPU + 2G RAM，1Gbps IPv6 Bandwidth，Linux 6.1 Kernel
TCP发送端sysctl配置：
net.ipv4.tcp_congestion_control = bbr | cubic
net.core.default_qdisc = fq
# kernel default测试软件：iperf3
测试参数：-R -P 4
下载速度测量测量方法：对所有线程的下载速度求和
ICMP 延迟测量方法：ping
ICMP 测量备注：由于 China Mobile 的 5G NR 不允许被动 ICMP ，因此整个测试中均将 UE 使用 WireGuard 隧道连接服务器，在服务器端使用ping $隧道peer地址的方式对 ICMP 延迟进行测试。但通过控制路由表对去往 iperf 连接地址的路由不经过 WireGuard 。
5G UE：
- iPhone 13 Pro (Qualcomm X60 5G Modem)
- Quectel RM500U-CN (UNISOC UDX710 Modem) at Superspeed USB ECM Mode + MacBook Pro 14′ M1 Pro
实验次数：3
实验时间顺序：
for_each(device)
for_each(loop)
for tcp_cong_algo in {cubic, bbr}实验环境
Neighbor Cell信息
China Unicom:
China Mobile:
注：不保证实验中一直连接着对应Cell。
实验结果
| 5G ISP | 5G UE | iperf3 Download Speed (Mbps) |
| ------------ | ------------- | ---- | ---- | ---- | ---- | ---- | ---- |
| | Cubic | BBR |
| China Unicom | iPhone 13 Pro | 637 | 441 | 656 | 615 | 623 | 465 |
| China Mobile | iPhone 13 Pro | 300 | 468 | 327 | 730 | 523 | 526 |
| China Unicom | RM500U-CN | 343 | 323 | 325 | 359 | 339 | 358 |
| China Mobile | RM500U-CN | 125 | 223 | 127 | 226 | 458 | 421 || 5G ISP | 5G UE | avg ping (ms) |
| ------------ | ------------- | ------- | ------- | ------- | ------- | ------ | ------- |
| | Cubic | BBR |
| China Unicom | iPhone 13 Pro | 155.023 | 114.736 | 131.526 | 49.743 | 69.296 | 43.005 |
| China Mobile | iPhone 13 Pro | 136.909 | 132.406 | 234.823 | 70.177 | 93.927 | 115.566 |
| China Unicom | RM500U-CN | 42.258 | 37.957 | 46.478 | 70.370 | 60.254 | 55.850 |
| China Mobile | RM500U-CN | 45.563 | 30.837 | 32.422 | 108.099 | 61.847 | 63.963 || 5G ISP | 5G UE | mdev ping(ms) |
| ------------ | ------------- | ------- | ------- | ------- | ------ | ------ | ------ |
| | Cubic | BBR |
| China Unicom | iPhone 13 Pro | 155.023 | 114.736 | 131.526 | 49.743 | 69.296 | 43.005 |
| China Mobile | iPhone 13 Pro | 105.282 | 120.616 | 357.796 | 26.814 | 24.723 | 58.353 |
| China Unicom | RM500U-CN | 24.121 | 10.046 | 25.657 | 72.331 | 47.118 | 35.687 |
| China Mobile | RM500U-CN | 18.800 | 6.967 | 8.790 | 67.700 | 19.355 | 29.929 |实验结论
在几乎所有的测试中，iperf3 下载速度几乎都在 BBR 算法上有更好的表现。
在 iPhone 13 Pro 的测试中，BBR 测试过程中的ping延迟显著低于 Cubic，而在 RM500U-CN 的测试中，即使在高带宽下载的情况下也未见显著延迟增加，而可能由于 BBR 带来更高的带宽反而导致了延迟略有上升。这可能是因为 RM500U-CN 使用 USB 输出时基带处理器具有较高的负载，其 CPU 占用本身结合其节能策略可能导致了带宽的限制以及延迟的增加，而不是由于 5G NR 空口导致。
总体而言，TCP BBR 拥塞控制算法可一定程度避免 5G NR 网络下的大缓冲区的 Long Fat Pipe 导致流量不断增广占满链路 Buffer 导致延迟增加的情况，一直到出现丢包为止才让速率收敛，但这还导致了不稳定的速率导致无法拥有较高的性能。而 TCP BBR 可根据其 ACK 延迟发现 Buffer bloat 事件，在发生丢包前就进行动态速率调整，避免该情况发生。
也许，在 5G NR 时代，我们真的该大规模部署 TCP BBR 在 CDN 以及 Web 服务器上了。
解决方法的讨论
对于单一 5G NR UE 分享 Internet 给不同的 WiFi 客户端使用多应用的场景，若要防止满速下载时出现延迟增加，可考虑使用以下方法：
- 云服务器隧道+ TCP BBR 透明代理
可考虑使用隧道连接的方式，将 5G NR 访问 Internet 流量使用一台开启了 TCP BBR 的服务器进行透明代理，这种情况下 TCP Buffer 将由云服务器维护，并通过 TCP BBR 算法进行更加高性能且合理的流量控制。
缺点：未能解决 UDP 流量占满带宽的问题。
- 等待你的建议