Linux配置TCP快速打开(TFO)方法

配置TCP快速打开（TFO）看似简单，实则有不少细节需要注意。许多人按照教程操作后测试没有效果，问题往往出在那些“知道但没做到”的关键环节。下面从前提检查到最终验证，完整梳理一遍配置流程。

先检查一个常见的前提条件：内核版本必须≥3.7，且tcp_fastopen参数必须设为3，否则后续所有操作都无效。

先查看内核版本：uname -r，输出结果如果≥3.7，说明通过了第一道门槛。对于服务端，建议内核版本至少为4.1以上。

再检查TFO的当前配置：cat /proc/sys/net/ipv4/tcp_fastopen。返回值有四种情况：

• 0：完全禁用，TFO未开启。
• 1：仅客户端可用，服务端忽略TFO请求。
• 2：仅服务端接受TFO连接，客户端无法发起。
• 3：双向启用，生产环境推荐值。

如果检查发现不是3，可以临时运行一条命令：echo 3 > /proc/sys/net/ipv4/tcp_fastopen（需要root权限）。

临时生效不是长久之计，要想重启后保持配置，需要修改文件并立即生效。编辑 /etc/sysctl.conf，添加一行：net.ipv4.tcp_fastopen = 3，然后执行 sysctl -p 加载配置。注意：在CentOS 7或某些旧版systemd系统上，重启后可能出现配置被自动重置为0的情况，原因在于systemd-sysctl存在延迟加载问题。此时需要额外执行 systemctl restart systemd-sysctl，才能确保重启后配置保持为3。

验证配置是否生效：sysctl net.ipv4.tcp_fastopen和cat /proc/sys/net/ipv4/tcp_fastopen的输出必须均为3，两者一致才算配置成功。

服务端应用必须显式启用监听 socket 的 TFO 队列

内核级别的开关只是基础，不等于业务层面已经开通。如果运行的是Nginx、OpenResty或自研服务，没有在listen socket上主动调用setsockopt(, IPPROTO_TCP, TCP_FASTOPEN, &qlen, sizeof(qlen))，客户端发来的SYN-data包会被服务端悄然丢弃，不会有任何反馈。

• 如果使用Nginx且版本≥1.15.5，在listen指令后添加fastopen=256即可——例如listen 443 ssl http2 fastopen=256;。
• C/C++自研服务的配置时机很关键：必须在bind()之后、listen()之前调用setsockopt()。qlen值建议在5到128之间，并发量较大时可适当调高。
• Go语言程序如果版本≥1.13，可使用golang.org/x/net/tcp包，设置TCPFastOpen: true即可启用。

验证服务端是否就绪：运行命令ss -i | grep :443（替换为实际监听端口），如果输出中包含tfo:0x1字段，说明服务端已准备好。

客户端触发 TFO 必须用 sendto() + MSG_FASTOPEN

这是很多人容易忽略的地方：使用传统的connect()→send()流程，永远无法触发TFO。第一次连接必须先完成完整的三次握手，目的是获取Cookie。

• C/C++编写的客户端：创建socket后，直接调用sendto(sockfd, data, len, MSG_FASTOPEN, ...)即可。glibc版本需要≥2.23才能支持MSG_FASTOPEN。
• 使用curl的话，版本≥7.49.0自带TFO支持。运行curl --tcp-fastopen https://example.com即可，curl会自动处理Cookie缓存和重试逻辑。
• 压测时需特别注意：必须让客户端复用相同的IP和端口，否则每次连接都会被当作首次连接，无法体现RTT节省效果。使用wrk时可加参数wrk -t4 -c100 -d30s --tcp-fastopen。

最终的验证方式——抓包。使用tcpdump抓到的SYN包，如果长度大于60字节，且在Wireshark中看到TCP Options包含TFO Cookie字段，说明整条链路真正走通。

整条链路中最容易被忽视的坑有两个：服务端未配置fastopen=参数，或客户端未使用MSG_FASTOPEN。如果只将/proc/sys/net/ipv4/tcp_fastopen改为3，而这两步没有跟上，那么TFO实际上不会产生任何效果。