在当今的 Web 性能优化实践中，HTTP/2 与 HTTPS 的协同工作已成为现代网站部署的标配。尽管 HTTP/2 协议规范本身并未强制要求加密，但主流浏览器（Chrome、Firefox、Safari、Edge）均只支持基于 TLS 的 HTTP/2（即 h2）。这意味着，想要获得 HTTP/2 带来的多路复用、头部压缩等性能红利，HTTPS 是必经之路。而在这两者之间扮演“牵线人”角色的，正是 ALPN（Application-Layer Protocol Negotiation）扩展。
本文将深入解析 ALPN 的协商机制，量化 HTTP/2 over HTTPS 的性能收益，并给出可落地的配置要点。
一、ALPN：HTTP/2 与 HTTPS 的“握手协议”
在 ALPN 出现之前，客户端和服务器通过 NPN（Next Protocol Negotiation）扩展协商应用层协议。但 NPN 存在额外往返延迟和实现复杂的问题。ALPN 作为 TLS 扩展（RFC 7301），将协议协商直接嵌入 TLS 握手过程，实现了“零额外延迟”的协议选择。
1.1 ALPN 协商流程
- ClientHello：客户端在 TLS 握手的第一个消息中，通过
application_layer_protocol_negotiation扩展发送自己支持的协议列表，通常为["h2", "http/1.1"]。 - ServerHello：服务器从列表中选择一个自己支持的协议（如
h2），并在 ServerHello 中通过 ALPN 扩展返回该选择。 - 握手完成：TLS 握手成功后，双方立即使用协商好的协议进行应用层通信。若服务器不支持 ALPN 或未选择
h2，则回退到 HTTP/1.1。
整个过程无需额外往返，且对不支持 ALPN 的旧客户端保持兼容。
1.2 为什么 ALPN 对 HTTP/2 至关重要？
- 避免协议降级：没有 ALPN，服务器无法在 TLS 层得知客户端是否支持 HTTP/2，可能错误地使用 HTTP/1.1 响应，导致性能损失。
- 支持多协议共存：同一端口（443）可同时服务 HTTP/1.1、HTTP/2 甚至 HTTP/3（通过 Alt-Svc），ALPN 是区分它们的唯一依据。
- 简化部署：无需为 HTTP/2 分配独立端口或域名，运维成本大幅降低。
二、性能收益：HTTP/2 over HTTPS 的实测优势
HTTP/2 在 TLS 之上运行，虽然增加了加解密开销，但其核心特性带来的性能提升远超 TLS 的额外成本。以下是关键收益点：
2.1 多路复用（Multiplexing）
HTTP/1.1 中，浏览器对同一域名并发连接数限制为 6~8 个，且每个连接同一时刻只能处理一个请求（队头阻塞）。HTTP/2 允许在单个 TLS 连接上并行交错传输多个请求和响应，彻底消除了应用层的队头阻塞。
实测数据：在 100 个资源请求的场景下，HTTP/2 over HTTPS 比 HTTP/1.1 over HTTPS 的页面加载时间减少 30%~50%，具体取决于网络延迟和资源数量。
2.2 头部压缩（HPACK）
HTTP/2 使用 HPACK 算法压缩请求和响应头部。对于重复头部（如 User-Agent、Cookie），HPACK 通过静态表和动态表索引，可将头部体积减少 80%~90%。在移动网络或高延迟链路中，这一优化显著降低了首字节时间（TTFB）。
2.3 二进制分帧与流优先级
HTTP/2 将数据分割为二进制帧，并支持流优先级和依赖关系。服务器可根据优先级智能调度资源，例如优先发送 CSS 和关键 JavaScript，延迟图片加载。虽然优先级机制在实践中有争议，但合理配置仍能改善关键渲染路径。
2.4 服务器推送（Server Push）
服务器可在客户端请求 HTML 时主动推送关联的 CSS、JS 文件，减少往返延迟。但需注意：推送过多会浪费带宽，且浏览器缓存可能已存在资源。建议仅推送关键且未缓存的资源，或使用 Cache-Digest 等机制优化。
2.5 TLS 1.3 的加成
HTTP/2 通常与 TLS 1.3 搭配部署。TLS 1.3 将握手往返从 2-RTT 降至 1-RTT，并支持 0-RTT 恢复。结合 ALPN，客户端可在首次握手即完成协议协商和密钥交换，进一步降低连接建立延迟。
三、配置要点：从 Nginx 到云负载均衡
正确配置 ALPN 和 HTTP/2 是发挥性能优势的前提。以下是主流服务器和云平台的配置要点。
3.1 Nginx 配置
server {
listen 443 ssl http2;
server_name example.com;
ssl_certificate /path/to/fullchain.pem;
ssl_certificate_key /path/to/privkey.pem;
# 启用 TLS 1.2 和 1.3
ssl_protocols TLSv1.2 TLSv1.3;
# 优先使用服务器端密码套件
ssl_prefer_server_ciphers on;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256;
# 启用 ALPN（Nginx 自动处理，无需显式配置）
# 但需确保 OpenSSL 版本 >= 1.0.2
}
注意：Nginx 1.25.1 起支持 http2 on; 指令，不再推荐在 listen 中写 http2。旧版本仍需 listen 443 ssl http2;。
3.2 Apache 配置
<VirtualHost *:443>
ServerName example.com
SSLEngine on
SSLCertificateFile /path/to/cert.pem
SSLCertificateKeyFile /path/to/key.pem
# 启用 HTTP/2
Protocols h2 http/1.1
# 启用 ALPN（mod_ssl 自动处理）
SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
</VirtualHost>
需确保 mod_http2 已加载。
3.3 云负载均衡与 CDN
- AWS ALB：在 HTTPS 监听器上启用 HTTP/2，ALB 自动通过 ALPN 协商。注意：ALB 到后端仍为 HTTP/1.1，需确保后端支持。
- Cloudflare：默认启用 HTTP/2 和 HTTP/3，ALPN 自动处理。可在 SSL/TLS 设置中开启“HTTP/2”和“HTTP/3”。
- Google Cloud Load Balancer：创建 HTTPS 负载均衡器时勾选“HTTP/2”，ALPN 自动生效。
3.4 常见陷阱与排查
- ALPN 未生效：使用
openssl s_client -alpn h2 -connect example.com:443检查服务器是否返回ALPN protocol: h2。若返回No ALPN negotiated，则说明服务器未正确配置。 - TLS 版本过低：TLS 1.0/1.1 不支持 ALPN，必须启用 TLS 1.2+。
- 证书链不完整：ALPN 协商在 TLS 握手早期进行，但证书验证失败会导致连接中断。确保使用完整证书链。
- HTTP/2 与旧客户端兼容：若客户端不支持 ALPN，服务器应回退到 HTTP/1.1。Nginx 默认行为正确，无需额外配置。
- 服务器推送滥用：推送资源需设置正确的
cache-control和vary头，避免重复推送。
四、总结
HTTP/2 与 HTTPS 的协同并非简单的“加密 + 新协议”，而是通过 ALPN 在 TLS 握手阶段无缝协商，实现了性能与安全的双赢。多路复用、头部压缩、二进制分帧等特性在 HTTPS 之上发挥出最大价值，而 TLS 1.3 的普及进一步放大了这一优势。
部署时，请确保：
- 使用 TLS 1.2 或 1.3，并启用 ALPN；
- 在 Nginx/Apache 或云负载均衡上正确开启 HTTP/2；
- 通过
openssl s_client验证 ALPN 协商结果； - 监控 HTTP/2 连接的性能指标，避免服务器推送等特性被误用。
随着 HTTP/3 的逐步落地，ALPN 仍将是协议协商的核心机制（HTTP/3 使用 h3 标识）。掌握 ALPN 与 HTTP/2 的配置要点，是每一位 Web 运维和开发人员的必备技能。
未经允许不得转载：任鹏个人博客 » HTTP/2 与 HTTPS 的协同：ALPN 协商、性能收益与配置要点
朋友圈点赞图在线生成源码
