香港CN2服务器Linux内核优化深度对比：BBR、Cubic、HTCP谁能压榨CN2最后1ms？
1. 问题背景：CN2不是玄学，是内核参数的游戏
香港CN2（ChinaNet Next Carrier）的特殊性在于：物理延迟低（<30ms）、带宽充足、但偶尔出现微突发丢包（<0.5%）。默认内核（Cubic配合fq_codel）在纯低延迟场景下尚可，但一旦出现0.1%丢包，吞吐直接腰斩。我们需要在抗丢包和低延迟之间找平衡点——这不是调一个参数就能解决的，而是整套拥塞控制+缓冲区+调度器的组合拳。
本文用两台香港CN2服务器（A：轻云互联香港CN2高性能实例，4C8G，10Mbps独享；B：同样配置的轻云互联节点，作为对端）做对比：默认Cubic vs BBR vs HTCP，并逐一解剖每个sysctl参数对实际传输的影响。不搞花哨Benchmark，只说真实场景。
2. 环境与测试方法
- 内核版本：5.15（所有算法内核原生支持）
- 网络瓶颈：通过
tc qdisc add dev eth0 root netem loss 0.2% delay 10ms模拟CN2偶发丢包+恒定延迟 - 测试工具：iperf3（双向，5分钟）、ping -c 1000（统计抖动）、flent（RRUL测试）
- 基准配置：
net.core.default_qdisc = fq_codel（推荐，避免bufferbloat）
3. 核心对比：三种拥塞控制算法的血战
3.1 Cubic + fq_codel（默认）
# sysctl -w net.ipv4.tcp_congestion_control=cubic
sysctl -w net.core.default_qdisc=fq_codel
# 其他参数保持默认
结果：无丢包时吞吐9.6Mbps，延迟稳定11ms；添加0.2%丢包后吞吐暴跌至2.1Mbps，延迟抖动飙至±8ms。Cubic对丢包极度敏感——因为它的AIMD策略过于激进，每次丢包都砍一半窗口。
3.2 BBR + fq_codel
# sysctl -w net.ipv4.tcp_congestion_control=bbr
# 注意：BBR要求配合fq或fq_codel
结果：无丢包吞吐9.8Mbps（略有提升，因为BBR通过探测带宽更准）；0.2%丢包下吞吐稳定在8.3Mbps，延迟抖动控制在±3ms。BBR基于带宽和RTT建模，丢包后不直接降窗口，而是重测BDP——这是CN2场景的核心优势。
3.3 HTCP（Hybrid TCP）
# sysctl -w net.ipv4.tcp_congestion_control=htcp
# 默认qdisc已是fq_codel则无需改
结果：无丢包下吞吐9.5Mbps；0.2%丢包时吞吐仅4.1Mbps，但延迟抖动只有±2ms。HTCP在高RTT环境下优化过拥塞窗口增长，但对丢包的反应仍比BBR慢半拍。
结论：CN2线路（低延迟+微小丢包）下，BBR吞吐领先33%（对比Cubic）且延迟抖动最低，是首选。但BBR在纯无丢包状态会增加约5ms的排队延迟（因为主动填充队列），需配合tcp_notsent_lowat调优。
4. 深度调优：让BBR在CN2上再榨10%性能
BBR默认参数倾向于最大化吞吐，在CN2上可以微调以压低延迟。以下是我的
# /etc/sysctl.d/99-cn2-bbr.conf
net.ipv4.tcp_congestion_control = bbr
net.core.default_qdisc = fq_codel
# 关键：让BBR更快感知实际RTT，避免过度缓存
net.ipv4.tcp_notsent_lowat = 131072 # 128KB，降低发送延迟
net.ipv4.tcp_slow_start_after_idle = 0 # 空闲后不重置拥塞窗口
# 接收/发送缓冲区放大（CN2带宽富裕，BDP=10ms*10Mbps=12.5KB，但留余量）
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 65536 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
# 启用MTU探测（CN2支持1500正好，但避免分片）
net.ipv4.tcp_mtu_probing = 1
# 关闭慢启动重启（CN2连接稳定，无需重来）
net.ipv4.tcp_slow_start_after_idle = 0
4.1 专项测试：tcp_notsent_lowat 效果
单独对比此参数：设置128KB后，在0.2%丢包下，延迟从最差情况16.2ms降到9.8ms（平均降低40%），吞吐从8.3Mbps提升到8.7Mbps。原因：BBR的pacing发送在排队时会犹豫，调低notsent_lowat让BBR更激进地填充管道，减少应用层等待。
4.2 与默认系统对比（全面测试）
使用flent做RRUL（Realtime Response Under Load）测试：
- 默认Cubic：延迟25ms@50%负载，吞吐波动±15%
- BBR+fq_codel+以上调优：延迟8ms@50%负载，吞吐波动±5%
在CN2实际生产环境下（无模拟丢包），轻云互联的机器通过此配置，单连接SFTP传输从美国返程香港时，速度稳定在理论带宽的98%以上，而其他VPS默认配置仅70%-80%。
5. 还能更深吗？尝鲜：tc的公平队列与BBR的交互
替换默认qdisc为fq（fair queue vs fq_codel）: 在BBR下fq比fq_codel平均吞吐高2%，但延迟抖动略大（因为fq_codel的codel机制主动丢弃恶霸流）。本次对比选用fq_codel作为基准。可以通过tc -s qdisc show dev eth0观察丢包情况。
6. 总结：香港CN2服务器最佳内核配方
- 必须启用BBR：抵抗微小丢包，平滑吞吐
- 配合fq_codel：避免BBR自身造成的bufferbloat
- 调整tcp_notsent_lowat到128KB：降低延迟，提升小包响应
- 禁用慢启动重启：保持连接性能
- 大缓冲区+MTU探测：适配CN2稳定带宽
这套配置已在轻云互联香港CN2实例上运行半年，经历过多次跨境高峰期，始终稳定。如果你手上有香港CN2服务器，不妨花10分钟执行上面那段sysctl——你会看到实打实的数字变化。
（测试数据来自真实环境，所有命令已验证可复现。翻过一次手册就是写代码，不是排比句。）