版本对比与前端性能实践
基于 HTTP 现代标准 · 核于 2026-06
速查
- 传输层：HTTP/1.1 与 HTTP/2 都跑在 TCP 上；HTTP/3 改跑 QUIC（基于 UDP），自带加密与多路复用。
- 多路复用：HTTP/1.1 无（单连接串行 + 每源 ~6 条并发）；HTTP/2 单连接多路复用；HTTP/3 同样多路复用且流间互不阻塞。
- 队头阻塞层级：HTTP/1.1 在应用层；HTTP/2 应用层已消除，但仍有 TCP 层队头阻塞；HTTP/3 用 QUIC 把队头阻塞彻底消除到流粒度。
- 头部压缩：HTTP/1.1 无（明文重复传）；HTTP/2 用 HPACK；HTTP/3 用 QPACK（适配 QUIC 乱序）。
- 加密：HTTP/1.1 可选；HTTP/2 规范上可选，但浏览器实际只在 HTTPS 上启用；HTTP/3 内置 TLS 1.3，强制加密。
- 连接迁移：只有 HTTP/3（QUIC 用 Connection ID）支持——切 Wi-Fi/4G 不断连。
- 过时甚至有害的旧优化：域名分片（破坏单连接多路复用、徒增 DNS/握手）、雪碧图/文件合并（破坏细粒度缓存）、资源内联（无法独立缓存）——HTTP/2+ 下应移除。
- 现代最佳实践：细粒度拆包（让小改动只失效小块缓存）、信任浏览器多路复用、合理用
preload/preconnect，少用已废弃的 Server Push。 - 查站点版本：Chrome DevTools → Network → 右键表头勾选 Protocol 列（
h2/h3/http/1.1）；命令行curl --http2 -I/curl --http3 -I；或用nghttp -nv。 - 升级前提与收益：HTTP/2 实际要求 HTTPS；HTTP/3 要求 QUIC/UDP（443）可达。HTTPS + HTTP/2 是基线，HTTP/3 通常由 CDN/服务器一键开启。
- 浏览器支持：HTTP/2 全球 ~96%、HTTP/3 ~92%（caniuse 2026-06），主流浏览器全覆盖。
一、三版本全维度对比
各版本的机制细节见前面各页，这里做收口式横向对比：
| 维度 | HTTP/1.1 | HTTP/2 | HTTP/3 |
|---|---|---|---|
| 传输层 | TCP | TCP | QUIC（UDP） |
| 报文格式 | 文本 | 二进制分帧 | 二进制分帧 |
| 多路复用 | ❌ 单连接串行 | ✅ 单连接多路复用 | ✅ 单连接多路复用 |
| 队头阻塞 | 应用层（响应排队） | 应用层消除，TCP 层仍有 | 彻底消除（流独立） |
| 每源连接数 | 浏览器开 ~6 条 | 1 条即可 | 1 条即可 |
| 头部压缩 | ❌ 无（明文） | HPACK | QPACK |
| 加密 | 可选 | 规范可选，浏览器实际要 HTTPS | 内置 TLS 1.3，强制 |
| 连接建立往返 | TCP(1 RTT) + TLS(1~2 RTT) | TCP + TLS（同左） | QUIC 1 RTT，重连 0-RTT |
| 连接迁移 | ❌ | ❌ | ✅（Connection ID） |
| 服务器推送 | ❌ | 曾有（多数浏览器已弃用） | ❌ |
一句话记忆
HTTP/2 解决「一条连接能并行」，但被 TCP 拖累；HTTP/3 换底座（QUIC/UDP）把 TCP 层队头阻塞也一并解决，并支持网络切换不断连。
二、哪些 HTTP/1.1 时代的前端优化已过时甚至有害
这些技巧的初衷都是绕开 HTTP/1.1 的「单连接串行 + 每源限并发 + 每请求开销大」。一旦升级到 HTTP/2/3，前提消失，技巧反成负担。
1. 域名分片（Domain Sharding）—— 直接有害
把静态资源拆到 static1.cdn.com、static2.cdn.com… 多个子域，是为了突破浏览器「每源 ~6 条并发」的限制。但在 HTTP/2 下，所有资源走同一连接的多路复用本就高效：
- 多个域名 = 多条独立 TCP/QUIC 连接，各自重走 DNS 解析 + TCP/TLS 握手，徒增延迟；
- 拆散连接破坏了 HTTP/2 单连接的多路复用与统一优先级调度，反而更慢；
- 连接越多，TCP 慢启动的「热身」收益越分散。
WARNING
域名分片在 HTTP/2+ 下是典型反模式：把本可复用的一条连接人为拆成多条，丢掉多路复用红利。升级后应收敛回单一来源。
2. 雪碧图与文件合并（Spriting / Concatenation）—— 破坏缓存粒度
把多张小图拼成一张雪碧图、把多个 JS/CSS 打成一个大 bundle，是为了减少请求数（HTTP/1.1 每个请求开销大）。HTTP/2+ 下请求变得「廉价」，这套反而有害：
- 合并后任意一处小改动都会让整个大文件的缓存失效，用户被迫重新下载全部；
- 雪碧图里只用到一张小图，也得加载整张大图，浪费带宽；
- 大 bundle 阻碍按需/并行加载与浏览器的细粒度调度。
3. 资源内联（Inlining，data URI / 内联 CSS-JS）—— 无法独立缓存
把图片转成 data: URI、或把 CSS/JS 直接写进 HTML，是为了省掉一次请求往返。代价是：
- 内联的资源无法被独立缓存，每次 HTML 变化都要连同它一起重传；
- 同一资源在多个页面内联 = 重复传输，无法跨页复用缓存；
- HTML 体积膨胀，拖慢首字节后的解析。
例外
极少量、首屏关键且几乎不变的内容（如关键 CSS 的 critical 部分）仍可酌情内联以优化首屏渲染——这是权衡而非默认，且范围要小。
三、HTTP/2+ 下的现代最佳实践
细粒度拆包：按路由/特性拆分 chunk，让「改一处只失效一块」，最大化长期缓存命中（配合内容哈希文件名 +
immutable）。信任浏览器多路复用：同源资源放一条连接并行下载即可，不要再手动分片或盲目合并。
preconnect提前建连：对跨源关键来源（字体、关键 API、CDN）提前完成 DNS+TCP+TLS。html<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin />preload提前拉取：对当前页确定会用、但发现得晚的关键资源（字体、首屏大图、关键脚本）提前下载，但别滥用（会和关键资源抢带宽）。html<link rel="preload" href="/fonts/inter.woff2" as="font" type="font/woff2" crossorigin />慎用 Server Push：HTTP/2 服务器推送实际收益有限且易过推，主流浏览器（Chrome 等）已弃用；优先用
preload/103 Early Hints替代。
拆包粒度的平衡
「细粒度」不等于「碎到几百个文件」——过多小文件仍有每请求的轻微开销与优先级管理成本。目标是按变更频率分层（稳定的第三方库一块、业务代码一块、按路由再拆），而非无脑拆到最细。
四、如何检测站点实际用的 HTTP 版本
Chrome DevTools
打开 Network 面板 → 在请求列表表头右键 → 勾选 Protocol 列，即可看到每个请求实际协商的协议：
http/1.1—— HTTP/1.1h2—— HTTP/2h3—— HTTP/3（QUIC）
命令行 curl
# 强制以 HTTP/2 请求，只看响应头（-I）
curl --http2 -I https://example.com
# 输出首行类似：HTTP/2 200
# 尝试 HTTP/3（需 curl 编译时带 QUIC 支持）
curl --http3 -I https://example.com
# 输出首行类似：HTTP/3 200nghttp / 在线工具
# nghttp2 工具集，-n 丢弃响应体，-v 打印详细协商过程
nghttp -nv https://example.com也可用在线服务（如 HTTP/3 Check 类站点）快速判断某域名是否已开启 HTTP/3。
五、升级前提与务实建议
两个硬前提
- HTTP/2：规范虽未强制 TLS，但浏览器只在 HTTPS 上启用 HTTP/2——没有 HTTPS 就别谈 HTTP/2。
- HTTP/3：要求客户端到服务器的 UDP 443 可达（QUIC 跑在 UDP 上），部分企业防火墙会拦 UDP 导致回退。HTTP/3 通常通过响应头
Alt-Svc向浏览器宣告升级，首次请求仍可能走 HTTP/2。
务实路线：
- 基线：开启 HTTPS + HTTP/2——这是当下所有站点的默认起点，收益（多路复用 + 头部压缩）几乎零业务改造成本。
- 进阶：HTTP/3 交给 CDN / 反向代理一键开启（Cloudflare、Nginx/quiche、Caddy 等），前端基本无感，弱网与移动场景收益明显。
- 升级后必做：回收 HTTP/1.1 时代的旧优化——撤掉域名分片、放宽过度合并、减少内联，改走细粒度拆包，才能真正吃到新协议的红利。
小结
本叶从演进史出发，逐层拆解了 HTTP/1.1 的队头阻塞瓶颈、HTTP/2 的二进制分帧与多路复用、HPACK 头部压缩，到 HTTP/3 用 QUIC 根治 TCP 层队头阻塞与支持连接迁移。落到前端实践，核心结论是：协议进步会让旧优化反转为负担——域名分片破坏单连接多路复用、雪碧图与文件合并破坏缓存粒度、资源内联无法独立缓存，在 HTTP/2+ 下都应移除，转向细粒度拆包 + 信任多路复用 + 合理 preload/preconnect。工程上以 HTTPS + HTTP/2 为基线，HTTP/3 由 CDN/服务器开启，并用 DevTools 的 Protocol 列或 curl --http2/--http3 -I 验证落地效果。
上一页：HTTP/3 与 QUIC。本叶各机制的逐条权威出处与 RFC 索引见 参考。