HTTPS 如何优化？

HTTPS（HyperText Transfer Protocol Secure）的性能优化是一个系统工程，核心目标是在保证安全的前提下，尽可能减少握手延迟、降低传输开销、提升并发处理能力。

随着 HTTP/2 和 HTTP/3 的普及，以及 TLS 1.3 成为主流，优化的重点已从单纯的"减少握手次数"转向了"协议特性利用"和"全链路加速"。

这是提升 HTTPS 性能最根本的手段，收益远大于应用层微调。

原理：TLS 1.3 将握手过程从 TLS 1.2 的 2-RTT（往返时延）减少到 1-RTT ，甚至支持 0-RTT（在复用连接时）。它移除了不安全的加密算法，简化了握手流程。
操作：
- 在 Web 服务器（Nginx, Apache, OpenResty）或负载均衡器中明确配置 ssl_protocols TLSv1.3;。
- 禁用 TLS 1.0/1.1/1.2（除非有极特殊的旧客户端兼容需求）。
收益：首屏加载时间（FCP）显著降低，特别是在高延迟网络（如弱网、跨国访问）下效果明显。

HTTP/2 ：
- 多路复用：解决队头阻塞问题，允许在一个 TCP 连接上并行发送多个请求/响应，极大减少了建立多个 TCP/TLS 连接的开销。
- 头部压缩 (HPACK)：减少重复请求头的传输体积。
- 服务器推送 (Server Push)：虽然现代浏览器对其支持有所保留（有时甚至禁用），但在特定场景下仍可主动推送关键资源。
HTTP/3 (基于 QUIC) ：
- 基于 UDP：彻底解决了 TCP 层面的队头阻塞问题。
- 连接迁移：用户从 WiFi 切换到 4G/5G 时，无需重新握手，连接保持有效。
- 内置 TLS 1.3：强制加密，且握手更快。
操作：
- Nginx 1.25+ 或其他现代网关已原生支持 HTTP/3。
- 配置 listen 443 ssl http2; 和 listen 443 quic;。
- 添加响应头 Alt-Svc: h3=":443"; ma=86400 告知客户端支持 HTTP/3。

原理：避免每次请求都进行完整的 TLS 握手。
- Session ID：传统的复用方式，依赖服务器端缓存。
- Session Tickets (RFC 5077)：将会话状态加密后发送给客户端，客户端下次访问时带回，服务器解密即可恢复会话。这种方式更适合分布式集群（需同步 Ticket Key）。
操作：在 Nginx 中配置 ssl_session_cache shared:SSL:10m; 和 ssl_session_tickets on;。
收益：将后续请求的握手开销降至几乎为零。

痛点：传统模式下，浏览器需要单独向 CA 机构查询证书是否被吊销（OCSP 请求），这会增加额外的 DNS 解析和 TCP 连接耗时，且受限于 CA 服务器的稳定性。
优化：由服务器定期向 CA 查询并缓存 OCSP 响应，在 TLS 握手时直接"装订"发给客户端。
操作：Nginx 配置 ssl_stapling on; 和 ssl_stapling_verify on;。
收益：减少一次外部网络请求，提升握手速度约 30%-50%。

椭圆曲线 (ECC) 证书：相比传统的 RSA 证书，ECC（如 P-256, P-384）在同等安全强度下，密钥更短，计算速度更快，握手时的 CPU 消耗更低，传输数据量更小。
证书链优化：确保服务器发送的证书链是完整的且顺序正确（叶证书 -> 中间证书），避免客户端去下载缺失的中间证书。
早期提示 (Early Hints, RFC 8297) ：配合 HTTP/2 使用，服务器在正式响应准备好之前，先发送 103 Early Hints 状态码，告诉浏览器提前预加载关键资源（如 CSS, JS），进一步掩盖网络延迟。

Brotli (br) ：相比 Gzip，Brotli 在文本资源（HTML, CSS, JS）上的压缩率通常高出 15%-20%。虽然压缩时更耗 CPU，但解压速度快，且能显著减少传输字节数。
- 注意：建议对静态资源进行预压缩 （.br 文件），避免动态压缩消耗服务器 CPU。
Zstandard (zstd)：在某些新场景下开始流行，提供速度与压缩率的更好平衡，但目前浏览器支持度不如 Brotli 普及。

初始拥塞窗口 (Initial Congestion Window, initcwnd)：默认值通常较小（如 10 MSS）。将其调大（如 30 或 40），允许在第一个 RTT 内发送更多数据包，显著加快小文件的传输速度。
TCP Fast Open (TFO)：允许在 TCP 三次握手的同时发送数据，减少一个 RTT。需在操作系统和 Web 服务器同时开启。
Keep-Alive 调优 ：适当延长 keepalive_timeout，增加 keepalive_requests，让一个连接服务更多请求，减少频繁建连的开销。