本文目录导读:

你提到的 tcp_autocork_fack 实际上并不是一个标准的 Linux 内核变量或函数名,它看起来像是将 TCP_autocorking(自动塞子)与 FACK(Forward Acknowledgment,前向确认)这两个独立的 TCP 机制组合在了一起。
根据你的意图(“怎样FACK”),我推测你是想了解: 在使用 TCP 自动塞子(autocorking)的场景下,如何启用或调整 FACK(前向确认)算法?
下面我会先澄清两者的关系,然后重点介绍如何“操作”FACK。
核心澄清:autocorking 与 FACK 是独立的
- TCP Autocorking:这是一个内核优化的发送端策略(从 Linux 3.11 左右引入)。
- 作用:当应用程序调用
send()但数据不足以填满一个 MSS 时,内核会决定稍等片刻(通常最多 1ms),期望后续有更多数据到来,从而合成一个更大的 TCP 报文段发送,这提高了网络吞吐量,减少了小包。 - 它不是一个 sysctl 参数,而是内核自动采用的内置逻辑(可以通过
tcp_autocorking内核参数静态调节,但通常默认开启)。
- 作用:当应用程序调用
- TCP FACK:这是一个拥塞控制/丢包恢复算法。
- 作用:用于更精确地判断网络拥塞时有多少数据包丢失,它利用 SACK(选择性确认)信息来估算“飞行的数据”,从而更快速地恢复丢包,不需要等待 RTO(超时重传)。
- 它也是一项内核处理逻辑,而不是一个可调节的开关。
你不能直接“做”FACK,但可以影响它
你无法直接手动“触发”FACK,也无法通过一个命令开启它。 FACK 是 Linux 内核 TCP 协议栈在以下条件下自动激活的:
- 对端支持 SACK:如果客户端或服务器的 TCP 握手时协商了 SACK(选择性确认),FACK 就会参与工作。
- 拥塞控制算法兼容:FACK 通常与 CUBIC 或 Reno 等传统算法配合,如果使用 BBR 等基于延迟的算法,FACK 的作用会减弱或被替代。
- 内核版本足够新:几乎所有现代 Linux 内核(>2.6.x)都支持。
如何“启用”或“调整”TCP FACK 行为
虽然无法手动调用 FACK,但你可以通过以下方式影响或启用它:
确保 SACK 开启(FACK 的先决条件)
FACK 依赖于 SACK,检查并启用 SACK:
# 检查当前值(1 = 启用) cat /proc/sys/net/ipv4/tcp_sack # 如果返回 0,则临时开启 sysctl -w net.ipv4.tcp_sack=1 # 永久生效(编辑 /etc/sysctl.conf 或 /etc/sysctl.d/99-sysctl.conf) echo "net.ipv4.tcp_sack = 1" >> /etc/sysctl.conf
选取合适的拥塞控制算法
FACK 在内核中通常只与基于丢包的算法(如 CUBIC、Reno)耦合,如果你想确保 FACK 活跃:
# 查看当前拥塞算法 sysctl net.ipv4.tcp_congestion_control # 如果不是 cubic 或 reno,切换(例如切换到 CUBIC) sysctl -w net.ipv4.tcp_congestion_control=cubic
监控 FACK 是否在工作
你无法直接看到 “FACK status”,但可以观察丢包恢复过程,使用 ss -i 或 netstat -s 观察 SACK 相关的重传指标:
# 查看当前 TCP 连接细节(注意 tcp_info 中的 sack_retransmits 等字段) ss -ti # 查看全局 SACK 统计 nstat -az | grep -i sack
- FACK 不能被主动调用或手动“FACK”。 它是内核在以下两个条件同时满足时自动生效的算法:
- SACK 开启(
tcp_sack=1)。 - 使用基于丢包的拥塞控制算法(如 CUBIC)。
- SACK 开启(
- Autocorking 与此无关。 无论 FACK 是否激活,Autocorking 始终在发送端尝试延迟小包合并,它们互不干扰。
- 你的操作:如果你发现网络丢包恢复很慢(RTO 频繁),可以检查
tcp_sack是否开启,并考虑切换拥塞控制算法到 CUBIC。tcp_autocork参数(如果存在)用于关闭 autocorking 的整体逻辑,但不会影响 FACK。
标签: TCP自动塞入