TLS 延迟由什么决定
HTTPS 首连延迟由三部分叠加：网络往返（握手本身要几趟）、握手传输量（证书链的大小）、以及额外的吊销查询。对应的优化手段也很直接：TLS 1.3 把完整握手压缩到 1-RTT；会话复用与票据让回头客免去完整握手；OCSP 装订把吊销信息随握手下发，省掉一次额外往返；证书链瘦身与 TLS 1.3 证书压缩减少传输字节。0-RTT 能进一步省一个往返，但它只适合可重放安全的请求。
基本信息
| 减少往返 | TLS 1.3 为 1-RTT；0-RTT 仅适合可重放安全的请求 |
|---|---|
| 减少传输 | 缩短证书链、使用 ECC 证书、启用 TLS 1.3 证书压缩 |
| 减少依赖 | OCSP 装订避免客户端额外查询吊销状态 |
| 会话复用 | 会话票据或会话 ID 让重复访问跳过完整握手 |
| 量化工具 | curl -w 的分阶段计时，配合多次采样取中位数 |
| 适用前提 | 先测量再优化，多数场景瓶颈在应用与网络 |
典型使用场景
- 跨境访问优化：高 RTT 链路上，减少往返比压缩静态资源更见效。
- 移动网络首连：弱网下握手体积与往返次数都是可见的延迟来源。
- 配置评审：判断某项 TLS 优化是否真的对目标用户有收益。
- 容量评估：握手成本与 CPU 开销一起权衡，避免优化一项拖累另一项。
- 回归对比：变更前后用同一套计时口径验证效果。
分阶段计时
分阶段计时
# 一次完整请求的分阶段耗时
curl -so /dev/null -w 'dns=%{time_namelookup} tcp=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total}\n' https://example.com/
# 重复多次取中位数，避免被单次抖动带偏
for i in 1 2 3 4 5; do curl -so /dev/null -w '%{time_appconnect}\n' https://example.com/; done | sort -n | sed -n 3p
# 对比会话复用效果：第二次请求的 tls 阶段应明显缩短耗时阶段读法
| 阶段 | 含义 | 异常时的方向 |
|---|---|---|
| time_namelookup | DNS 解析耗时 | 解析慢，考虑本地缓存或就近解析 |
| time_connect | TCP 建连耗时 | 接近 RTT，异常大说明网络路径有问题 |
| time_appconnect | TLS 握手完成耗时 | 与 connect 的差值即握手成本 |
| time_starttransfer | 首字节到达耗时 | 含服务端处理，注意与握手分开看 |
| time_total | 总耗时 | 用于整体回归对比 |
优化前先量化：多数业务的首屏瓶颈在应用处理与网络链路，TLS 配置调整带来的收益需要实测数据支撑，否则容易做了一堆改动却看不出变化。