HTTP/1.1 的痛
一个连接同一时刻只能处理一个请求，多个资源要排队（队头阻塞），浏览器只能开多个连接缓解，代价是握手和开销。
HTTP/2 的改进
- 多路复用：一个连接上并发多个请求 / 响应，不再互相阻塞；
- 头部压缩：HPACK 压缩重复的请求头，省带宽；
- 服务端推送：可主动推资源（实际用得少，且常被弃用）。
HTTP/3 为何换 UDP
HTTP/2 虽多路复用，但底层 TCP 丢一个包仍会堵住所有流（TCP 层队头阻塞）。HTTP/3 改跑在 QUIC（基于 UDP）上，每个流独立，丢包只影响自己；且 0-RTT 建连更快。
两个提醒
- 不是万能：应用层慢（接口本身慢）再换协议也救不了；
- TLS 是前提：HTTP/2、HTTP/3 在浏览器端基本都要求 HTTPS。
实战案例：升级之后为什么没变快
- 还在做域名分片：HTTP/1.1 时代为绕过单域名 6 连接上限而拆分域名，HTTP/2 下多域名反而要各自建连握手。升级后应合并回同一域名。
- 把 JS / CSS 打成一个巨型文件：HTTP/2 有多路复用，按路由与组件合理拆包能提高缓存命中率，首屏只需少量关键资源。
- QUIC 被网络拦掉：HTTP/3 走 UDP 443，部分企业网络与旧中间设备直接丢包，客户端回退 TCP 反而多一次延迟。上线 HTTP/3 要保留 HTTP/2 回退并监控回退比例。
常见问题（FAQ）
HTTP/2 还有队头阻塞吗？在 TCP 层仍有：一个丢包会阻塞同一连接上的所有流；HTTP/3 基于 QUIC 才消除了传输层队头阻塞。要给 HTTP/2 单独配证书吗？不需要，与 HTTPS 共用同一证书，协商在 ALPN 阶段完成。服务器推送还用吗？主流浏览器已移除支持，改用 preload 与 103 Early Hints 更实际。用什么指标验证升级效果？看连接数、TLS 握手耗时、首字节时间与首屏资源竞速，别只盯单个文件的下载速度。
迁移与灰度验证
- 先确认全站 HTTPS：HTTP/2 在主流浏览器中几乎只通过 TLS 协商，未全站 HTTPS 时升级无从谈起；
- 开启 ALPN 协商并保留回退：服务端同时声明
h2与http/1.1，让旧客户端自动回落；HTTP/3 则保留 TCP 回退； - 灰度放量：先对内部与小比例用户开启，观察错误率、握手耗时与回退比例，再逐步扩大；
- 重新审视旧优化：域名分片、雪碧图与小文件合并等 HTTP/1.1 时代的技巧应逐项评估，很多在 HTTP/2 下已成负担；
- 验证关键指标：对比升级前后的连接数、TLS 握手耗时、首字节时间与首屏资源竞速，用数据而不是感觉判断收益。
需要注意的是，协议升级不会自动解决应用层问题：服务端渲染慢、数据库查询慢导致的 TTFB 劣化，换协议一样快不了。
与前端构建策略的配合
- 按路由而非按类型拆分：把资源拆成入口与按需加载的若干块，首屏只加载必要部分，既提升缓存命中率，也避免把所有代码塞进一个巨大文件。
- 依赖变更频率分层：第三方依赖变化少、业务代码变化多，分成不同的块后，发版时用户只需重新下载业务部分，依赖可从缓存复用。
- 关键资源尽早发现：把首屏必需的样式与脚本以显式声明的方式提前告知浏览器，减少解析 HTML 后才发起请求的延迟。
- 避免过量请求：多路复用降低了并发成本，但每个请求仍有头部与处理开销，几十个小文件仍不如适度合并，需要按实测决定。
- 测量以真实用户为准：实验室数据只能反映理想网络，应结合真实用户的加载指标评估优化效果，尤其是移动网络下的首屏时间。
协议升级带来的是可能性，真正决定体验的仍是资源组织方式与首屏关键路径的取舍。