从 HTTP/0.9 到 HTTP/2.0：一文看懂协议演进与性能优化

在浏览器地址栏输入 https://juejin.cn 的一瞬间，一个复杂的网络通信过程就开始了。而这一切的背后，正是 HTTP 协议在默默支撑。

从最初的简单文本传输，到如今支持高并发、低延迟的现代网页加载，HTTP 经历了多个版本的迭代。每一次升级，都是为了解决前一版本的性能瓶颈。

本文将带你系统梳理 HTTP 协议从 0.9 到 2.0 的演进历程，深入理解每一次变革背后的动机与技术突破。

一、HTTP/0.9：最原始的"超文本传输协议"

特点：

✅ 仅支持 GET 请求方法
✅ 响应只返回纯 HTML 文本
❌ 没有请求头（Header）和响应头
❌ 不支持图片、CSS、JavaScript 等资源

工作方式：

http 复制代码

GET /index.html

服务器返回：

html 复制代码

<html>Hello World</html>

局限性：

只能传输静态 HTML 页面
无法传输图片、样式、脚本等现代网页必备资源
完全没有状态管理机制

💬 小结：HTTP/0.9 是"超文本"的起点，但离"现代网页"还很远。

二、HTTP/1.0：引入头部，支持多种数据类型

新增特性：

特性	说明
✅ 请求/响应头（Headers）	支持 `Content-Type`, `Content-Length` 等字段
✅ 多媒体支持	可传输图片、CSS、JS、JSON 等类型
✅ 状态码	如 `200 OK`, `404 Not Found`
✅ Cookie（后续补充）	实现会话跟踪，解决无状态问题

示例请求：

http 复制代码

GET /style.css HTTP/1.0
User-Agent: Chrome/128.0
Accept: text/css

响应：

http 复制代码

HTTP/1.0 200 OK
Content-Type: text/css
Content-Length: 1234

body { color: #333; }

但仍有严重性能问题：

❌ 每次请求都新建 TCP 连接

一个页面包含 HTML、CSS、JS、图片等资源
每个资源都要经历：DNS → TCP三次握手 → 发送请求 → 接收响应 → 断开连接
开销巨大，加载缓慢

📉 结果：同域名下多个资源只能"排队"加载，效率极低。

三、HTTP/1.1：持久连接与性能优化

为应对日益复杂的网页和用户增长，HTTP/1.1 带来了多项关键改进。

1. ✅ 持久连接（Persistent Connection）：`Connection: keep-alive`

多个请求复用同一个 TCP 连接
避免频繁建立/断开连接的开销
显著提升页面加载速度

http 复制代码

Connection: keep-alive

🚀 效果：HTML、CSS、JS、图片可在一个 TCP 链接上传输。

2. ✅ 管道化（Pipelining）

允许客户端连续发送多个请求，无需等待前一个响应
服务器必须按顺序返回响应

⚠️ 问题：队头阻塞（Head-of-Line Blocking）

如果第一个请求的资源响应慢，后面的响应即使准备好了也必须等待
依然无法实现真正的并发

3. ✅ 分块传输编码（Chunked Transfer Encoding）

服务器可以边生成数据边发送，无需预先知道内容长度
适用于动态内容（如流式响应、大文件传输）

http 复制代码

Transfer-Encoding: chunked

4. ✅ 其他改进

更丰富的状态码（如 304 Not Modified）
支持缓存控制（Cache-Control）
支持虚拟主机（Host 头字段）

小结：HTTP/1.1 是最广泛使用的版本之一，但它仍有瓶颈：

🔁 队头阻塞 + 单连接请求并发有限 → 仍需"曲线救国"

四、应对 HTTP/1.1 瓶颈的"黑科技"

由于 HTTP/1.1 无法真正并发，开发者们想出了各种" workaround"：

1. ⚡ 域名分片（Domain Sharding）

将资源分布在多个子域名下（如 static1.example.com, static2.example.com）
浏览器对每个域名有并发连接数限制（通常 6 个）
多个域名 = 更多并行 TCP 连接

❗ 缺点：增加 DNS 查询、TCP 握手开销，得不偿失（在 HTTP/2 下反而有害）

2. 🖼️ 资源内联（Inlining）

将小图片转为 Base64 内嵌到 CSS/HTML 中
减少请求数量

❗ 缺点：无法缓存，增大主文档体积

3. 🧩 雪碧图（CSS Sprites）

将多个小图标合并成一张大图，通过 CSS 定位显示
减少图片请求数

💬 这些方法虽然有效，但本质是"绕开协议缺陷"，不够优雅。

五、HTTP/2.0：真正的并发与性能飞跃

📅 年代：2015年，基于 Google SPDY 协议，RFC 7540

HTTP/2 的目标：解决 HTTP/1.1 的队头阻塞问题，实现高效、低延迟的通信。

1. ✅ 多路复用（Multiplexing）

一个 TCP 连接上可并发传输多个请求和响应
所有数据被拆分为 二进制帧（Frames）
每个帧带有 Stream ID 标识属于哪个请求

🚀 效果：请求和响应可以交错传输，互不阻塞！

text 复制代码

TCP 连接
├── Stream 1: 请求首页
├── Stream 2: 请求图片1
├── Stream 3: 请求脚本
└── 响应帧交错返回，无需排队

2. ✅ 二进制分帧层（Binary Framing Layer）

HTTP/1.x 是文本协议，解析慢且易出错
HTTP/2 使用二进制格式，解析更快、更高效

3. ✅ 头部压缩（HPACK）

请求头（如 Cookie、User-Agent）通常重复且冗长
使用 HPACK 算法压缩头部，减少传输体积

📉 效果：节省带宽，提升移动端体验

4. ✅ 服务器推送（Server Push）（已逐步弃用）

服务器可主动推送客户端可能需要的资源（如 CSS、JS）
减少往返延迟

⚠️ 注意：HTTP/3 中已建议弃用，由 103 Early Hints 替代

5. ✅ 请求优先级（Priority）

客户端可为资源设置优先级（如 HTML > CSS > 图片）
服务器据此调整传输顺序，优化渲染性能

六、HTTP/2 vs HTTP/1.1：核心对比

特性	HTTP/1.1	HTTP/2
连接模型	多个 TCP（或 keep-alive）	单个 TCP 多路复用
数据格式	文本	二进制帧
并发能力	有限（6-8 并发）	高并发（多流并行）
队头阻塞	存在（HOL Blocking）	解决（帧交错传输）
头部压缩	无	HPACK 压缩
性能优化手段	域名分片、雪碧图	不需要，反而有害

✅ 结论：HTTP/2 彻底解决了 HTTP/1.1 的性能瓶颈，是现代 Web 的基石。

七、总结：HTTP 协议演进图谱

版本	核心贡献	关键问题
HTTP/0.9	超文本传输起点	只能传 HTML
HTTP/1.0	引入 Header，支持多种类型	每次新建 TCP
HTTP/1.1	keep-alive、缓存、Host	队头阻塞
HTTP/2	多路复用、二进制帧、HPACK	仍基于 TCP，存在 TCP 层 HOL

从 HTTP/0.9 到 HTTP/2.0：一文看懂协议演进与性能优化

一、HTTP/0.9：最原始的"超文本传输协议"

特点：

工作方式：

局限性：

二、HTTP/1.0：引入头部，支持多种数据类型

新增特性：

但仍有严重性能问题：

❌ 每次请求都新建 TCP 连接

三、HTTP/1.1：持久连接与性能优化

1. ✅ 持久连接（Persistent Connection）：Connection: keep-alive

2. ✅ 管道化（Pipelining）

3. ✅ 分块传输编码（Chunked Transfer Encoding）

4. ✅ 其他改进

小结：HTTP/1.1 是最广泛使用的版本之一，但它仍有瓶颈：

四、应对 HTTP/1.1 瓶颈的"黑科技"

1. ⚡ 域名分片（Domain Sharding）

2. 🖼️ 资源内联（Inlining）

3. 🧩 雪碧图（CSS Sprites）

五、HTTP/2.0：真正的并发与性能飞跃

1. ✅ 多路复用（Multiplexing）

2. ✅ 二进制分帧层（Binary Framing Layer）

3. ✅ 头部压缩（HPACK）

4. ✅ 服务器推送（Server Push）（已逐步弃用）

5. ✅ 请求优先级（Priority）

六、HTTP/2 vs HTTP/1.1：核心对比

七、总结：HTTP 协议演进图谱

1. ✅ 持久连接（Persistent Connection）：`Connection: keep-alive`