Linux TCP拥塞控制调优关键是匹配链路特性：Cubic适配低丢包稳定网络，BBR需≥5.10内核+fq调度器，切换后须用iperf3和snmp验证效果。
Linux TCP 拥塞控制算法的选择和调优，本质是匹配网络路径特性——不是“哪个更好”，而是“哪个更适配当前链路”。BBR 和 Cubic 的设计哲学完全不同：Cubic 看丢包，BBR 看带宽和时延。调优的关键在于识别场景、验证效果、避免误切。
先确认当前算法和可用选项
别直接改配置，先摸清现状：
- 查当前生效算法：
sysctl net.ipv4.tcp_congestion_control - 查系统支持哪些算法：
sysctl net.ipv4.tcp_available_congestion_control（若输出不含bbr，说明内核未启用或版本过低） - 检查内核版本：
uname -r，BBR 需 ≥ 4.9，但生产建议用 ≥ 5.10，避免早期 BBR v1 的稳定性问题
BBR 启用与配套设置
启用 BBR 不只是改一个参数，它依赖特定队列调度器才能发挥效果：
Browser Setup (No-Root Linux)
下载
在无 root/sudo 权限的环境（云容器、VPS、隔离主机）中安装并配置 OpenClaw 浏览器工具的 headless Chrome。适用场景：...
- 加载模块：
sudo modprobe tcp_bbr - 设置拥塞控制：
echo "net.ipv4.tcp_congestion_control=bbr" | sudo tee -a /etc/sysctl.conf - 必须搭配
fq（Fair Queueing）队列规则：echo "net.core.default_qdisc=fq" | sudo tee -a /etc/sysctl.conf - 生效：
sudo sysctl -p - 验证：
ss -i查看单个连接的 cwnd、pacing rate、delivery rate，BBR 连接应显示非零的bbr相关字段
Cubic 适用场景与微调要点
Cubic 仍是通用性最强的默认算法，尤其适合中等延迟、低丢包的稳定网络（如数据中心内部、骨干网互联）：
- 无需额外模块，开箱即用
- 若需增强长肥管道（high BDP）表现，可略调大初始慢启动阈值：
net.ipv4.tcp_slow_start_after_idle=0（禁用空闲后重置 cwnd，保持窗口） - 不建议盲目调大
tcp_congestion_window或tcp_rmem/tcp_wmem，这些由内核动态管理更可靠；手动固定反而可能抑制自适应能力 - 在丢包率 > 0.5% 的链路上，Cubic 吞吐会明显下降，此时切换 BBR 收益显著
切换后务必验证真实效果
改完参数不等于优化成功，得看实际流量行为：
- 用
ip route show确认路径 RTT 和带宽是否符合预期（例如跨洋链路 RTT ≈ 150ms，带宽 1Gbps，则 BDP ≈ 18.75MB） - 跑一次 iperf3 测试：
iperf3 -c server_ip -t 60 -P 4，对比 Cubic/BRR 下的吞吐、抖动、重传率 - 监控
/proc/net/snmp中的 TCP 重传统计，BBR 下重传应主要来自链路层丢包，而非拥塞触发 - 混合部署时注意：BBR 流可能抢占 Cubic 流带宽，若共存需评估公平性，必要时启用 ECN（
net.ipv4.tcp_ecn=1）
