HTTP 1.0 到 HTTP 3 的演进

zhangyuguai2026/3/16大约 23 分钟约 6969 字

一、为什么要学习 HTTP 的演进

HTTP 是 Web 世界最核心的应用层协议之一。我们平时在浏览器里访问网页、调用后端接口、加载图片和视频，本质上都在使用 HTTP。

如果只记住「HTTP 是请求响应协议」这句话，其实远远不够。面试里更常见的问题是：

为什么 HTTP/1.1 比 HTTP/1.0 快？
为什么已经有了 HTTP/2，还要继续搞 HTTP/3？
HTTP/2 已经支持多路复用了，为什么还是没有彻底解决队头阻塞？
QUIC 和 TCP 到底是什么关系？

要回答这些问题，核心不是死记协议特性，而是抓住一条主线：

每一代 HTTP，几乎都是在解决上一代暴露出来的性能瓶颈、连接开销和传输延迟问题。

所以这篇文章不只会罗列版本差异，而是会按「问题出现 -> 方案演进 -> 新问题继续暴露」的方式，把 HTTP/1.0 到 HTTP/3 的迭代过程串起来。

二、先建立整体认识

1. HTTP 的本质

HTTP，HyperText Transfer Protocol，超文本传输协议。最开始它主要是为网页文本传输设计的，后来逐渐演化成一个通用的应用层协议，既可以传 HTML，也可以传 JSON、图片、视频、文件等各种资源。

HTTP 的核心特点有两个：

请求-响应模型：客户端发起请求，服务端返回响应
无状态：协议本身不记录两次请求之间的上下文，需要靠 Cookie、Session、Token 等机制补充状态

2. HTTP 运行在哪一层

HTTP 位于应用层，通常依赖下面的传输层协议：

HTTP/1.0、HTTP/1.1、HTTP/2：通常基于 TCP
HTTP/3：基于 QUIC，而 QUIC 底层使用 UDP

也就是说，HTTP 的版本升级，不只是应用层报文格式在变化，很多时候还会牵扯到下面传输层能力的变化。

3. 理解版本演进的观察维度

后面看每个版本时，可以重点关注下面几个维度：

连接是否复用：一次请求要不要重新建连接
并发能力如何：多个请求能不能同时走
是否存在队头阻塞：前面的请求卡住会不会拖慢后面的请求
头部开销大不大：重复请求头会不会浪费带宽
安全能力如何：是否天然适配加密
弱网表现如何：丢包、抖动、切网时表现怎么样

三、HTTP/1.0：能用，但非常“原始”

1. 背景

HTTP/1.0 诞生于 Web 早期阶段。那时候网页很简单，一个页面可能主要就是一段 HTML 文本，外加很少量的图片资源。协议设计目标偏向于「先把内容传过去」，并没有强烈考虑今天这种复杂页面加载场景。

你可以把 HTTP/1.0 理解成：适合简单文档传输，但不适合现代 Web 的资源密集型场景。

2. 核心特点

短连接

HTTP/1.0 默认使用短连接。也就是说：

客户端和服务端建立一个 TCP 连接
发一个 HTTP 请求
收到响应
TCP 连接关闭

如果一个网页包含：

1 个 HTML
3 个 CSS
5 个 JS
20 张图片

那浏览器理论上就要建立很多次 TCP 连接。每个资源都可能经历一次完整的建连、传输、断连过程。

这在今天看来开销非常大，因为 TCP 建连本身就需要三次握手，关闭还要四次挥手，频繁重复意味着：

延迟高
服务器连接管理成本高
网络利用率低

请求与响应格式是文本

HTTP/1.0 的报文是纯文本格式，可读性很好，调试方便。例如：

GET /index.html HTTP/1.0
Host: example.com

服务端返回：

HTTP/1.0 200 OK
Content-Type: text/html
Content-Length: 1024

<html>...</html>

这套文本协议一直延续到了 HTTP/1.1。它的好处是简单直观，缺点是表达效率不算高。

对 Host 的支持不完善

HTTP/1.0 时期，Host 头并不是强制要求。这个问题在早期服务器数量少时还不明显，但后来虚拟主机越来越普遍，一个 IP 需要承载多个站点，服务端就必须知道客户端到底要访问哪个域名，这也推动了 HTTP/1.1 的标准化完善。

3. HTTP/1.0 的主要问题

HTTP/1.0 最大的问题可以概括成一句话：

每请求一个资源都重新建连接，代价太大。

在早期静态网页场景下，这个问题还不算致命；但随着网页资源越来越多，性能问题就迅速暴露：

页面加载很慢
TCP 连接反复创建和销毁
服务端压力增加
网络拥塞控制和慢启动收益无法复用

这里再补一个很重要的点：

TCP 刚建立连接时会进入慢启动阶段，拥塞窗口较小。如果每次请求都重新建连接，那么 TCP 很难进入稳定高效的传输状态。这意味着 HTTP/1.0 不只是「握手慢」，还会让 TCP 的传输效率一直起不来。

4. HTTP/1.0 小结

维度	HTTP/1.0
连接模型	默认短连接
并发能力	很弱
头部格式	文本
资源加载效率	低
主要问题	每次请求都要新建 TCP 连接

5. 它给下一代留下的任务

HTTP/1.0 把最核心的问题暴露得非常明确：

能不能别每次都断开连接？
能不能让多个资源复用同一个连接？
能不能让 Web 页面加载得更快一点？

于是 HTTP/1.1 出场。

四、HTTP/1.1：真正走向实用化的版本

HTTP/1.1 是 Web 历史上非常重要的一代。严格来说，直到今天，大量系统内部调用、老项目接口、代理转发链路中仍然在广泛使用 HTTP/1.1。

1. 核心改进一：长连接

HTTP/1.1 默认启用持久连接，也就是我们常说的 Keep-Alive。

这意味着：

一个 TCP 连接建立后，不必立刻关闭
同一个客户端后续多个请求可以复用这条连接
减少了频繁握手和挥手的开销

比如浏览器第一次请求首页时建立 TCP 连接，后续再请求 CSS、JS、图片时，可以尽量复用已经建立好的连接，而不是每次重新来一遍。

这带来的收益非常直接：

减少 TCP 建连成本
降低延迟
减少服务端连接管理开销
让 TCP 拥塞窗口可以持续利用，提升吞吐

这是 HTTP/1.1 相比 1.0 最关键的升级。

2. 核心改进二：Host 头成为必须

HTTP/1.1 中，Host 头变成必需字段。例如：

GET /api/user HTTP/1.1
Host: www.example.com

这样服务端即使在同一个 IP 上部署多个网站，也能根据 Host 识别用户究竟访问的是哪个站点。

这推动了虚拟主机技术的大规模使用，是现代 Web 托管体系的重要基础。

3. 核心改进三：更多缓存与传输控制能力

HTTP/1.1 对缓存和内容传输能力也做了大量增强，例如：

Cache-Control
ETag
If-Modified-Since
If-None-Match
Range
Transfer-Encoding: chunked

这些机制很重要，因为它们直接影响网页性能和资源传输体验。

缓存能力增强

浏览器不必每次都重新下载全部资源，可以和服务端协商：

资源是否过期
文件是否有变化
没变化就直接用缓存

这显著减少了重复请求带来的带宽消耗。

分块传输

chunked 传输允许服务端在不知道完整内容长度时，边生成边返回数据。比如服务端动态渲染页面或流式输出内容时，就不必等全部内容准备完再一次性发送。

4. 核心改进四：管线化机制提出，但没有真正普及

HTTP/1.1 提出了 Pipelining（管线化）。它的思路是：

在一个 TCP 连接上
客户端可以连续发送多个请求
不必等待前一个响应回来再发下一个

听起来很好，但现实里它并没有广泛落地，原因是它有一个大问题：

服务端返回响应时，仍然必须按照请求顺序依次返回。

也就是说，如果前面的响应处理很慢，后面的响应即使已经准备好了，也不能先发。这就导致了应用层队头阻塞。

举个例子：

客户端依次发送请求 A、B、C
服务端收到后开始处理
如果 A 很慢，那么 B、C 即使很快完成，也必须排在 A 后面返回

最终效果就是：理论上减少了等待，但实际仍然容易被前面的慢请求拖住。

5. HTTP/1.1 的核心瓶颈

HTTP/1.1 虽然已经比 1.0 好很多，但它仍然有明显问题。

问题一：同一连接上请求基本仍然串行

即使有 Keep-Alive，单条连接上的请求处理仍然很受限制。很多场景下，浏览器为了提高并发度，只能针对同一域名开启多条 TCP 连接。

这就形成了一种很经典的现象：

一个域名通常会开 6 条左右 TCP 连接
靠多开连接提升并发加载速度

但这本质上是一种“绕过协议限制”的工程化补丁，不是真正优雅的协议能力。

问题二：队头阻塞

HTTP/1.1 的队头阻塞主要体现在应用层：

一个请求阻塞，会拖慢同连接中后续请求
即使是管线化，也无法真正乱序返回

问题三：头部重复发送

现代网页请求很多，而每个请求都要携带一堆重复头部，比如：

Cookie
User-Agent
Accept
Authorization

这些字段经常重复出现，体积还不小。HTTP/1.1 对头部没有专门压缩机制，请求一多，浪费很明显。

问题四：文本协议解析效率有限

文本协议的优点是直观，缺点是：

解析成本高于二进制协议
结构表达不够紧凑
不利于高性能实现

6. HTTP/1.1 小结

维度	HTTP/1.1
连接模型	默认长连接
并发能力	依赖多 TCP 连接并发
队头阻塞	有，主要是应用层
头部压缩	无
报文格式	文本
主要贡献	让 HTTP 真正适合现代 Web 初期发展

7. 它给下一代留下的任务

HTTP/1.1 已经证明了一件事：

真正的问题不只是“要不要复用连接”，而是“复用以后，如何高效并发传输多个请求”。

于是 HTTP/2 的目标就非常明确了：

在一条连接上真正并发
降低头部开销
提高传输效率

五、HTTP/2：从文本协议走向二进制多路复用

HTTP/2 的设计目标非常鲜明：不改变 HTTP 的语义，但重写传输方式。

也就是说：

请求方法还是 GET、POST
状态码还是 200、404
头部语义还是那些头部

但底层传输组织形式彻底变了。

1. 核心改进一：二进制分帧

HTTP/2 不再直接传输原始文本报文，而是把数据拆分成更小的帧（Frame），然后在连接中传输。

常见帧类型包括：

HEADERS
DATA
SETTINGS
WINDOW_UPDATE
PING

这样做的意义在于：

更适合机器解析
结构化程度更高
为多路复用打基础

你可以把 HTTP/1.1 想成一条公路上整车运输；HTTP/2 更像是先把货拆成标准化集装箱，再统一调度运输。

2. 核心改进二：多路复用

这几乎是 HTTP/2 最重要的特性。

HTTP/2 在一条 TCP 连接上引入了流（Stream）的概念：

一个请求/响应对对应一个流
一个流可以被拆成多个帧
多个流的帧可以交错发送

例如：

连接里传输的帧顺序可能是：

流1的HEADERS
流3的HEADERS
流1的DATA
流5的HEADERS
流3的DATA
流1的DATA
流5的DATA

也就是说，多个请求不再必须像 HTTP/1.1 那样近似串行排队，而是可以在同一条连接里并发推进。

这直接带来了几个收益：

减少浏览器为并发而建立多条 TCP 连接的必要
更充分利用单连接带宽
页面资源加载效率明显提升

3. 核心改进三：头部压缩

HTTP/2 引入了 HPACK 头部压缩机制，用来解决 HTTP/1.1 中重复头部过多的问题。

它的核心思路包括：

对常见头字段建立静态表
对历史出现过的头字段建立动态表
重复内容不再原样发送，而是发送索引或增量信息

例如很多请求都带着同样的 Cookie、User-Agent、Accept 头，那么后续请求就不必每次完整传一遍。

这对移动网络和大量小请求场景特别有帮助。

4. 核心改进四：服务端推送

HTTP/2 提供了 Server Push 能力。服务端可以在客户端还没明确请求前，主动把可能需要的资源推过去。

比如客户端刚请求首页 HTML，服务端觉得你马上大概率会需要对应的 CSS 和 JS，就可以提前推送。

这个思路很超前，但落地效果并不理想，原因包括：

浏览器缓存命中时，推送可能变成浪费
服务端不一定真的知道客户端需要什么
实践中调优复杂

所以 Server Push 后来并没有成为主流能力，在 HTTP/3 时代也基本被边缘化。

5. HTTP/2 解决了什么

相对于 HTTP/1.1，HTTP/2 主要解决了这些问题：

解决了连接级别的并发低效问题

一条 TCP 连接上就能支持多个请求并发传输，不必再大量依赖多连接并行。

解决了头部重复过大的问题

HPACK 明显减少了重复头部带来的浪费。

提升了解析效率

二进制分帧比文本协议更适合高性能实现。

6. HTTP/2 没有彻底解决什么

这是面试里最容易被追问的点。

HTTP/2 虽然支持多路复用，但它仍然跑在 TCP 上。而 TCP 有一个关键特性：

TCP 要保证字节流按序交付。

这意味着，如果某个 TCP 报文段丢失了，即使后面的报文段已经到了，接收方在 TCP 层也必须先等丢失的那一段重传成功，后面的数据才能继续交给上层。

这就导致 HTTP/2 仍然存在传输层队头阻塞。

注意这里要区分两种队头阻塞：

HTTP/1.1：更多是应用层请求排队导致的队头阻塞
HTTP/2：应用层多路复用缓解了排队问题，但 TCP 层丢包仍会让所有流一起卡住

这也是为什么很多人会说：

HTTP/2 解决了“同连接内请求不能并发”的问题，但没有解决“TCP 丢包导致整条连接受阻”的问题。

7. 一个直观例子

假设一个 TCP 连接里同时承载三个流：

流 1：HTML
流 3：CSS
流 5：图片

如果图片对应的某些 TCP 数据段丢了，那么从 TCP 视角看，这条连接的字节流顺序被打断了。即使 HTML 和 CSS 后面的数据其实已经到达，TCP 仍然可能暂时不把后续字节交给 HTTP/2 层处理。

于是结果就变成：

多个流逻辑上是独立的
但在 TCP 字节流层面仍然被绑在一起

这就是 HTTP/2 的“天花板”。

8. HTTP/2 小结

维度	HTTP/2
连接模型	单连接复用能力强
并发能力	强，多路复用
报文格式	二进制分帧
头部压缩	有，HPACK
队头阻塞	TCP 层仍存在
主要贡献	让 HTTP 真正进入高并发高效率时代

9. 它给下一代留下的任务

HTTP/2 已经把应用层能做的事情做得差不多了，接下来剩下的问题非常集中：

TCP 丢包导致整条连接受影响
TCP + TLS 的握手成本还能不能更低
移动网络切换场景下，连接能不能更平滑迁移

于是 HTTP/3 不再只改应用层，而是直接改传输通道。

六、HTTP/3：把底层传输从 TCP 换成 QUIC

HTTP/3 最大的变化，不是头部字段，不是方法名，不是状态码，而是：

它不再基于 TCP，而是基于 QUIC。

这是理解 HTTP/3 的关键。

1. 为什么 HTTP/3 必须“绕开” TCP

前面已经看到，HTTP/2 的主要问题不是 HTTP 语义，而是 TCP 的按序交付机制 会在丢包时拖住整条连接。

如果还继续基于 TCP 做优化，空间已经不大了。因为：

TCP 在内核里实现，升级和迭代成本高
HTTP 层很难改变 TCP 的可靠传输逻辑
多路复用做得再好，仍然会被 TCP 的连接级阻塞拖累

所以 HTTP/3 选择的路线是：

使用 UDP 作为基础传输载体
在用户态之上实现 QUIC
再把 HTTP 语义跑在 QUIC 上

2. QUIC 是什么

QUIC 可以理解成：

一个在 UDP 之上实现的、具备类似 TCP 可靠传输能力，并且原生支持多路复用、加密和更快握手的新型传输协议。

虽然它底层用的是 UDP，但它并不是“裸 UDP 直接发 HTTP”，而是在 UDP 之上补齐了很多传输能力，例如：

可靠传输
丢包重传
拥塞控制
流量控制
多路复用
连接迁移
TLS 1.3 级别的安全握手

也就是说，QUIC 本质上是在“重造一个更适合现代网络环境的传输层”。

3. HTTP/3 的核心改进一：真正意义上的多路复用

HTTP/3 也有流的概念，但这些流是建立在 QUIC 上的。QUIC 的流之间是相对独立的：

一个流丢包了，主要影响这个流自己
不会像 TCP 那样让整条连接上的所有流一起等待按序恢复

因此，HTTP/3 解决的是传输层级别的队头阻塞问题。

这才是真正意义上把多路复用做透了。

4. HTTP/3 的核心改进二：更快的握手

传统 HTTPS 建立连接，一般要经历：

TCP 三次握手
TLS 握手
才能开始真正传输 HTTP 数据

这个过程在高延迟网络下代价很明显。

QUIC 把传输连接建立和安全握手更紧密地整合在一起，可以实现：

1-RTT 建连
在某些场景下实现 0-RTT 恢复连接

这意味着客户端在再次访问同一个服务端时，能更快开始发送应用数据。

这里补充一个常见面试点：

RTT 是 Round Trip Time，往返时延
1-RTT 表示一个往返后建立好
0-RTT 表示某些恢复场景下，几乎可以立刻发送应用数据

当然，0-RTT 也有重放攻击等安全语义上的限制，不能简单理解成所有请求都无脑更快。

5. HTTP/3 的核心改进三：连接迁移

TCP 连接的四元组通常和源 IP、源端口、目标 IP、目标端口绑定很紧。一旦网络环境变化，比如手机从 Wi-Fi 切到 4G，TCP 连接往往就断了，需要重新建立。

QUIC 使用连接 ID 来标识连接，这使得它在网络切换时更灵活：

客户端 IP 变了
网络切换了
只要连接上下文还在，连接可以更平滑地迁移

这个能力对移动互联网尤其重要。

6. HTTP/3 的核心改进四：默认更强的安全整合

HTTP/3 与 QUIC 的设计中，加密几乎是“原生内建”的。它并不像早期 HTTP 那样把安全视为外挂能力，而是直接和传输层握手流程深度结合。

这让：

加密默认化
握手流程更紧凑
协议设计更适合现代互联网安全需求

7. HTTP/3 的代价与挑战

HTTP/3 并不是只有优点，它也带来了新的复杂性。

实现复杂度更高

以前很多可靠传输能力由操作系统内核里的 TCP 实现。现在 QUIC 许多逻辑在用户态完成，实现和调优都更复杂。

中间设备兼容性问题

网络里很多设备长期都是围绕 TCP 设计和优化的。新协议落地时，需要处理：

防火墙策略
NAT 行为
代理与抓包工具支持
运维监控体系适配

CPU 与加密开销

更复杂的加密与用户态协议栈，也可能带来额外 CPU 压力，需要工程上做平衡。

8. HTTP/3 小结

维度	HTTP/3
传输基础	QUIC over UDP
并发能力	强，多流独立
队头阻塞	避免了 TCP 级别的连接整体阻塞
握手时延	更低，可支持 1-RTT / 0-RTT
连接迁移	支持更好
安全能力	与加密深度整合
主要贡献	从传输层角度彻底优化现代 Web 体验

七、从 HTTP/1.0 到 HTTP/3，到底升级了什么

如果把整个演进过程压缩成一条主线，其实就是下面这张表。

版本	主要改进	解决了什么	仍然存在的问题
HTTP/1.0	确立请求-响应模型	让 Web 能工作	短连接开销巨大
HTTP/1.1	长连接、缓存增强、Host、chunked	减少重复建连，实用性大增	应用层队头阻塞、头部冗余、并发效率一般
HTTP/2	二进制分帧、多路复用、头部压缩	提升并发和带宽利用率	仍受 TCP 队头阻塞影响
HTTP/3	基于 QUIC，改造传输层	解决 TCP 层队头阻塞，降低握手时延	协议和工程复杂度更高