1. TLS握手协议概述
聊TLS优化之前，得先把握手这件事搞清楚。我见过不少团队，调了半天TCP参数，结果问题出在TLS握手阶段——说白了，两层没对齐。
TLS握手，就是客户端和服务器互相确认身份、协商加密参数的过程。这个过程会跟IP层、传输层产生大量交互。不理解这些交互，调优就是瞎调。
1.1 TLS协议栈架构
TLS不是单独一层。它夹在传输层和应用层之间。我习惯这么看：
- 底层：TCP（传输层）提供可靠字节流
- 中间：TLS Record Protocol（记录协议）负责分片、压缩、加密
- 上层：TLS Handshake Protocol（握手协议）负责认证和密钥协商
你想想看，每次应用层发数据，先经过TLS加密，再交给TCP分段，最后IP层路由。这个链路里任何一层出问题，都会影响整体性能。
核心观点：TLS握手不是独立事件。它依赖TCP的RTT、IP的路由路径、甚至MTU大小。调优必须跨层看。
1.2 TLS握手流程全景图
下面这张图，是我自己画的标准TLS 1.3握手流程。注意看每一轮交互对应哪些层。
个人经验：我在优化一个跨国电商平台时，发现TLS握手占了页面加载时间的40%。后来把TLS 1.2升级到1.3，配合TCP快速打开，首屏时间直接砍掉一半。嗯，跨层调优的效果就是这么明显。
1.3 TLS与IP层/传输层的关系
很多人觉得TLS是应用层的事，跟IP、TCP没关系。这是误解。我列几个关键交互点：
| 交互点 | 涉及层 | 影响 |
|---|---|---|
| TCP三次握手 | 传输层 | TLS握手必须等TCP连接建立后才能开始。TCP握手延迟直接叠加到TLS延迟上。 |
| MTU与分片 | IP层 | TLS记录太大时，IP层会分片。分片丢失会导致整个TLS记录重传，性能暴跌。 |
| 拥塞控制 | 传输层 | TLS握手阶段的数据量虽小，但TCP拥塞窗口初始值小，可能限制证书等大消息的传输。 |
| TLS记录大小 | TLS层 | 默认16KB的记录，在TCP层可能被拆成多个段。段丢失触发重传，影响握手完成时间。 |
避坑指南：我曾经遇到一个案例，客户端和服务端之间MTU只有1400字节，但TLS证书链超过8KB。结果每次握手都要经历IP分片和重传，握手耗时从50ms飙升到800ms。后来强制TLS记录大小不超过MTU，问题解决。
1.4 为什么需要协同调优？
说白了，TLS握手不是孤立事件。它依赖TCP的RTT、IP的路由路径、甚至MTU大小。调优必须跨层看。
我个人的调优习惯是：
- 先看传输层：TCP参数（初始窗口、拥塞算法）是否合理
- 再看IP层：MTU是否一致、路由路径是否最优
- 最后调TLS：协议版本、密码套件、会话复用
你想想看，如果TCP拥塞窗口只有10个段，而TLS证书有20个段，那握手就得等两个RTT才能传完证书。这时候调TLS密码套件有什么用？
一句话总结：TLS握手的性能瓶颈，往往不在TLS本身，而在它下面的两层。协同调优，才是真正的优化。