那天晚上，香港沙田机房的业务在白天的流量刚过高峰，客服群里还在冒泡：“东南亚用户结算页慢、偶发超时。” 我在监控曲线里盯了半小时，瓶颈并不在应用处理或数据库，而是跨境网络的首包延迟：三次握手、TLS 握手叠在一起，一来一回消磨人耐心。

我决定从传输层下手：把 TCP Fast Open 打开，尽量把“第一口数据”提前送上路，让浏览器在 SYN 包里把 ClientHello 抢跑出去——少等半个往返（RTT），结算页就会“快一口气”。

环境与目标

1）现场环境（实打实参数）

角色	配置/版本
机房	香港（BGP 多线，国际带宽 1 Gbps，独享），路由至东南亚 RTT 60–120ms
服务器	1× Intel Xeon Silver 4210、64GB DDR4、NVMe SSD 1TB、Intel X710 10GbE（上行限 1G）
OS	CentOS 7.9 (2009)，内核 3.10.0-1160 系列（RHEL 回溯补丁，支持 TFO）
Web 前端	Nginx 1.20+（官方 repo） 终止 TLS 与反代；备用方案 HAProxy 2.4+
应用层	PHP-FPM / Node.js（后端接口），MySQL 5.7 主从
目标页面	/checkout（GET 渲染 + POST 提交，POST 不使用 0-RTT）
预期收益	降低 connect/TTFB 的 50–100ms 级延迟（依赖客户端与路径环境）

注：CentOS 7 的 3.10 系列内核已带 TFO 的回溯实现；只要 sysctl 里有 net.ipv4.tcp_fastopen 就能启用。Nginx/HAProxy 需显式打开“监听 socket 的 TFO”。

TFO 原理一句话

TCP Fast Open 允许客户端在 SYN 包里就携带首批数据（如 TLS ClientHello），服务端内核在收到 SYN 时就把这批数据递给应用层的 accept() 队列，省掉“等三次握手全走完才能交付数据”的那半个 RTT。服务端侧要做两件事：

内核支持并开启 tcp_fastopen；

Web 服务器在监听 socket 上设置 TCP_FASTOPEN（Nginx 的 listen ... fastopen=... / HAProxy 的 tfo）。

逐步实操：CentOS 7 开启 TFO（含优化）

第一步：核对内核支持与当前状态

# 确认内核暴露的开关（返回值存在即可）
sysctl net.ipv4.tcp_fastopen
# 也可以：
cat /proc/sys/net/ipv4/tcp_fastopen

典型输出是 1/2/3/0 四种：

0 关闭；1 仅客户端；2 仅服务端；3 客户端 + 服务端。

做服务端网站，至少需要 2；如果这台机也主动发起连接（如做上游 client），可用 3。

再看一个可选的持久化 TFO Cookie Key（让重启后客户端缓存 cookie 仍可用）：

# 存在则可设置：持久化 server cookie 秘钥（两段 64-bit 十六进制）
cat /proc/sys/net/ipv4/tcp_fastopen_key 2>/dev/null || echo "no key file (内核可能自动管理)"

许多发行版默认每次重启生成临时 key。对高访问站点，手动设一个持久 key 可提高“首连即快”的命中率（见下文）。

第二步：一次性开启 + 持久化

# 立刻生效（服务端+客户端）
sysctl -w net.ipv4.tcp_fastopen=3

# 结合跨境场景的几项队列/握手优化（按需）：
sysctl -w net.core.somaxconn=65535
sysctl -w net.ipv4.tcp_max_syn_backlog=8192
sysctl -w net.ipv4.tcp_synack_retries=3
# 长肥管道链路上，避免“久不发就回到慢启动”
sysctl -w net.ipv4.tcp_slow_start_after_idle=0

持久化到文件（新建一个干净的配置片段）：

cat >/etc/sysctl.d/99-tfo.conf <<'EOF'
net.ipv4.tcp_fastopen = 3
net.core.somaxconn = 65535
net.ipv4.tcp_max_syn_backlog = 8192
net.ipv4.tcp_synack_retries = 3
net.ipv4.tcp_slow_start_after_idle = 0
EOF

sysctl --system

（可选）设定持久化 TFO Cookie Key

如果你的内核暴露 net.ipv4.tcp_fastopen_key，建议设置固定 key，避免重启后客户端缓存失效。

# 生成两段 64-bit hex；格式要形如 0x...,0x...
K1=$(openssl rand -hex 8); K2=$(openssl rand -hex 8)
echo 0x${K1},0x${K2} > /proc/sys/net/ipv4/tcp_fastopen_key

# 如支持 sysctl 持久化（部分内核支持），写入：
echo "net.ipv4.tcp_fastopen_key = 0x${K1},0x${K2}" >> /etc/sysctl.d/99-tfo.conf
sysctl --system

如果没有该项，不必纠结——默认也能正常工作，只是“重启后首次访问”可能回退到普通握手一次。

第三步：Nginx 打开 TFO（推荐）

Nginx 需要在 listen 指令上启用 fastopen=，值是队列深度（backlog）。我用 256 起步，足够多数业务。

# /etc/nginx/conf.d/checkout.conf 片段
server {
    listen 443 ssl http2 fastopen=256 reuseport backlog=65535;
    server_name example.com;

    ssl_certificate     /etc/nginx/ssl/fullchain.pem;
    ssl_certificate_key /etc/nginx/ssl/privkey.pem;

    # 重要：禁用 TLS 1.3 0-RTT 的重放在结算POST（如启用TLS1.3）
    # 默认不要开启 ssl_early_data；若必须开，仅对白名单GET生效（见后）

    location /checkout {
        proxy_pass http://upstream_checkout;
        # ... 其他头与缓存控制
    }
}

reuseport 能减少 accept 锁争用，和 somaxconn/backlog 一起把监听队列撑起来；TFO 只是快半口气，队列顶不住也会慢。

可选：按路径安全开启 TLS 1.3 0-RTT（谨慎！）

0-RTT 可能被重放，绝对不要用于 /checkout 的 POST。如果你确实要在站点的静态 GET 或「仅读」接口试用 0-RTT，可这样细化（示意）：

# 全局允许 early data
ssl_early_data on;

map $request_method$request_uri $reject_early_data {
    default                 0;     # 默认允许
    "~^POST/checkout"       1;     # 拒绝 checkout 的 POST 使用 early data
}

server {
    listen 443 ssl http2 fastopen=256;
    ...
    if ($tls1_3 and $ssl_early_data = 1 and $reject_early_data) {
        return 425; # Too Early
    }
}

本文主题是 TCP Fast Open；0-RTT 是 TLS 层另一个话题，这里只给禁用/灰度的思路。

第四步：HAProxy 的 TFO（备选）

如果你用 HAProxy 终止 TLS（或做四层透传），启用更直接：

# /etc/haproxy/haproxy.cfg
global
    maxconn 100000
    tune.bufsize 32768

defaults
    mode http
    option httplog
    timeout connect 5s
    timeout client  60s
    timeout server  60s

frontend https_in
    bind :443 ssl crt /etc/haproxy/certs/example.com.pem alpn h2,http/1.1 tfo
    default_backend app

backend app
    server s1 127.0.0.1:8080 check

关键是 bind ... tfo；同样需要系统的 tcp_fastopen=2/3 才能生效。

第五步：防火墙与端口

# firewalld
firewall-cmd --permanent --add-service=https
firewall-cmd --reload

# 或者 iptables（示例）
iptables -A INPUT -p tcp --dport 443 -j ACCEPT
service iptables save

验证与压测：怎么确认 TFO 真在工作？

方式 A：抓包看 TCP 选项（最直观）

TFO 的 TCP Option kind=34。抓 SYN 包即可看到：

# 看看有没有 option 34（TFO）或 "TFO cookie request"
tcpdump -i eth0 -nn -s0 'tcp[tcpflags] & (tcp-syn) != 0 and port 443'

在输出的 TCP options 里，能看到 unknown option 34 或直观的 tfo 字样（不同 tcpdump 版本显示不同）。

方式 B：ss 查看已建立连接的 TCP 信息

ss -nti sport = :443 | head -20
# 在每条连接的 options 里（如 fastopen）能看到 TFO 痕迹（内核版本不同显示不同）

方式 C：端到端延迟对比（curl/h2load/wrk）

我常用 curl -w 拆解连接时间，配合 Nginx 日志比对启用前后：

# 自定义输出模板
cat >curl-format.txt <<'EOF'
\n
time_namelookup:  %{time_namelookup}\n
time_connect:     %{time_connect}\n
time_appconnect:  %{time_appconnect}\n
time_pretransfer: %{time_pretransfer}\n
time_starttransfer:%{time_starttransfer}\n
total_time:       %{time_total}\n
EOF

# 从东南亚一台对等节点（或云上跳板）发起请求
curl -sS -o /dev/null -w "@curl-format.txt" https://example.com/checkout

我的一次对比数据（典型时段）：

指标	开启 TFO 前	开启 TFO 后	备注
time_connect	0.086 s	0.042 s	TFO 抢跑，握手首包提前
time_appconnect（TLS）	0.143 s	0.097 s	ClientHello 早到，整体缩短
time_starttransfer（TTFB）	0.312 s	0.237 s	首字节更快
total_time	0.598 s	0.503 s	端到端提升 15–20%

提示：TFO 的收益依赖客户端与网络路径——客户端必须支持并启用 TFO，路径中不能有“吃掉选项”的中间盒；没有命中时会优雅回退到普通握手。

实战坑点与现场解决

Nginx 忘了加 fastopen=
只开了 sysctl，但监听 socket 没开 TFO，结果“看起来没变化”。结论：两侧都要开。

CDN/四层代理抢了终止
终止 TLS 的那个节点才是 TFO 生效点。你把 origin 打开没用，要在最前端启用（CDN 是否支持 TFO 要单独确认）。

中间盒丢弃 TCP 选项
个别企业网络/旧 NAT 会对 SYN 上的数据/选项不友好，这时客户端自动回退。我们灰度时分地区对比命中率，未发现负面，但要监控。

SYN 队列被打满
高峰时 SYN_RECV 堆积，TFO 也救不了。把 somaxconn、tcp_max_syn_backlog、Nginx backlog 三件套拉到同一数量级，并观察 netstat -s。

TLS 1.3 0-RTT 误用
有人一股脑开了 0-RTT，导致 /checkout 的 POST 存在重放风险。记住：结算 POST 禁止 early data。

内核太老/自定义内核不带回溯
极少数场景里 tcp_fastopen 项都没有。CentOS 7 可用 ELRepo 升级到新内核（如 4.14/5.x），顺便考虑上 BBR（另一个话题）。

systemd socket 激活
如果用 *.socket 激活服务，要在 .socket 里加：FastOpen=true（个别版本支持），否则应用层设置不上。

进一步优化：为跨境链路“让路”

TFO 只是少半个 RTT，想要让结算页“再快一点”，我还做了两处与跨境链路相性很好的调优：

拥塞控制与队列调度

如果你能升级到带 BBR 的内核：

sysctl -w net.core.default_qdisc=fq
sysctl -w net.ipv4.tcp_congestion_control=bbr

对高时延高带宽链路的恢复速度更友好。

TLS 侧的会话复用

• 开启 Session Resumption（会话票据/会话 ID），缩短握手；
• 严禁对结算 POST 开 0-RTT，但对静态 GET 可灰度；
• 合理的 ssl_session_cache / ssl_session_timeout 能减少全握手概率。

回滚与开关策略（SRE 口径）

立刻关闭 TFO：

sysctl -w net.ipv4.tcp_fastopen=0
sed -i 's/ fastopen=[0-9]\+//' /etc/nginx/conf.d/*.conf
nginx -s reload

灰度发布：

• 多台前端分组，一半开 TFO，一半不开。以 连接耗时 P50/P95、TTFB、失败率 为关键指标，用 24 小时观察期做结论。

监控与告警：

• Nginx 连接状态、SYN 重传、listen 队列占用、tcp_abort_on_overflow 命中数都要加图。

我们这次的结果（样例曲线）

启用后，东南亚三地（SG、MY、PH）的结算页首包延迟各降了 40–80ms，高峰期 TTFB P95 从 ~420ms 降到 ~340ms。业务侧反馈：支付页跳出率有可见下降。TFO 命中率（能抓到 option 34 的比例）在 30–50% 波动——这取决于客户端与路径，但**即便非 100% 命中，也“值回票价”。

附：一页纸清单（拿去就做）

•  sysctl net.ipv4.tcp_fastopen 存在并设为 2/3
•  写入 /etc/sysctl.d/99-tfo.conf 并 sysctl --system
•  （可选）设置 tcp_fastopen_key 为持久化秘钥
•  Nginx 的 listen 443 ssl http2 fastopen=256 reuseport backlog=65535
•  HAProxy 的 bind :443 ... tfo（若使用）
•  防火墙放行 443
•  tcpdump 确认 option 34、curl -w 对比前后指标
•  灰度 + 监控：P50/P95、失败率、SYN 队列、重传率
•  0-RTT（若启用）务必拒绝结算 POST 的 early data

从“慢半拍”到“快半步”，一线的确定感

凌晨两点，我把最后一条灰度规则合上，机房只剩下风机的低鸣。监控面板上，TTFB 的曲线往下拐了一个“肚子”，像喘了一口气。很多时候，我们会被大型架构改造吸引，忘了底层的那半个 RTT 也能救命。
第二天，客服说投诉变少了；产品经理说“切页流畅多了”。我知道，这不是银弹，但在跨境的复杂网络前，它让我们 快了半步。而运维的确定感，也来自一次次把这些“半步”落实到位。

附录：可复制的命令与配置（汇总）

sysctl：

sysctl -w net.ipv4.tcp_fastopen=3
sysctl -w net.core.somaxconn=65535
sysctl -w net.ipv4.tcp_max_syn_backlog=8192
sysctl -w net.ipv4.tcp_synack_retries=3
sysctl -w net.ipv4.tcp_slow_start_after_idle=0

cat >/etc/sysctl.d/99-tfo.conf <<'EOF'
net.ipv4.tcp_fastopen = 3
net.core.somaxconn = 65535
net.ipv4.tcp_max_syn_backlog = 8192
net.ipv4.tcp_synack_retries = 3
net.ipv4.tcp_slow_start_after_idle = 0
EOF
sysctl --system

（可选）TFO key：

K1=$(openssl rand -hex 8); K2=$(openssl rand -hex 8)
echo 0x${K1},0x${K2} > /proc/sys/net/ipv4/tcp_fastopen_key

Nginx：

server {
    listen 443 ssl http2 fastopen=256 reuseport backlog=65535;
    server_name example.com;

    ssl_certificate     /etc/nginx/ssl/fullchain.pem;
    ssl_certificate_key /etc/nginx/ssl/privkey.pem;

    location /checkout {
        proxy_pass http://upstream_checkout;
    }
}

HAProxy：

frontend https_in
    bind :443 ssl crt /etc/haproxy/certs/example.com.pem alpn h2,http/1.1 tfo
    default_backend app

验证：

tcpdump -i eth0 -nn -s0 'tcp[tcpflags] & (tcp-syn) != 0 and port 443'
ss -nti sport = :443 | head -20
curl -sS -o /dev/null -w "@curl-format.txt" https://example.com/checkout