HTTPS 比 HTTP 慢吗？有哪些性能优化手段？

简化版

HTTPS 确实比 HTTP 多了开销，但主要在首次握手（多几个 RTT + 加解密计算），数据传输阶段的对称加密开销几乎可忽略。优化方向：减少握手次数/往返（会话复用、TLS 1.3、连接复用/HTTP2）、降低加解密成本（ECC 证书、硬件加速）、减少证书验证开销（OCSP Stapling）。现代优化下，HTTPS 和 HTTP 的性能差距已经很小。

详细版

HTTPS 的额外开销来自两块：

握手开销（主要）：TLS 握手要额外的往返（TLS 1.2 需 2-RTT，1.3 需 1-RTT），以及非对称加密的计算（协商密钥、验证证书）；
加解密开销（次要）：数据传输用对称加密，但对称加密（AES）非常快，现代 CPU 还有硬件指令（AES-NI）加速，几乎可忽略。

常见优化手段：

升级 TLS 1.3：握手 2-RTT → 1-RTT，会话恢复 0-RTT；
会话复用（Session Resumption）：重连时跳过完整握手——Session ID（服务端存状态）或 Session Ticket（无状态，服务端把加密的会话信息交给客户端保存）；
连接复用：HTTP/1.1 Keep-Alive、HTTP/2 多路复用——一个 TLS 连接承载多个请求，摊薄握手成本；
OCSP Stapling：服务器主动附上证书吊销状态，省去客户端单独查询 CA 的往返；
ECC 证书：椭圆曲线证书比同等安全强度的 RSA 证书密钥更短、计算更快；
CDN / TLS 卸载：在离用户近的边缘节点终结 TLS，缩短握手 RTT。

完整版教学

一、慢在哪：握手是大头，加密可忽略

要回答「HTTPS 慢不慢」，得分清两个阶段：

握手阶段：这是 HTTPS 相对 HTTP 主要的额外成本——多了 TLS 握手的往返和非对称运算。在高延迟网络（移动端）下，多一两个 RTT 是能感知的。
数据传输阶段：用对称加密（AES 等），速度极快，加上 CPU 的 AES-NI 硬件加速，加解密开销小到基本可忽略。

所以「HTTPS 慢」主要慢在建连握手，而不是「加密数据本身慢」。优化的重点自然是减少和加速握手。

二、会话复用：避免重复的完整握手

同一个用户短时间内多次连接，每次都做完整握手太浪费。会话复用让重连时跳过大部分握手，直接复用之前协商的密钥，有两种机制：

Session ID：首次握手后服务器给一个会话 ID 并在服务端保存会话状态，重连时客户端带上 ID，服务器查到就快速恢复。缺点是服务端要存状态，分布式下多机器要共享。
Session Ticket：服务器把会话状态加密成一张 ticket 交给客户端保存（服务端不存），重连时客户端带上 ticket，服务器解密即可恢复。无状态，对分布式友好。

TLS 1.3 用基于 PSK（预共享密钥） 的恢复机制统一了会话复用，还支持 0-RTT。

三、连接复用:一次握手，多次请求

握手成本是「一次性」的——只要连接不断，后续请求就不用再握手。所以尽量复用连接能极大摊薄握手开销：

HTTP/1.1 Keep-Alive：一个 TCP+TLS 连接连续处理多个请求；
HTTP/2 多路复用：一个连接上并发多个请求，一次握手服务所有请求，效果更好。

这也是为什么 HTTP/2 只在 HTTPS 上启用——用连接复用抵消了 HTTPS 的握手成本，甚至整体比明文 HTTP/1.1 还快。

四、其他优化点

TLS 1.3：本身就把握手减到 1-RTT，是最直接的提速（详见「TLS 1.2 和 1.3 的区别」那道题）。
OCSP Stapling：验证证书要查它有没有被吊销，客户端单独去问 CA 会增加一次往返。OCSP Stapling 让服务器代为查询并把结果「钉」在握手里一起发给客户端，省掉这次往返，还保护隐私。
ECC 证书：256 位的 ECC 证书安全性约等于 3072 位 RSA，但密钥更短、握手计算更快、传输更小。
CDN 边缘终结：让 TLS 握手在离用户最近的 CDN 节点完成，RTT 更短。

五、常见误区

❌ 以为 HTTPS 慢是因为「加密数据慢」——对称加密极快，慢主要在握手往返。
❌ 以为 HTTPS 一定比 HTTP 慢很多——配合 TLS 1.3、会话复用、HTTP/2，差距已很小甚至反超。
❌ 忽略会话复用——重复完整握手是很大的浪费，Session Ticket / TLS 1.3 恢复能省很多。
❌ 以为证书验证不耗时——OCSP 查询可能增加往返，用 OCSP Stapling 优化。

六、常见误区与追问

考点	正确口径
额外开销	TLS 握手、证书验证、密钥协商
数据加密	现代对称加密通常不是主要瓶颈
优化	TLS 1.3、会话复用、连接复用、OCSP Stapling

full handshake -> more RTT and CPU
resumption -> fewer RTT
HTTP/2/3 -> reuse connection for many requests

HTTPS 的主要开销在握手阶段，连接复用后单个请求摊销成本会明显下降。

误区：HTTPS 慢主要因为每个字节加密很慢。 现代 AES/ChaCha20 很快，握手 RTT 和证书校验更常是主要成本。
误区：每个 HTTPS 请求都要完整 TLS 握手。 长连接、会话复用、HTTP/2 多路复用可以摊薄握手成本。
误区：上 HTTPS 后就无法缓存。 HTTPS 一样支持 HTTP 缓存，只是共享代理缓存语义更谨慎。
追问：TLS 1.3 如何提速？ 完整握手通常 1-RTT，并支持更高效的会话恢复。
追问：OCSP Stapling 优化什么？ 服务器把证书状态证明随握手发给客户端，减少客户端单独查询 CA 的延迟。
追问：证书链过长有什么影响？ 增加传输字节和验证成本，应配置完整但不过度冗余的证书链。

七、加强记忆

HTTPS 的额外开销主要在首次握手（多 RTT + 非对称运算），数据传输的对称加密几乎可忽略。优化围绕「减少和加速握手」：升级 TLS 1.3（1-RTT/0-RTT）、会话复用（Session ID / Ticket）、连接复用（Keep-Alive / HTTP2）、OCSP Stapling、ECC 证书、CDN 边缘终结。现代优化下 HTTPS 与 HTTP 性能差距很小。

简化版

详细版