把 HTTP 的演化摊开看，核心驱动只有一条：让连接更省、传输更快、协议更可控。HTTP/1.0 立起”一次一连”的范式，HTTP/1.1 用持久连接与流水线打破这个范式，HTTP/2 用二进制分帧实现真正的多路复用，HTTP/3 则彻底脱离 TCP，把传输交给基于 UDP 的 QUIC。每一代都把上一代无法解决的最痛的那一两个瓶颈作为发力点。
一、四个版本的关键节点
四个版本最常被引用的标准化节点如下，时间和 RFC 编号都能在 IETF 公开文档里交叉验证。
| 版本 | 标准节点 | 核心规范 | 关键变化 |
|---|---|---|---|
| HTTP/0.9 | 1991（未正式 RFC） | 仅 GET 一行命令 | 无头、无状态码、只回 HTML、连接即断 |
| HTTP/1.0 | 1996.5 | RFC 1945 | 引入请求/响应头、状态码、Content-Type、POST/HEAD |
| HTTP/1.1 | 1997.1 / 1999.6 / 2014 / 2022 | RFC 2068 / 2616 / 7230-7235 / 9110-9112 | 持久连接、强制 Host 头、分块传输、缓存与条件请求、内容协商 |
| HTTP/2 | 2015.5 / 2022.6 | RFC 7540 / 9113 | 二进制分帧、多路复用、HPACK 头压缩、Server Push、流优先级 |
| HTTP/3 | 2022.6 | RFC 9114（基于 RFC 9000 QUIC） | 改用 QUIC over UDP，0-RTT、连接迁移、消除队头阻塞 |
读这张表能马上看出节奏：1996 到 2022 共 26 年里，HTTP 只在 2015 年与 2022 年完成两次”代际跳跃”，其余时间都在补语义和拆分文档。语义与线协议分离，是 RFC 9110 时代最重要的结构变化：9110 定语义，9111 定缓存，9112/9113/9114 分别承载三个版本的消息语法。
二、HTTP/1.0：把超文本变成通用协议
HTTP/0.9 只能 GET /index.html 拿 HTML 一个动作，遇到图片、CSS、错误页都无能为力。HTTP/1.0 把这件事补齐：
- 引入请求头与响应头，把元数据从正文里抽出来；
- 定义三位数状态码，404、500、200 一类开始承担语义反馈；
- 通过 Content-Type 把任意 MIME 类型都纳入可传输范围；
- 新增 POST、HEAD 等方法，命令集合从 1 个扩到多个。
但 HTTP/1.0 仍有一个硬伤：每个请求都开一条新的 TCP 连接，完成即关闭。一张含 20 张图的网页意味着 20 次握手与慢启动，握手延迟在小文件场景下能占到总时延的八成以上。
三、HTTP/1.1：在 TCP 之上做”省”
HTTP/1.1 没有改传输层，但把请求模型重做了一遍：
- 持久连接（keep-alive）：默认开启，TCP 连接可承载多次请求，握手成本摊薄；
- 强制 Host 头：让一台物理主机可以托管多个域名，是虚拟主机的根基；
- 分块传输编码（chunked）：响应长度未知时也能流式返回；
- 条件请求与缓存控制：ETag、Last-Modified、If-None-Match、Cache-Control 一起把”重复请求”挡在带宽之外；
- Range 请求：支持断点续传与按范围取数；
- 流水线（pipelining）：理论上能在同一连接上不等响应就发下一请求，实践里被队头阻塞拖累，几乎没人真用。
HTTP/1.1 是工业界用得最久的版本，文本格式让抓包调试几乎零门槛，至今仍大量存在于后端服务内部、嵌入式设备与对兼容性敏感的网关里。RFC 2616 之后又有 2014 年的 RFC 7230-7235 与 2022 年的 RFC 9110/9112 两次小修，但语义骨架二十多年没变。
3.1 HTTP/1.1 的请求样例
GET /index.html HTTP/1.1
Host: www.example.com
Connection: keep-alive
Accept-Encoding: gzip, deflate
If-None-Match: "5d8c72a5edda3"响应到达后，连接不会立刻断，下一个请求可以复用。这一行 Connection: keep-alive 在 HTTP/1.1 里已是默认行为，写出来只是兼容老代理。
四、HTTP/2：把”多路复用”真正落地
HTTP/2 把 HTTP/1.1 时代浏览器”每域名开 6 个 TCP 连接绕开队头阻塞”的权宜之计做成协议层能力。设计要点有五条：
- 二进制分帧层：消息被切成带类型与流 ID 的二进制帧，而不是文本行；
- 多路复用：同一连接上同时跑多对请求/响应，单连接并发上限由帧数而非物理连接数决定；
- HPACK 头压缩：高频头（Host、User-Agent、Cookie）走静态表 + 动态表，体积比 HTTP/1.1 时代的整行重复文本小一个量级；
- 流优先级：客户端声明哪些资源更紧急，CSS 通常排在 JS 之前；
- Server Push：服务端可主动推送它猜客户端会用到的资源（Chrome 2022 年起移除，实际意义有限）。
最关键的是第 1、2 条：HTTP/1.1 上层再多并发，也救不了 TCP 层的”有序字节流”性质——一个包丢了，后续所有字节都阻塞。HTTP/2 把”队头阻塞”从应用层挪到传输层，掩盖了它但没消除它，这是后面 HTTP/3 解决的事情。
4.1 一个 HTTP/2 连接上的并发示意
TCP 连接 (单条)
├─ Stream 1: GET /index.html
├─ Stream 3: GET /app.css
├─ Stream 5: GET /app.js
└─ Stream 7: GET /logo.png
每条流独立编号、帧交错传输、互不阻塞五、HTTP/3：把传输层也换掉
HTTP/2 部署两三年后，工程界发现只要底层还是 TCP，应用层再多路复用也顶不住”一个丢包全队等”的现实。HTTP/3 干脆把 TCP+TLS 替换成 QUIC（基于 UDP），核心收益有四条：
- 真正的多路复用：QUIC 的每个流独立处理丢包，单流丢包不再卡其他流；
- 0-RTT 握手：首次连接 1-RTT 即可完成建链与密钥协商，回访 0-RTT 直接带数据；
- 连接迁移：连接不再绑定”源 IP+源端口+目的 IP+目的端口”四元组，改用连接 ID，Wi-Fi 切 5G 不掉线；
- 内置 TLS 1.3：加密是传输层默认行为，没有”明文 HTTP/3″这种形态。
QUIC 由 RFC 9000 定义，HTTP/3 自身的消息语法在 RFC 9114，HPACK 升级为 QPACK（RFC 9204）以解决动态表队头阻塞。
5.1 现实部署情况
把视角切到 2025 年的互联网：Cloudflare Radar 公布的 2025 年度回顾显示，发往 Cloudflare 的请求里 HTTP/2 占 50%、HTTP/1.x 占 29%、HTTP/3 占 21%，与 2024 年基本持平。全球已有 15 个国家或地区 HTTP/3 请求占比超过三分之一；大型社交平台在生产实践中公开了 QUIC/HTTP/3 的落地数据，请求错误率与尾延迟较 HTTP/2 均出现明显下降。Chrome、Firefox、Safari、Edge 主流浏览器均已默认开启 HTTP/3，访问不支持的站点时通过 Alt-Svc 自动回退到 HTTP/2，过程对用户透明。
六、各阶段相对前代的关键优化
| 阶段 | 相对前代最关键的优化 | 留下的新瓶颈 |
|---|---|---|
| HTTP/0.9 → HTTP/1.0 | 加头、加状态码、加方法、加 Content-Type | 一次一连接、握手成本极高 |
| HTTP/1.0 → HTTP/1.1 | 持久连接、强制 Host、分块、条件请求、Range | 文本解析慢、并发受限于浏览器多连接 |
| HTTP/1.1 → HTTP/2 | 二进制分帧、多路复用、HPACK、流优先级、Server Push | 队头阻塞从应用层下沉到 TCP 层 |
| HTTP/2 → HTTP/3 | QUIC 替代 TCP+TLS、0-RTT、连接迁移、内置加密 | 中间盒兼容、UDP 限流、移动网络抖动 |
这张表几乎可以当成面试里”为什么每一代都要换”的标准答案：每一代都把上一代最影响体验的那一项拆掉，然后留下一个能被下一代继续优化的新问题。
七、落地时的取舍
服务端、CDN、客户端这三段对协议版本的支持是错位的，部署时通常分三步走：
- 确认服务对外暴露的协议标识（ALPN 里 h2、h3 都协商过）；
- CDN 开启 HTTP/3 优先（Cloudflare、Akamai、Fastly 均已默认开启），同时保留 HTTP/2 兜底；
- 客户端代码里加 Alt-Svc 监听，便于浏览器后续升级握手版本。
# Nginx 启用 HTTP/3（QUIC）示例
listen 443 ssl;
http2 on;
add_header Alt-Svc 'h3=":443"; ma=86400';启用后可用 curl --http3-only -I https://example.com 验证是否走 QUIC。注意 0-RTT 会带来潜在重放风险，非幂等接口要结合 Early-Data 头做防御，不要让重放请求在业务侧造成副作用。
常见问题（FAQ）
Q1：HTTP/1.1 是不是已经过时了？
没有。HTTP/1.1 仍是后端服务内部、嵌入式设备、调试脚本的默认协议，云函数与内部 RPC 调用大量仍在用。
Q2：HTTP/2 为什么不直接用 UDP 而要等 HTTP/3？
HTTP/2 设计时浏览器生态普遍走 TCP，UDP 在中间盒、企业网络、操作系统内核层面兼容性差；QUIC 把 UDP 改造为可被广泛接受的安全传输，HTTP/3 才顺势切到 UDP。
Q3：升级到 HTTP/3 一定要换服务器软件吗？
多数主流 Web 服务器（Nginx、Caddy、Envoy、HAProxy）已支持 QUIC；Caddy 默认开启 HTTP/3，改动量最小。
