HTTPS握手慢主因是RTT叠加计算开销，优化需聚焦四阶段：连接前启0-RTT与HSTS、握手交互用TLS1.3+X25519、证书验证配OCSP装订与ECDSA、密钥协商后设会话缓存及HTTP/2多路复用。
HTTPS 握手慢，不是因为“加密本身太重”，而是多个环节叠加了网络往返（RTT）和计算开销。一张图能帮你理清脉络，但真正落地优化，得盯住四个关键阶段：连接建立前、握手交互中、证书验证时、密钥协商后。下面按实际发生顺序拆解各阶段的瓶颈点和对应参数配置，全部基于 TLS 1.3 + HTTP/2/3 主流环境（截至2026年）。
连接建立前：减少首次访问延迟
用户输入网址后，DNS 解析、TCP 连接、TLS 协商依次发生。这里最易被忽略的是“零RTT准备”：
-
TLS 1.3 0-RTT 启用前提：客户端必须曾访问过该域名且服务器缓存了有效 ticket；需配置
ssl_session_tickets on和稳定的ssl_session_ticket_key（集群部署时务必同步） -
HSTS 预加载生效：避免首次访问走 HTTP 再 301 跳转；提交到 hstspreload.org 并配置
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" -
Alt-Svc 头声明 HTTP/3 支持：让客户端提前知道可切 QUIC，例如
Alt-Svc: h3=":443"; ma=86400
握手交互中：压缩往返与计算耗时
TLS 1.3 已将标准握手压到 1-RTT，但仍有优化空间：
-
禁用旧协议直截了当：Nginx 中只留
ssl_protocols TLSv1.3；Apache 用SSLProtocol -all +TLSv1.3 -
密钥交换算法聚焦 ECDHE + X25519：比 P-256 更快更安全；OpenSSL 3.x 默认启用，Nginx 无需额外配，但需确认
ssl_ciphers中包含ECDHE-ECDSA-AES128-GCM-SHA256等现代套件 -
减小 TLS record size：
ssl_buffer_size 4k（非默认 16k），降低 TTFB，尤其对首屏 HTML 加载敏感
证书验证时：绕开外部依赖链
传统 OCSP 查询常因 CA 服务不稳定拖慢首屏，OCSP Stapling 是必选项：
-
开启 stapling 并强制验证：Nginx 配置
ssl_stapling on; ssl_stapling_verify on;，同时确保ssl_trusted_certificate指向完整证书链（含中间 CA） - 使用 ECDSA 证书替代 RSA：签名体积更小、验签更快；配合 Let’s Encrypt 的 ECC 免费证书，部署无门槛
-
关闭 CRL 检查：现代浏览器已弃用，Nginx 默认不启用，确认未配置
ssl_crl即可
密钥协商后：提升并发与复用效率
握手完成≠性能到位，后续请求仍可能重复开销：
-
会话缓存分层设置：
ssl_session_cache shared:SSL:20m（支持约 8 万个会话），配合ssl_session_timeout 4h；若用 session tickets，ssl_session_tickets on必须开启 -
HTTP/2 多路复用 + HPACK 压缩：Nginx listen 行加
http2，并确保响应头未被代理意外剥离（如某些 CDN 会删掉:status伪头） -
启用 early data 但慎用：0-RTT 数据有重放风险，仅对幂等接口（如 GET /api/status）开启，Nginx 中通过
ssl_early_data on控制
