TCP BBR、Cubic、Reno 有什么区别？VPS 和网站应该怎么选
更新日期：2026-07-07
Linux 上常见 TCP 拥塞控制算法包括 Cubic、Reno 和 BBR。很多 VPS 教程会直接推荐 BBR，但并不是所有场景都一定更快。先理解它们的思路，再决定是否开启。
Reno：传统基线
Reno 的思路比较保守：把丢包视为网络拥塞信号，丢包后明显降低发送窗口。它简单、成熟，但在高延迟、高带宽链路上利用率不高。
现在普通服务器很少主动选择 Reno，更多是作为理解 TCP 拥塞控制的基础。
Cubic：Linux 长期默认选择
Cubic 也是基于丢包信号，但增长曲线更适合现代高带宽网络。很多 Linux 发行版长期默认使用 Cubic，因为它兼容性好、表现稳定、和传统网络设备配合较成熟。
Cubic 适合：
- 普通网站和 API。
- 同地域、低延迟服务。
- 不想引入额外变量的企业环境。
- 对公平性和兼容性更敏感的网络。
BBR：基于带宽和 RTT 建模
BBR 的核心不是等丢包，而是估算瓶颈带宽和最小 RTT，再控制发送速率。它在跨区域、高 RTT、轻微丢包场景下更容易体现优势。
BBR 适合：
- 海外 VPS 面向跨洲用户。
- 下载站、对象分发、镜像站。
- 反向代理、长连接 API。
- 公网链路轻微丢包但带宽没有跑满的场景。
什么时候不要盲目开 BBR
- 你的瓶颈在应用、数据库、磁盘或 CPU。
- 你的用户都在同机房或同地域内网。
- 网络设备、QoS 或企业安全策略对 pacing 行为很敏感。
- 你没有监控，也无法比较开启前后的延迟和丢包。
推荐选择
| 场景 | 推荐 |
|---|---|
| 普通低延迟网站 | Cubic 或 BBR 都可以 |
| 海外 VPS 面向国内用户 | 优先测试 BBR |
| 跨洲下载、代理、镜像 | 优先测试 BBR |
| 企业内网、数据库专线 | 先保持默认 Cubic |
| 容器共享宿主机网络 | 先确认宿主机权限 |
实操建议
不要一次改一堆 sysctl。先只启用：
net.core.default_qdisc=fq
net.ipv4.tcp_congestion_control=bbr
然后观察：
- p95/p99 响应时间。
- 下载吞吐。
- TCP retransmits。
- mtr 丢包和延迟。
- 应用层错误率。