入门
基于 HTTP 现代标准 · 核于 2026-06
速查
- 三代演进只换传输方式、不改语义：HTTP/1.1（文本、TCP）→ HTTP/2（二进制分帧、TCP）→ HTTP/3（QUIC over UDP）
- 一条主线 = 消灭队头阻塞：1.1 应用层 HOL → 2 消除应用层 HOL 但残留 TCP 层 HOL → 3 用 QUIC 降到单流
- HTTP/1.1 瓶颈：响应必须串行（管线化失败）、每域 ~6 连接上限、头部明文重发；前端被迫域名分片 / 雪碧图 / 合并 / 内联
- HTTP/2 解法：二进制分帧（帧 / 消息 / 流）+ 单连接多路复用 + HPACK 头部压缩；服务器推送已废弃
- HTTP/2 残留痛点：所有流挤一条 TCP，一个丢包连坐全部流（TCP 层队头阻塞）
- HTTP/3 = HTTP over QUIC（UDP）：每流独立重传根治队头阻塞、内置 TLS 1.3、0-RTT、连接迁移（切网不断连）
- 头部压缩：HTTP/2 用 HPACK、HTTP/3 用 QPACK（适配 QUIC 乱序到达）；不用 gzip 是为防 CRIME/BREACH 侧信道攻击
- 版本协商：ALPN（TLS 握手内一次选定
h2/http/1.1）、Alt-Svc: h3宣告并异步升级到 HTTP/3 - 支持现状（caniuse 2026-06）：HTTP/2 ~96%、HTTP/3 ~92%，主流浏览器与 CDN 默认开启
- ⚠️ HTTP/2+ 下旧优化过时甚至有害：域名分片破坏单连接多路复用、雪碧图 / 合并破坏缓存粒度
- 检测版本：DevTools → Network → Protocol 列（
h2/h3）或curl --http2 -I/curl --http3 -I - 升级前提：HTTP/2 实际要求 HTTPS、HTTP/3 要求 UDP 443 可达
一条主线：和「队头阻塞」搏斗
HTTP 的演进史，本质是一部和**队头阻塞（Head-of-Line Blocking）**搏斗的历史。抓住这条主线，三个版本的来龙去脉就串起来了：
- HTTP/1.1——一条 TCP 连接上请求必须排队：前一个响应没回来，后面的就得等。这是应用层队头阻塞。前端只能用「多开连接 + 把资源拼大」绕开。
- HTTP/2——单连接上引入多路复用，多个请求并发交错，应用层队头阻塞消失了。但所有流仍跑在同一条 TCP 上，TCP 一旦丢包就卡住所有流——队头阻塞下沉到了 TCP 层。
- HTTP/3——干脆抛弃 TCP，改用基于 UDP 的 QUIC，让每个流独立重传，丢包只影响那一个流——队头阻塞被降到单个流粒度，基本根治。
三代速览
| 版本 | 年份 | 传输层 | 关键变化 | 队头阻塞 |
|---|---|---|---|---|
| HTTP/0.9 | 1991 | TCP | 单行 GET，只传 HTML | — |
| HTTP/1.0 | 1996 | TCP | 头部、状态码、Content-Type | 每请求新建连接 |
| HTTP/1.1 | 1997 | TCP | 持久连接、Host、分块、缓存 | 应用层 |
| HTTP/2 | 2015 | TCP | 二进制分帧、多路复用、HPACK | 应用层消除、TCP 层残留 |
| HTTP/3 | 2022 | QUIC(UDP) | 流级独立重传、0-RTT、连接迁移 | 降到单流 |
语义为什么能「无感切换」
不管底层是文本还是二进制、跑在 TCP 还是 QUIC 上，GET /api、200 OK、Content-Type: application/json 的含义始终一致。HTTP 在 RFC 9110 里把语义（方法 / 状态码 / 首部）和线格式（每个版本各自的字节编码）彻底分离，所以升级版本对应用代码几乎透明。
怎么看自己用的是哪个版本
打开浏览器 DevTools → Network，右键表头勾出 Protocol 列，就能看到每个请求走的是 http/1.1、h2 还是 h3；命令行则用 curl --http2 -I https://example.com 或 curl --http3 -I ...。注意：访问一个站点时，首个请求常常先走 h2，浏览器看到响应里的 Alt-Svc: h3 后，后续请求才异步升级到 h3。
接下来各页逐一展开：先看完整的版本演进史，再深入每一代的瓶颈与解法。