本文目录导读:

在 Linux 网络协议栈中,tcp_recovery_fast 通常指的是 TCP 快速恢复 机制(Fast Recovery),这是 TCP 拥塞控制算法(如 Reno、CUBIC 等)中处理丢包后恢复吞吐量的关键阶段。
要实现“快速恢复”,核心目标是在检测到丢包后,尽快重新填满网络的带宽,同时避免再次引发拥塞,这需要结合 Linux 内核的参数调整和协议机制来优化。
以下是几种让 TCP 快速恢复“更快”的方法:
调整内核参数(最直接有效)
Linux 提供了多个 sysctl 参数来控制 TCP 恢复行为,针对“快”的需求,可以考虑以下调整:
-
启用 TCP 时间戳(TSO/E):这是快速恢复的基础。
sysctl -w net.ipv4.tcp_timestamps=1
作用:提供更精确的 RTT(往返时间)测量,帮助 TCP 更准确地判断丢包并启动快速重传,而不是消极等待超时。
-
启用 TCP 选择性确认(SACK):这是快速恢复的核心,如果没有 SACK,发送方只能重传一个丢包,然后等待 ACK 确认;有 SACK 可以一次性重传多个丢失的包,大大加快恢复速度。
sysctl -w net.ipv4.tcp_sack=1 sysctl -w net.ipv4.tcp_dsack=1 sysctl -w net.ipv4.tcp_fack=1
-
启用 TCP 窗口缩放(Window Scaling):允许使用更大的接收窗口,避免因窗口不足而限制吞吐量,间接帮助恢复。
sysctl -w net.ipv4.tcp_window_scaling=1
-
启用 TCP 早期重传(ERT):允许发送方在收到有限的新数据 ACK 时触发快速重传,而不是等待重复 ACK 达到阈值(3 个)。
sysctl -w net.ipv4.tcp_early_retrans=1
调整拥塞控制算法
不同的拥塞控制算法在快速恢复阶段的行为差异很大,选择适合高速、低延迟网络的算法可以显著加快恢复:
- 推荐算法:BBR(Bottleneck Bandwidth and Round-trip propagation time):不依赖丢包来判断带宽,而是基于带宽和延迟的测量,它的恢复速度极快,几乎不受丢包影响。
sysctl -w net.ipv4.tcp_congestion_control=bbr # 通常需要加载模块:modprobe tcp_bbr
- 推荐算法:CUBIC(Linux 默认):在高带宽网络中恢复较好,但在低延迟网络中可能不如 BBR 快。
- 适合短连接/低延迟:TCP_NOTSENT_LOWAT:减少发送缓冲区中未发送的数据量,降低应用层延迟,间接加快 ACK 返回速度。
调整应用程序行为
快速恢复本质上依赖于接收端及时返回 ACK,应用层可以做一些事情:
- 使用 TCP_NODELAY(禁用 Nagle 算法):避免小数据包被延迟发送,确保 ACK 尽可能快地返回。
- 使用大缓冲区:增大
SO_RCVBUF和SO_SNDBUF(系统会按 2 倍自动调整),给发送端更大的空间继续发送数据,避免窗口关闭导致的恢复变慢。
特殊情况:tcp_recovery 参数(内核 4.15+)
从 Linux 4.15 开始,引入了 net.ipv4.tcp_recovery 参数,用于控制选择性 ACK 与快速恢复的细节,设置为 1 可以启用 DSACK(Duplicate SACK) 优化,帮助发送方更快地处理重传数据。
sysctl -w net.ipv4.tcp_recovery=1
最快速的恢复组合
如果你的场景是高吞吐、丢包率低但偶尔突发丢包,建议使用以下配置:
# 内核参数 sysctl -w net.ipv4.tcp_timestamps=1 sysctl -w net.ipv4.tcp_sack=1 sysctl -w net.ipv4.tcp_dsack=1 sysctl -w net.ipv4.tcp_fack=1 sysctl -w net.ipv4.tcp_window_scaling=1 sysctl -w net.ipv4.tcp_early_retrans=1 sysctl -w net.ipv4.tcp_recovery=1 # 使用 BBR 拥塞控制 sysctl -w net.ipv4.tcp_congestion_control=bbr # 应用层 setsockopt(sock, IPPROTO_TCP, TCP_NODELAY, &one, sizeof(one));
注意:
- 参数修改需在
/etc/sysctl.conf中持久化,或通过网络工具临时设置。 - BBR 在某些对丢包容错要求极高的场景(如卫星链路)下可能不如 CUBIC 稳定,需测试。
- 如果网络本身存在严重的丢包(>5%),任何算法都难以快速恢复,应优先排查物理层或中间设备问题。
希望这些配置能显著提升你系统的 TCP 快速恢复速度。
标签: TCP快速恢复