3、TCP三次握手与TLS延迟：TCP握手对TLS的影响、TCP快速打开、TLS over TCP优化
聊到TLS性能，很多人第一反应是「证书太慢」或者「加密太耗CPU」。但说实话，我排查过不少线上问题，真正拖后腿的往往不是TLS本身，而是它底下那层TCP。
你想想看，一个完整的HTTPS连接，TCP三次握手要1个RTT，TLS握手又要1-2个RTT。如果用户离服务器远一点，比如跨洋访问，光握手就得花几百毫秒。用户等得起吗？等不起。
核心观点：TCP握手是TLS延迟的「放大器」。优化TLS，必须先搞定TCP。
3.1 TCP三次握手如何影响TLS
先看一个标准流程。客户端发SYN，服务器回SYN+ACK，客户端再发ACK——这是TCP的三次握手。完成之后，TLS握手才开始。
也就是说，TLS的ClientHello必须等到TCP连接建立之后才能发出去。这1个RTT是硬开销，谁也省不掉。
我记得有一次帮一家电商公司排查下单接口慢的问题。用户反馈说「点提交按钮要等2秒」。我抓包一看，TCP握手花了200ms，TLS握手花了400ms，剩下时间都在等业务逻辑。但问题是，用户只感知到「慢」，不会区分是哪一层慢。
所以，TCP握手对TLS的影响可以总结为三点：
- 串行阻塞：TCP不建完，TLS不发包。这是最直接的延迟叠加。
- 拥塞窗口初始值小：TCP握手完成后，cwnd通常只有10个MSS（约14KB）。TLS握手阶段的证书链如果超过这个值，就会触发丢包或分片，进一步增加延迟。
- 慢启动拖累：即使TLS握手完成，后续数据传输也要从慢启动开始。如果连接是短连接（比如API调用），大部分时间都浪费在握手和慢启动上。
一个小技巧：我习惯在抓包时关注「三次握手完成」到「ClientHello发出」的时间差。如果这个差值超过10ms，说明TCP层可能有队列积压或SYN Flood防护在干扰。
3.2 TCP快速打开（TFO）的原理与实战
TCP快速打开（TFO）是个好东西。它允许客户端在SYN包里直接携带数据。对于TLS来说，这意味着ClientHello可以和SYN一起发出去。
原理其实不复杂：
- 第一次连接时，服务器生成一个TFO Cookie，通过SYN+ACK返回给客户端。
- 客户端缓存这个Cookie。
- 后续连接，客户端在SYN里带上Cookie和TLS ClientHello。
- 服务器验证Cookie通过后，直接处理ClientHello，无需等待三次握手完成。
效果呢？省掉1个RTT。对于跨洋连接，这可能是100-200ms的优化。
我曾经在一个海外游戏加速项目里用过TFO。玩家从东南亚连到美国服务器，原本每次登录要等1.2秒。开了TFO之后，降到0.8秒。虽然绝对值不大，但玩家体验提升很明显——毕竟没人喜欢盯着「连接中」转圈。
不过，TFO不是银弹。有几个坑要注意：
| 问题 | 说明 | 建议 |
|---|---|---|
| Cookie大小限制 | TFO Cookie通常只有16字节，但TLS ClientHello可能更大（尤其带了SNI、ALPN等扩展）。 | 确保ClientHello不超过TCP选项字段的剩余空间，否则TFO退化为普通握手。 |
| 中间设备兼容性 | 部分老旧防火墙或负载均衡器会丢弃SYN+数据的包。 | 先在测试环境验证，逐步灰度上线。 |
| 重传风险 | 如果SYN包丢失，TFO数据会随SYN重传，可能触发重复数据。 | 应用层做好幂等处理。 |
注意：Linux内核从3.6开始支持TFO服务端，3.7支持客户端。但很多发行版默认关闭。你需要手动设置 net.ipv4.tcp_fastopen 参数。我一般设成3（同时启用客户端和服务端）。
3.3 TLS over TCP的优化策略
说完了TFO，咱们聊聊更通用的优化手段。这些策略我在不同项目里反复用过，效果都比较稳。
3.3.1 调整TCP初始拥塞窗口
默认的initcwnd是10。对于TLS握手来说，证书链经常超过14KB。如果initcwnd太小，服务器需要等客户端ACK才能发下一批数据，白白浪费一个RTT。
我建议把initcwnd调到20-30。怎么调？用iproute2：
# 查看当前initcwnd
ip route show | grep initcwnd
# 设置initcwnd为20
ip route change default via 192.168.1.1 dev eth0 initcwnd 20调完之后，证书链可以一次发完，TLS握手延迟能降10-20%。
3.3.2 启用TCP_NODELAY
Nagle算法会把小包攒起来再发。TLS握手阶段有很多小包（ClientHello、ServerHello、Finished等），如果Nagle开着，这些包会被延迟发送。
解决方案很简单：在socket上设置TCP_NODELAY。
// C语言示例
int flag = 1;
setsockopt(sock, IPPROTO_TCP, TCP_NODELAY, &flag, sizeof(flag));
// Go语言示例
tcpConn, _ := tcpConn.(*net.TCPConn)
tcpConn.SetNoDelay(true)嗯，这里要注意：TCP_NODELAY只对写操作有效。如果你用的是异步框架，还得确保应用层不攒包。
3.3.3 连接复用
这是最有效的优化，没有之一。HTTP/1.1的Keep-Alive和HTTP/2的多路复用，本质都是复用TCP连接，避免重复握手。
我见过一个极端案例：某广告系统每次请求都新建TCP+TLS连接，QPS只有2000。改成连接池复用后，QPS直接飙到15000。你说夸张不夸张？但这就是事实。
连接复用的关键参数：
- 最大空闲时间：建议60-120秒。太短了复用率低，太长了浪费服务器资源。
- 最大复用次数：有些场景建议限制次数（比如1000次），防止连接退化。
- 健康检查：定期发心跳包，避免复用已断开的连接。
3.3.4 调整TCP缓冲区大小
TLS加密后的数据流需要更大的缓冲区来吸收突发流量。默认的tcp_rmem和tcp_wmem可能不够。
我常用的配置：
# 最小、默认、最大（单位：字节）
net.ipv4.tcp_rmem = 4096 131072 6291456
net.ipv4.tcp_wmem = 4096 65536 4194304这个配置让TCP缓冲区能自适应，既不会浪费内存，也不会在高吞吐时成为瓶颈。
3.4 一张图看懂TCP与TLS的握手延迟
下面这张图展示了普通TCP+TLS握手和TFO优化后的对比。你可以直观看到TFO省掉了哪个RTT。
3.5 避坑指南
最后分享几个我踩过的坑：
- 别盲目开TFO：如果中间有代理或WAF，TFO可能被拦截。我曾经在某个云厂商的LB后面开TFO，结果客户端一直收不到Cookie，连接反而变慢了。后来查文档才发现，那款LB不支持TFO透传。
- initcwnd不是越大越好：调太大可能导致网络拥塞。我一般从20开始，压测观察丢包率，再逐步往上加。
- 连接复用要配合超时：有个项目把连接池超时设成了30分钟，结果服务器端空闲连接被回收，客户端还在复用，导致大量「Connection reset」。后来改成60秒，问题消失。
嗯，TCP和TLS的优化，说白了就是「减少RTT」和「让每个RTT传更多数据」。这两件事做好了，TLS性能不会差到哪里去。