1. TLS 协议基础回顾：握手流程、密码套件、证书链验证，以及它们对性能的潜在影响
聊 TLS 性能优化，得先回到协议本身。很多人一上来就调参数、改配置，结果握手还是慢、吞吐还是低。为什么？因为没搞清楚底层在干什么。
我自己的习惯是，先画一张完整的握手流程图，把每个步骤的耗时拆开看。你想想看，一次 TLS 握手，客户端和服务端要交换多少条消息？每条消息里又藏着哪些计算开销？把这些理清了，优化才有方向。
1.1 完整的 TLS 1.2 握手流程
先看最经典的 TLS 1.2 完整握手。我当年刚接手一个高并发网关项目时，就是靠这张图定位到握手耗时占了总连接时间的 70%。
看到没？一次完整握手需要 2 个 RTT（网络往返）才能开始传数据。第一个 RTT 交换 Hello 和证书，第二个 RTT 交换密钥和完成消息。如果客户端和服务端相距 100ms，光握手就耗掉 200ms。
我在项目中遇到过最极端的情况：客户端在东南亚，服务端部署在美西，RTT 接近 300ms。一次 TLS 握手就要 600ms，用户早就没耐心了。后来我们上了会话复用和 0-RTT，才把延迟压下来。
1.2 密码套件：安全与性能的博弈
密码套件这东西，说白了就是一组加密算法的组合。你选什么套件，直接决定了握手时的计算开销和数据传输的吞吐能力。
我见过不少团队，为了「绝对安全」直接上 ECDHE-ECDSA-AES256-GCM-SHA384，结果压测时 CPU 直接飙到 90%。其实没必要，大部分场景下 AES-128-GCM 就足够了。
| 密码套件组件 | 常见选项 | 性能影响 | 我的建议 |
|---|---|---|---|
| 密钥交换 | RSA / DHE / ECDHE | ECDHE 比 DHE 快 3-5 倍，RSA 无前向安全性 | 优先 ECDHE，曲线选 X25519 或 P-256 |
| 身份认证 | RSA / ECDSA | ECDSA 签名比 RSA 快 2-4 倍，验证速度相当 | 新系统用 ECDSA，兼容旧设备保留 RSA |
| 对称加密 | AES-128-GCM / AES-256-GCM / ChaCha20 | AES-128 比 AES-256 快约 40%（有硬件加速时差距缩小） | 移动端优先 ChaCha20，服务端用 AES-128-GCM |
| 哈希算法 | SHA-256 / SHA-384 | SHA-256 比 SHA-384 快约 30% | SHA-256 足够，除非合规要求 SHA-384 |
嗯，这里要注意一个坑：前向安全性。RSA 密钥交换没有前向安全性，一旦私钥泄露，之前所有的通信记录都能被解密。我建议所有新系统都上 ECDHE，虽然握手时多一次椭圆曲线计算，但安全收益远大于那几毫秒的代价。
1.3 证书链验证：被忽视的性能杀手
证书链验证，很多人觉得就是「检查一下证书是否有效」而已。其实不然，这里面藏着好几个性能陷阱。
一次完整的证书链验证，包括以下步骤：
- 解析证书：读取 X.509 结构，提取公钥、签名、有效期等信息
- 构建证书链：从叶子证书开始，逐级向上找到根证书
- 签名验证：用上级证书的公钥验证下级证书的签名
- 有效期检查：确认每个证书都在有效期内
- 吊销状态检查：通过 CRL 或 OCSP 确认证书未被吊销
- 主机名验证：检查证书中的 CN 或 SAN 是否匹配请求的域名
这里面最耗时的，是 签名验证 和 吊销状态检查。签名验证涉及非对称解密操作，证书链越长，计算量越大。吊销检查如果走 OCSP，还需要额外的 HTTP 请求。
我记得有一次排查一个 API 网关的慢连接问题，发现每次握手都要花 200ms 做 OCSP 查询。后来启用了 OCSP Stapling，让服务端自己缓存 OCSP 响应并推送给客户端，握手时间直接降到 40ms。
- 证书链长度控制在 3 级以内（叶子 → 中间 → 根）
- 启用 OCSP Stapling，避免客户端自己查询吊销状态
- 使用 ECDSA 证书替代 RSA 证书，签名验证更快
- 证书文件大小尽量控制在 2KB 以内，减少网络传输
1.4 握手流程中各阶段的性能开销拆解
光说概念不够，我们来拆一下实际耗时。我习惯把一次 TLS 握手拆成四个阶段：
| 阶段 | 主要操作 | 耗时占比（典型值） | 优化方向 |
|---|---|---|---|
| 网络往返 | TCP 三次握手 + TLS 消息交换 | 40%-60% | 会话复用、TLS 1.3、0-RTT |
| 证书传输 | 服务端发送证书链 | 10%-20% | 缩短证书链、使用 ECDSA 证书 |
| 密钥协商 | ECDHE 密钥对生成 + 共享密钥计算 | 10%-15% | 使用 X25519 曲线、硬件加速 |
| 证书验证 | 签名验证 + 吊销检查 | 15%-25% | OCSP Stapling、证书缓存 |
你看，网络往返占了将近一半的耗时。这就是为什么我反复强调：减少 RTT 是 TLS 性能优化的第一要务。证书验证虽然占比不高，但它是纯计算开销，在 CPU 密集型的网关或反向代理上，这个比例会显著上升。
1.5 从 TLS 1.2 到 TLS 1.3：性能的跨越式提升
TLS 1.3 是我个人非常推崇的版本。它把握手从 2-RTT 砍到 1-RTT，还支持 0-RTT 模式。怎么做到的？说白了就是「合并消息」和「减少协商」。TLS 1.3 的握手只有两条消息：ClientHello 和 ServerHello，密钥协商和证书交换都在一个往返里完成。
我去年帮一个电商平台做性能优化，从 TLS 1.2 升级到 1.3 后，首屏加载时间从 2.8 秒降到 1.6 秒，其中 TLS 握手时间从 400ms 降到 120ms。这个收益是立竿见影的。
不过要注意，TLS 1.3 的 0-RTT 模式有重放攻击的风险。我建议只在幂等的 GET 请求上启用 0-RTT，POST 请求还是走完整握手更安全。