Linux TCP Fast Open 与 BBR 优化指南
适用场景
适用于：
- Shadowsocks / Trojan 等 TCP 代理
- 跨境网络
- 高 RTT 链路
- 长距离 TCP
- 高带宽、大文件传输
- 多 TCP Flow 代理服务器
推荐组合：
net.ipv4.tcp_fastopen = 3
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr三者作用不同：
TCP Fast Open
→ 减少 TCP 建连和首包延迟
BBR
→ 优化 TCP 拥塞控制，提高高 RTT 链路利用率
fq
→ Flow Queueing + Packet PacingTCP Fast Open
原理
普通 TCP：
SYN
↓
SYN/ACK
↓
ACK
↓
DATATFO 在满足条件时允许：
SYN + DATA
↓
SYN/ACK
↓
ACK主要优化：
- 建连延迟
- 首包延迟
- 大量短连接
对长时间稳定传输的最终吞吐影响通常较小。
适用场景
收益较明显：
高 RTT
大量短连接
频繁建立 TCP
HTTP / API
代理请求收益较低：
低 RTT
长连接
大文件已经进入稳态传输含义
net.ipv4.tcp_fastopen = 3含义：
1 = Client
2 = Server
3 = Client + Server代理服务器通常同时存在入站和出站 TCP，所以使用 3。
BBR
原理
BBR 是 Linux TCP 拥塞控制算法，主要根据：
Bottleneck Bandwidth
+
RTT
+
Delivery Rate估计链路容量，并控制：
cwnd
pacing_rate
发送节奏相比主要依赖丢包反馈的传统算法，BBR 更适合：
- 高 RTT
- 高带宽
- 长距离 TCP
- 存在轻微随机丢包的网络
为什么高 RTT 更有价值
例如：
带宽 = 1 Gbps
RTT = 50 msBDP：
1 Gbps × 0.05s
≈ 6.25 MB意味着链路上必须维持足够多的 In-flight Data 才能跑满。
高 RTT 环境下，如果拥塞窗口增长不足或丢包后下降过多，就容易出现：
线路 1 Gbps
实际单 TCP 只有 200 ~ 500 MbpsBBR 的价值主要就在这里。
BBR 对代理服务器的作用
Shadowsocks / Trojan TCP 可以简化为：
Client
↓
TCP Connection 1
↓
Proxy Server
↓
TCP Connection 2
↓
Target这其实是两段独立 TCP。
服务器上的 BBR：
只控制服务器自己发送出去的 TCP因此通常对：
Server → Client也就是下载方向，更容易观察到改善。
BBR 不优化 UDP
Linux：
net.ipv4.tcp_congestion_control = bbr只作用于：
TCP不会直接优化：
UDP
QUIC
HTTP/3
Shadowsocks UDP Relay如果 UDP / QUIC 性能差，应重点检查：
丢包
RTT
抖动
MTU
Socket Buffer
线路 QoS
应用层拥塞控制fq
推荐：
net.core.default_qdisc = fq主要提供：
Flow Queueing
Packet Pacing
多 Flow 调度对代理服务器大量 TCP Flow 比较适合。
常用组合：
fq + BBRTCP 优化配置
检查系统是否支持 BBR
查看当前可用的 TCP 拥塞控制算法：
sysctl net.ipv4.tcp_available_congestion_control正常情况下应包含：
bbr例如：
net.ipv4.tcp_available_congestion_control = reno cubic bbr如果没有 bbr，尝试加载模块：
sudo modprobe tcp_bbr再次检查：
sysctl net.ipv4.tcp_available_congestion_control如果仍然没有 bbr，说明当前内核没有提供可用的 BBR，不建议继续配置：
net.ipv4.tcp_congestion_control = bbr配置 TCP Fast Open + fq + BBR
创建配置文件：
sudo nano /etc/sysctl.d/99-network-tuning.conf写入：
# TCP Fast Open
net.ipv4.tcp_fastopen = 3
# Queue Discipline
net.core.default_qdisc = fq
# TCP Congestion Control
net.ipv4.tcp_congestion_control = bbr应用配置：
sudo sysctl --system验证配置
检查：
sysctl net.ipv4.tcp_fastopen
sysctl net.ipv4.tcp_congestion_control
sysctl net.core.default_qdisc
sysctl net.ipv4.tcp_available_congestion_control期望：
net.ipv4.tcp_fastopen = 3
net.ipv4.tcp_congestion_control = bbr
net.core.default_qdisc = fq并且：
net.ipv4.tcp_available_congestion_control中包含：
bbr进一步检查真实 TCP Connection：
ss -tin重点关注：
bbr
rtt
cwnd
retrans
delivery_rate
pacing_rate其中：
rtt
→ 当前往返延迟
cwnd
→ 拥塞窗口
retrans
→ TCP 重传
delivery_rate
→ 实际交付速率
pacing_rate
→ 当前发送节奏场景建议
国内低 RTT
例如：
RTT < 10 ms
低丢包
低抖动建议：
TFO：可以开
BBR：可以开，但收益通常有限更应该关注：
CPU
NIC
MTU
代理程序
线路带宽跨境 / 高 RTT
例如：
RTT 30 ~ 150 ms
200 Mbps ~ 1 Gbps+
存在随机丢包或抖动推荐：
net.ipv4.tcp_fastopen = 3
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr这类场景最值得测试 BBR。
常见问题
Q1：开启 BBR 后一定会更快吗？
不一定。
BBR 无法解决：
运营商限速
线路物理瓶颈
CPU 满载
NIC 上限
目标服务器限速
严重物理丢包如果 CUBIC 已经接近跑满线路，切换 BBR 可能几乎没有变化。
Q2：TFO 能提高大文件下载速度吗？
通常不会明显提高稳态吞吐。
TFO主要优化：
建连
首包
短连接大文件稳定传输阶段主要取决于：
BBR / CUBIC
RTT
丢包
TCP Window
线路带宽Q3：为什么开启 BBR 后 iperf3 没变化？
常见原因：
RTT 很低
线路本来已经跑满
原来的 CUBIC 已经足够
CPU 或带宽已经成为瓶颈结合：
iperf3
ss -tin一起判断。
Q4：BBR 对 QUIC 有作用吗？
没有直接作用。
因为：
QUIC
↓
UDPQUIC 的拥塞控制通常由应用自己实现。
Q5：设置 tcp_fastopen=3 就一定使用 TFO 吗？
不一定。
它只代表：
Linux 内核允许使用 TFO实际是否生效还取决于：
客户端
服务端应用
TFO Cookie
NAT
防火墙
中间网络Q6：需要升级到 BBRv3 吗？
一般不需要。
生产环境优先使用：
发行版稳定内核自带 BBR如果评估 BBRv3，应做完整 A/B 测试，至少比较：
吞吐
平均 RTT
P95 / P99 RTT
重传率
丢包
CPU
SoftIRQ确认稳定收益后再考虑使用。
最终建议
普通跨境代理服务器可以直接使用：
net.ipv4.tcp_fastopen = 3
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr记住：
TFO
→ 优化建连和首包
BBR
→ 优化 TCP 拥塞控制
fq
→ Flow Queueing + Packet Pacing
iperf3 + ss -tin
→ 验证是否真的有收益
欢迎加入 Typecho 大家族