TCP三次握手与TLS握手重叠优化

这一章，我们来聊聊一个很实在的问题：怎么让TCP和TLS握手别再各自为政。

我见过太多团队，TCP优化做一套，TLS优化又做一套，结果两边加起来反而更慢。说白了，TCP三次握手和TLS握手是前后串联的——TCP先建连，TLS再加密。如果你能让它们重叠起来，延迟就能砍掉一大截。

今天我会把三个核心手段讲透：TCP Fast Open、TLS 1.3 0-RTT，以及TCP+TLS握手合并策略。每个我都会结合项目里的实际踩坑经验来说。

  核心观点：TCP和TLS的握手不是孤立的。让它们协同工作，比单独优化任何一个都划算。

先说说TCP Fast Open（TFO）。这东西不是什么新概念了，但很多人没用对。

传统TCP三次握手，客户端发SYN，服务端回SYN+ACK，客户端再发ACK。这1.5个RTT是硬开销，跑不掉。但TFO允许你在SYN报文里就带上数据。

怎么做到的？第一次连接时，服务端生成一个TFO Cookie，客户端存下来。后续连接，客户端在SYN里直接带Cookie和数据。服务端验证Cookie通过，数据直接交给上层处理。

我曾在某直播平台做过实验。用户从4G切WiFi时，TFO让重连时间从平均320ms降到了180ms。效果很明显，但有个坑——中间设备。很多老防火墙和负载均衡器不认识TFO选项，直接丢包。部署前一定要先扫一遍中间链路。

部署建议：Linux内核3.7+支持TFO服务端，3.13+支持客户端。用 sysctl net.ipv4.tcp_fastopen 开启，值1表示客户端，2表示服务端，3表示都开。

TLS 1.3把握手从2-RTT压缩到了1-RTT，还搞了个0-RTT模式。0-RTT说白了就是：客户端第一次发数据时，就能带上加密的应用数据。

原理是这样的：

听起来很完美对吧？但有个大问题——重放攻击。0-RTT数据如果被中间人截获，可以重复发送。服务端没法区分是重放还是正常请求。

避坑指南：我曾经在一个支付接口上开了0-RTT，结果测试发现重复的扣款请求被服务端接受了。后来我们强制要求所有0-RTT请求必须是幂等的——查询、预加载可以，写操作不行。

TLS 1.3 0-RTT适合的场景：

现在我们把TFO和TLS 1.3 0-RTT拼在一起。你想想看，如果TCP SYN里带数据，TLS ClientHello也带数据，那是不是能在一个RTT里完成所有事？

没错，这就是握手合并的核心思路。具体流程是这样的：

步骤	传统方式	合并优化后
1	客户端发SYN	客户端发SYN + TFO Cookie + TLS ClientHello + 0-RTT数据
2	服务端回SYN+ACK	服务端回SYN+ACK + TLS ServerHello + 0-RTT响应
3	客户端发ACK + TLS ClientHello	（跳过）
4	服务端回TLS ServerHello + 证书	（跳过）
5	客户端发TLS Finished	（跳过）
6	服务端回TLS Finished + 应用数据	（跳过）

从6步压缩到2步，RTT从3个降到1个。对于跨洋连接（比如中国到美国，延迟150ms），一次请求能省下300ms。

  关键点：合并不是简单地把报文拼在一起。你需要确保TFO Cookie和TLS PSK都提前就绪，而且中间设备不会拆包。

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

理论说完了，聊聊实战。我踩过的坑不少，挑几个典型的：

中间设备拦截TFO选项：有些老防火墙看到SYN带数据直接丢包。对策是灰度发布，先在小流量上验证中间链路兼容性。
TLS 0-RTT重放攻击：前面说了，幂等性是底线。我们当时在应用层加了个去重表，用请求ID+时间戳做唯一键。
Cookie/PSK过期：TFO Cookie和TLS PSK都有有效期。客户端如果缓存过期，会回退到标准握手。我建议把过期时间设成2小时，太短了优化效果打折扣，太长了安全风险高。
多路径问题：移动端经常切换网络，Cookie和PSK跟着失效。我们做了个预加载机制——在WiFi切4G前，提前发起一次握手刷新缓存。

性能数据：我们线上实测，TFO + TLS 1.3 0-RTT合并后，首包时间（TTFB）从平均280ms降到了110ms。对于弱网环境（丢包率5%），效果更明显，因为少了一次重传机会。

不是所有场景都适合。我建议你考虑以下几点：

嗯，这一章的内容差不多就这些。TCP和TLS的握手优化，说白了就是让数据早点上路。TFO帮你省了TCP的半个RTT，TLS 1.3 0-RTT帮你省了TLS的一个RTT，合并起来就是1.5个RTT。对于延迟敏感的应用，这可能是用户体验的分水岭。