3. TLS性能开销概述：握手延迟、计算开销、网络开销、内存开销
说实话，TLS 的开销问题，我刚开始做 HTTPS 优化时也踩过不少坑。很多人都觉得 TLS 就是加个证书、改个端口，跑起来就行了。但当你面对每秒几万请求的业务时，那点「额外开销」会被放大到让你头疼。今天我们就掰开揉碎，看看 TLS 到底在哪些地方「偷」走了我们的性能。
3.1 握手延迟：最让用户感知的痛
TLS 握手平均需要 1-3 个 RTT（往返时延）。如果是新加坡的客户端连美国的服务器，一个 RTT 可能就要 200ms。你想想看，用户点一下按钮，白屏等 600ms，这体验能好吗？
我习惯把握手延迟拆成两部分来看：
- TCP 握手：1 个 RTT，基础开销，跑不掉
- TLS 握手：1-2 个 RTT，取决于版本和会话复用情况
具体来说，TLS 1.2 完整握手需要 2 个 RTT（ClientHello → ServerHello + Certificate → ClientKeyExchange → Finished），而 TLS 1.3 只用了 1 个 RTT。更狠的是，如果之前已经连接过，TLS 1.3 支持 0-RTT 模式——第一次请求就能发数据。我曾在项目中把 CDN 节点的 TLS 版本从 1.2 升级到 1.3，首屏加载时间直接降了 30%。
| TLS 版本 | 完整握手 RTT | 恢复握手 RTT | 0-RTT 支持 |
|---|---|---|---|
| TLS 1.2 | 2 | 1 | 否 |
| TLS 1.3 | 1 | 0 | 是（需配合 PSK） |
3.2 计算开销：证书验证与加密解密
很多人觉得 TLS 慢是因为网络，其实计算开销也不小。尤其是握手阶段的非对称加密——RSA 或 ECDHE 密钥交换，CPU 忙得吱吱叫。
我记得有一次压测，服务端 CPU 冲到 95%，一查全是握手线程在跑 RSA 2048 签名。后来换成 ECDHE（椭圆曲线 Diffie-Hellman），CPU 占用直接腰斩。为什么会这样？因为同样安全强度下，椭圆曲线运算量比 RSA 小得多。
- 非对称运算：主要在握手阶段，每连接执行一次。ECDHE 比 RSA 快 2-4 倍
- 对称加密：数据传输阶段，AES-128-GCM 硬件加速下几乎无感知
- 证书链验证：如果证书链长（比如 3-4 级），每次验证都要算多次签名
我在做 IoT 设备优化时，碰上过内存只有 256KB 的芯片跑 TLS。当时连 ECDHE 都太重，最后用了 Pre-Shared Key 模式，完全绕开了非对称运算。说白了，场景决定方案，别为了秀技术把设备搞死。
3.3 网络开销：数据包膨胀与额外往返
TLS 握手不仅仅是 RTT，还有数据包大小。一个典型的 TLS 1.2 握手报文加起来大约 5-8KB。证书如果太大（比如 4096 位 RSA + 多级 CA），光证书就占 4KB 以上。这在高延迟链路下，会显著增加传输时间。
你想想看，用户用的是移动网络，TCP 初始拥塞窗口通常只有 10 个 MSS（约 1.5KB）。握手报文可能超过初始窗口，只能分多次发送，RTT 又被拉长。
我曾遇到过一个海外项目，客户端连 AWS 新加坡，TLS 握手要 1.2 秒。分析后发现是证书链太大，路由器还做了 MTU 分片。我建议换 ECDSA 证书（体积是 RSA 的 1/3），同时启用 TCP 快速打开（TFO），握手时间降到 0.7 秒。
3.4 内存开销：连接状态的代价
TLS 每个连接都要维护一个会话状态：加密密钥、序列号、压缩上下文等。我习惯粗略估算一下：每个 TLS 连接大约占用 2-4KB 内存（包括 SSL 对象和缓冲区）。如果你的服务器有 10 万并发连接，光 TLS 状态就要吃掉 200-400MB。这还没算上应用层缓冲区。
更隐蔽的是，TLS 1.3 的 0-RTT 虽然快，但服务端需要存储 PSK（预共享密钥）一段时间。如果并发高，PSK 存储会占用大量内存。我在一个消息推送服务里，为了支持千万级长连接，不得不限制每个用户的 PSK 生存期到 5 分钟，并定期清理。
| 项目 | 大小（估算） | 备注 |
|---|---|---|
| SSL 对象 | 1-2 KB | openssl / boringssl |
| 读写缓冲区 | ~0.5 KB each | 默认 16KB，但实际使用远小于 |
| 会话缓存（复用） | ~1 KB per entry | 如果开启会话复用 |
| 0-RTT PSK 存储 | ~0.2 KB per key | TLS 1.3 特有 |
我的建议：别把 TLS 内存开销当成“小问题”。在内存受限的环境中（比如 Docker 容器设了 256MB limit），一次突发连接增长就有可能 OOM。我个人习惯在监控里加一条“TLS 连接数 vs 内存使用率”的曲线，超过阈值就触发告警。
3.5 开销总览：一张图说清楚
下面的图把四种开销的关系和影响范围画出来了。你可以看到，握手延迟是「最外层」的瓶颈，计算和网络是它的具体来源，而内存则贯穿整个连接生命周期。
嗯，看完这张图你应该能直观感受到：优化 TLS 性能，不能只盯着一个点。我个人处理线上问题时，会按这个顺序排查：先看握手 RTT（网络层），再看证书大小（计算+网络），最后查内存峰值。一步一步来，别慌。