TLS握手延迟分析：RTT与计算开销
说实话，TLS握手的延迟是性能优化里最容易被忽视的坑。很多人部署HTTPS后发现页面变慢，第一反应是加密太贵，但实际上——来回的网络往返次数（RTT）才是大头。我手头有个真实案例：某金融App从HTTP切到HTTPS，首屏时间暴涨3秒，查到最后发现TLS 1.2完整握手走了整整3个RTT，而用户的网络延时是150ms，光握手就耗了450ms。
嗯，这一章我们就掰开揉碎了聊聊：TLS握手到底慢在哪？ 是网速？是CPU算不动非对称密钥？还是证书链太长？我习惯把延迟拆成两块——网络开销和计算开销。下面一个个说。
网络开销：RTT是隐形杀手
先看一个常识：TLS握手需要几次网络往返？ 这取决于协议版本和会话状态。
| 场景 | 需要RTT次数 | 典型耗时（50ms延迟） |
|---|---|---|
| TLS 1.2 完整握手 | 2 RTT | 100ms |
| TLS 1.3 完整握手 | 1 RTT | 50ms |
| TLS 1.2 会话复用（Session ID/Ticket） | 1 RTT | 50ms |
| TLS 1.3 0-RTT（early data） | 0 RTT | 0ms（握手中不等） |
你看，TLS 1.2一步到位就比1.3多耗一个RTT。我曾经在海外CDN项目上测试过，南美用户延迟普遍200+ms，如果还用1.2的完整握手，用户等了400ms才能开始发应用数据——这个体验基本上门还没进就被劝退了。
核心结论：在网络延迟高的场景下，每节省一个RTT，用户体验就是质变。所以近年来行业从TLS 1.2全面转向1.3，0-RTT甚至能做到零额外握手延迟。
那为什么TLS 1.2要2个RTT？简单回忆下流程：
- ClientHello → ServerHello + Certificate + ServerHelloDone（第1个RTT的往返）
- Client密钥交换 + Client Finished → Server Finished（第2个RTT的往返）
而TLS 1.3把server的Certificate和Finished放在同一个Flight里，client发完Hello就能预估密钥，所以只需要1个RTT就建立安全信道。
小技巧：如果项目必须兼容老旧客户端只能用TLS 1.2，可以优先开启Session Ticket复用。我曾在一个电商平台这么做，首次握手后后续请求只需要1个RTT，整体加载时间下降了40%。
计算开销：CPU也有短板
说完RTT，再说说计算。很多同学以为TLS慢主要是加解密，其实大部分计算开销发生在握手阶段，尤其是非对称密钥交换和证书验证。
3.1 密钥交换：RSA vs (EC)DHE
早期RSA密钥交换算法在握手时只做一次非对称解密（服务器私钥解密Pre-Master Secret），计算量并不大。但RSA不支持前向安全性，现在主流都用基于椭圆曲线的ECDHE或者传统DHE。这些算法需要生成临时密钥对、做点乘运算，CPU消耗明显更高。
| 算法 | 服务器CPU消耗（相对值） | 前向安全性 |
|---|---|---|
| RSA（2048位） | 1x | 否 |
| ECDHE（P-256） | 2~3x | 是 |
| DHE（2048位） | 10~20x | 是 |
我曾经在自建机房踩过一个坑：早期为了追求“最强安全”，配了DHE 2048bits，结果流量峰值时CPU跑到90%，服务器直接挂掉。后来换成ECDHE P-256，CPU降了80%，而且安全性完全够用。DHE简直是CPU杀手，能不用就别用。
避坑：不要把DHE/ECDHE的曲线长度设置得过高。P-256足够安全，用P-384或P-521会额外增加3~10倍的CPU开销，却只多几十比特的安全强度，在TLS里完全是浪费。
3.2 证书验证：根证书链越长越慢
Certificate消息里包含服务端证书和中间证书链。客户端收到后要做数字签名验证——也就是用证书公钥解密签名并对比哈希。如果证书链有3级（叶子→中间CA→根CA），就需要验证2次签名（根CA自签名通常不验证）。每次签名验证都是一次公钥运算，RSA 2048位大约是30万次CPU周期，而ECDSA P-256大约6万次。
补充一点：OCSP Stapling可以免去客户端主动查询证书吊销状态的开销，但前提是服务端要定期从CA获取OCSP响应并缓存在内存里。我团队有个线上系统，开启OCSP Stapling后，握手总时间又降了8~10ms。嗯，这里提醒一句：如果你自己维护Nginx，别忘了配ssl_stapling。
整体延迟拆解：一张图说清楚
下面这张图把TLS 1.2完整握手的延迟拆成了两个维度：RTT和CPU计算。注意看灰块是网络等待时间，彩色块是计算耗时。
从图上能清晰看到：网络等待（灰色虚线）占了大头。计算开销（彩色块）加起来不过几毫秒，而一个RTT就要50ms（以中等网络质量为例）。所以优化TLS握手，第一要务就是减少RTT次数，而不是死磕CPU。
实践中如何测量与定位
聊了这么多理论，我建议你直接在线上抓个包看看。用curl加--trace-time参数，或者浏览器开发者工具的Timing面板，都能看到握手阶段的具体耗时。
# 用openssl模拟完整握手，显示延迟
openssl s_client -connect example.com:443 -tls1_2 -msg -debug 2>&1 | grep -E "---|SSL_connect"我之前排查一个慢连接问题时，就是用这个命令发现服务器在Certificate后卡了800ms——最后发现是远程CA的OCSP响应超时。去掉OCSP Stapling的自动获取后，换了本地缓存策略，问题解决。
个人习惯：我会把TLS握手的延迟监控拆成三个指标——TCP连接时间、TLS握手总时间、以及其中包含的“等待Server Hell”和“等待Client Finish”子项。一旦TLS总时间超过200ms，就立刻抓包分析RTT和证书链长度。
综合优化清单
- 升级TLS 1.3：平均减少1个RTT，且强制使用ECDHE，计算开销反而比DHE低。
- 启用会话复用：Session Ticket或Session ID可以让后续握手降到1个RTT甚至0-RTT。
- 证书链裁剪：只包含必要的中间CA，不要塞多余的交叉证书。我见过某厂商的证书链有5级，每个客户端验证4次签名，白白多耗12ms。
- 使用ECDHE而不是DHE：CPU节省10倍以上，且安全强度相当。
- 开启OCSP Stapling：避免客户端逐级查询CRL/OCSP。
- 使用HTTP/2多路复用：在同一个TLS连接上发多个请求，避免重复握手。
嗯，以上就是TLS握手延迟的两个本质来源。记住：RTT是钢需，计算是细节。优先减少RTT数，再优化证书和密钥算法。下一笔优化可以结合具体业务场景，比如CDN加速或者长连接池，但那些属于更高层的架构话题了，咱们先把底层的延迟拆解清楚。