延迟的根源：深入分析TLS握手中的网络往返（RTT）与计算开销
聊TLS性能优化，绕不开一个核心问题：延迟到底从哪来？
很多人一提到TLS就说“慢”，但到底慢在哪？我见过不少团队，上来就砸钱升级硬件，结果延迟没降多少。说白了，没找到根因。
TLS握手阶段的延迟，主要来自两个大头：网络往返（RTT）和计算开销。咱们一个一个拆开看。
2.1 网络往返：TLS握手到底要跑几趟？
先看一个最经典的场景——完整的TLS 1.2握手。你想想看，客户端和服务器之间要交换多少消息？
完整TLS 1.2握手流程（不含HTTP数据）：
- 第1次RTT：ClientHello → ServerHello + 证书 + ServerHelloDone
- 第2次RTT：ClientKeyExchange + ChangeCipherSpec + Finished → ChangeCipherSpec + Finished
算下来，至少2个RTT。如果算上TCP的三次握手，那就是3个RTT才能开始传数据。
我记得有一次帮一家电商公司做性能诊断，他们的用户分布在东南亚，网络延迟本来就高。完整握手下来，光握手就花了400多毫秒。用户早跑了。
那TLS 1.3呢？它把握手压缩到了1个RTT。怎么做到的？
- 客户端直接猜一个密钥交换参数，发在ClientHello里
- 服务器如果同意，直接回复ServerHello + 完成消息
- 一次往返，握手结束
但这里有个坑：如果客户端猜错了（比如服务器不支持那个曲线），就得回退到完整的1-RTT握手。嗯，这种情况我遇到过，概率不高，但一旦发生，延迟反而更难看。
我的建议：在服务端优先配置主流的椭圆曲线（如X25519、P-256），减少客户端猜错的概率。同时开启TLS 1.3的0-RTT模式，但要注意重放攻击的风险。
2.2 计算开销：非对称加密到底有多重？
网络往返是“等”出来的，计算开销则是“算”出来的。TLS握手阶段，计算开销主要集中在两个地方：
- 证书验证：客户端要验证服务器证书的签名链
- 密钥交换：基于非对称加密算法生成会话密钥
非对称加密，说白了就是“慢”。RSA 2048位的私钥签名操作，在普通服务器上大概需要1-2毫秒。听起来不多？但如果你的服务器每秒要处理几万次握手，这个开销就炸了。
我曾经帮一个金融客户做压测，发现他们的TLS握手成功率在高峰期只有60%。一查，CPU全耗在RSA解密上了。后来换成ECDHE密钥交换，CPU负载直接降了40%。
| 算法 | 操作类型 | 相对耗时（参考值） | 适用场景 |
|---|---|---|---|
| RSA 2048 | 私钥签名/解密 | 高 | 传统兼容、证书签名 |
| ECDHE P-256 | 密钥交换 | 中 | 现代TLS 1.2/1.3 |
| X25519 | 密钥交换 | 低 | 性能优先、TLS 1.3推荐 |
| Ed25519 | 签名 | 极低 | 证书签名、替代RSA |
避坑指南：我曾经见过一个团队，为了“安全”把所有证书都换成了RSA 4096位。结果握手延迟翻倍，用户投诉不断。安全是安全了，业务没了。记住：安全与性能需要平衡，不是越强越好。
2.3 对称加密：握手之后的“隐形开销”
握手完成后，数据传输用的是对称加密。对称加密本身很快（AES-NI指令集加持下，AES-128-GCM可以做到几GB/s的吞吐），但这里有个容易被忽略的点：每次加密/解密都需要初始化向量（IV）和附加数据（AAD）。
如果你用的是AES-CBC模式，还得处理填充和MAC计算。嗯，这个模式我建议能不用就不用。GCM模式不仅快，还省掉了单独的MAC计算。
我个人的习惯是：优先选择AEAD（Authenticated Encryption with Associated Data）算法，比如AES-128-GCM或ChaCha20-Poly1305。前者在支持AES-NI的CPU上更快，后者在移动设备上表现更好。
2.4 一张图看懂TLS延迟的根源
下面这张图，把TLS握手阶段的延迟来源拆解清楚了。你可以看到，网络往返和计算开销是两条并行的“延迟线”。
2.5 实战中的“隐形杀手”
除了上面这些，还有几个容易被忽略的点：
- 证书链长度：证书链越长，客户端需要验证的签名越多。我见过一个客户，证书链有5层，每次握手光验证就要多花10毫秒。
- OCSP Stapling：如果没开启，客户端还得自己去查证书吊销状态，又多一次网络请求。
- Session Resumption：这个机制可以跳过完整的握手，但很多人没配置好，导致复用率极低。
我的建议：用Wireshark抓包，看看你的TLS握手到底花了几个RTT。很多时候，问题出在配置上，而不是协议本身。