75、TCP快速打开：TFO原理、TCP_FASTOPEN选项、适用场景

说实话，TCP 三次握手这个设计，在大多数场景下都没问题。但如果你做过高并发短连接服务，比如 Web 服务器、Redis 缓存、或者 API 网关，你就会发现——每次建连都要多一个 RTT，这开销其实挺疼的。

我几年前优化过一个推送网关，客户端每次发消息都要先握手，再发数据。那时候我就想：能不能把数据“塞”在握手过程里？后来查资料，发现 TCP 快速打开（TFO）就是干这个的。

什么是 TCP 快速打开？

TCP 快速打开，英文叫 TCP Fast Open，简称 TFO。它的核心思想很简单：在三次握手的 SYN 包中携带应用数据。

传统 TCP 连接，客户端必须等三次握手完成，才能发送数据。这意味着至少浪费一个 RTT。TFO 允许客户端在第一个 SYN 包中就带上数据，服务端收到后可以直接处理，并在 SYN-ACK 中返回响应。

说白了，就是把“握手”和“数据传输”合并了。你想想看，对于很多短连接场景，这能省下整整一个网络往返时间。

TFO 的工作原理

TFO 不是无条件的。它需要一个“信任建立”的过程。我第一次看 RFC 7413 时，觉得这个设计挺巧妙——用 Cookie 来防止 SYN 泛洪攻击。

整个流程分两步走：

第一步：获取 Cookie（首次连接）

1. 客户端发送 SYN 包，带上 TFO 选项（空 Cookie 请求）。
2. 服务端生成一个加密 Cookie（基于客户端 IP 和密钥），在 SYN-ACK 中返回。
3. 客户端缓存这个 Cookie，后续连接复用。

嗯，这里要注意：首次连接并不能省 RTT。Cookie 获取本身就需要一次握手。真正的收益从第二次连接才开始。

第二步：快速打开（后续连接）

1. 客户端发送 SYN 包，带上缓存的 Cookie 和要发送的数据。
2. 服务端验证 Cookie 有效，直接处理数据，并在 SYN-ACK 中返回响应。
3. 客户端收到 SYN-ACK，连接建立完成，数据已经送达。

我画了一张流程图，帮你理清这个逻辑：

TCP_FASTOPEN 选项

在 Linux 上启用 TFO，主要靠两个 socket 选项：

服务端设置

int qlen = 5;  // 最大未完成 TFO 连接数
setsockopt(sockfd, IPPROTO_TCP, TCP_FASTOPEN, &qlen, sizeof(qlen));

这个 qlen 参数，我解释一下：它表示服务端愿意同时处理多少个“未完成三次握手但已收到数据”的 TFO 连接。我个人习惯设成 5 到 10，具体看你的并发量。

客户端设置

int opt = 1;
setsockopt(sockfd, IPPROTO_TCP, TCP_FASTOPEN, &opt, sizeof(opt));

// 发送数据时使用 sendto 或 sendmsg，带上 MSG_FASTOPEN 标志
sendto(sockfd, data, len, MSG_FASTOPEN,
       (struct sockaddr *)&addr, sizeof(addr));

注意：客户端第一次连接时，sendto 会触发三次握手并获取 Cookie。后续连接才会真正“快速打开”。

适用场景

TFO 不是万能的。我总结了几类适合和不适合的场景：

避坑指南

我在生产环境用 TFO 时，遇到过几个问题，分享给你：

• 防火墙拦截：有些老旧防火墙不认识 TFO 选项，会直接丢弃 SYN 包。我曾经在客户现场部署，结果服务完全连不上，最后发现是中间防火墙把 TFO 包当攻击流量给拦了。
• Cookie 过期：服务端重启后，所有缓存的 Cookie 都失效。客户端需要重新获取。如果你的服务频繁重启，TFO 的收益会打折扣。
• 数据大小限制：SYN 包能携带的数据有限，通常不超过 1460 字节（一个 MSS）。如果你要发大包，TFO 帮不上忙。
• 兼容性：不是所有操作系统都支持 TFO。Linux 3.7+ 支持，Windows 10+ 支持，macOS 部分支持。如果你面向老旧设备，建议做降级处理。

性能实测数据

我拿一个简单的 HTTP 服务做过压测，对比普通 TCP 和 TFO 的延迟：

你看，后续连接的延迟降低了约 30%，吞吐量提升了 36%。这个收益在跨地域、高延迟的网络环境下会更明显。

好了，关于 TCP 快速打开，核心就是这些。记住一句话：TFO 是为短连接场景量身定做的优化，不是银弹。用对了地方，效果立竿见影；用错了地方，反而增加复杂度。