HTTPS 性能：加密并不慢，慢在握手

更新时间：2026-09-17。网络协议域·安全。握手机制见 TLS 握手，1.3 优化见 TLS 1.3，证书/OCSP 见证书链。

很多人以为 HTTPS 慢在加密数据本身。现代 CPU 有 AES-NI 等硬件指令，对称加密（AES-GCM/ChaCha20）对吞吐的影响通常只有个位数百分比。真正可观的开销在建立连接阶段：额外的 RTT 与非对称运算。理解成本结构，优化就有的放矢。

一、成本拆解

一次全新 HTTPS/1.1 over TLS1.2 请求在建连阶段大致付出：

DNS 解析      ~1 次查询（可缓存）
TCP 握手       1 RTT
TLS 握手       约 2 RTT（1.2）+ 证书链传输 + 非对称运算
首个请求       再 1 RTT
------------------------------------
首字节前       高 RTT 网络上累计 3~4 RTT
之后的数据     对称加密，开销很小

1. RTT（往返时延）：高延迟链路（跨境、移动，RTT 50–200ms）握手次数被线性放大，这是用户最有感的延迟。
2. 非对称运算：证书验签、ECDHE/RSA 运算比对称加密贵，主要消耗服务端 CPU（RSA 握手尤其）。
3. 证书链传输：链上每个证书几百~几千字节，还要建连就传，挤占初始拥塞窗口。
4. OCSP/CRL 吊销查询：若客户端实时查 CA，可能再加一次网络往返甚至阻塞握手。

二、优化手段

1. 升级 TLS 1.3：1-RTT/0-RTT

TLS 1.3 把完整握手压到 1 RTT、会话恢复支持 0 RTT，并强制 ECDHE 前向保密——最直接的建连延迟优化（见 TLS 1.3）。注意 0-RTT 只用于幂等安全请求。

2. 会话复用：Session ID 与 Session Ticket

复用之前协商过的密钥材料，恢复连接时跳过完整握手：

方式	原理	备注
Session ID	服务端记住会话，客户端带 ID 回来	服务端要存状态，多机部署需共享会话缓存
Session Ticket（RFC 5077）	服务端把会话状态加密成一张"票"发给客户端，回来时出示，服务端无状态	利于水平扩展；票证密钥要轮换，否则影响前向保密

恢复握手在 TLS1.2 约 1 RTT、1.3 配合 PSK 可 0-RTT。会话复用对"同一用户短时间多次建连"、移动端频繁断连收益明显。前提是票证超时不要过长、密钥定期轮换（票证密钥泄露会解密对应历史会话，与前向保密权衡）。

3. 减少连接数：HTTP/2/3 与 keep-alive

每少建一条 TCP+TLS 连接，就省掉整套握手：

• 启用 HTTP/2（握手里用 ALPN 协商 h2），单连接多路复用，配合 keep-alive/连接池，大幅减少连接数与反复握手。
• 服务端调长 keepalive 超时、客户端用连接池复用上游连接。
• HTTP/3/QUIC 进一步做到 0/1-RTT 且连接迁移。

4. OCSP Stapling（装订）

让服务器把 CA 签发的、带时效的"证书未吊销"凭证在握手时一并交给客户端，避免客户端再单独访问 OCSP 服务器（可能慢、泄露隐私、软失败）：

ssl_stapling on;
ssl_stapling_verify on;
resolver ... valid=300s;

省一次外部往返并提升证书校验可靠性。确保证书链配置正确，否则装订取不到。

5. 证书与密码套件

• 精简证书链：只发叶子 + 必要中间证书（不要把根也发了），减少握手字节；选择体积更小的证书。
• ECDSA 证书（P-256）相比 RSA-2048 签名更小、握手运算更省，性能与安全性都更好（生态已普遍支持）。
• 优先 ECDHE 套件，兼顾前向保密；启用 AES-GCM（有 AES-NI 的 x86）或 ChaCha20-Poly1305（移动/无硬件 AES）。
• 禁用旧协议/弱套件，减少协商不确定，但保留合理兼容。

6. 传输层协同

• 开启 TCP Fast Open、合理的初始拥塞窗口，配合 BBR 等拥塞控制（见TCP 拥塞控制）。
• CDN 就近 TLS 终结，缩短到用户的 RTT；回源可在受控内网用 HTTP 或复用长连接。
• HSTS 让浏览器直接走 HTTPS，省掉一次 301 跳转往返。

三、量化：curl -w 拆解各阶段

curl -o /dev/null -s \
 -w 'dns=%{time_namelookup} tcp=%{time_connect} tls=%{time_appconnect}\n     ttfb=%{time_starttransfer} total=%{time_total}\n' https://example.com
# time_appconnect - time_connect ≈ TLS 握手耗时
# 第二次连接（复用/keep-alive）时 connect/appconnect 可能为 0

• time_connect：TCP 三次握手完成点。
• time_appconnect：TLS 握手完成点；两者之差即 TLS 成本。
• 用浏览器 DevTools Security/Connection 面板确认协商的 TLS 版本、是否命中 1.3 与复用。
• Wireshark 看是否完整握手（含 Certificate）还是 abbreviated（恢复），QUIC 则看 UDP。

四、收益优先级

1. 启 TLS1.3 + HTTP/2（ALPN）——改动小、收益大。
2. 连接复用（keep-alive/连接池/HTTP2）+ CDN 就近终结。
3. 会话票证（注意密钥轮换）、OCSP Stapling。
4. ECDSA、精简链、现代套件。
5. 用 curl/监控持续观测 TLS 握手占比与复用率。

相关阅读

TLS 握手/TLS 1.3/证书链，连接复用见 keep-alive 与 HTTP/2，传输层调参见内核网络调优。

总结

HTTPS 的主要开销不是对称加密而是建连：TCP+TLS 的多个 RTT、非对称运算和证书/OCSP 传输；优化按"升 TLS1.3 与 HTTP/2/ALPN → keep-alive 与连接池减少连接数 → Session Ticket 会话复用与 OCSP Stapling → ECDSA/精简链/ECDHE 套件 → CDN 就近终结"的顺序收益最大，用 curl -w 的 connect/appconnect 差值能量化 TLS 握手成本。