🌺The Begin🌺点点关注，收藏不迷路🌺

🌺The End🌺点点关注，收藏不迷路🌺

01. 前言：为什么我们要对比 HTTP 1.0 和 2.0？

HTTP 协议是互联网的基石。从 HTTP 0.9 的纯文本传输，到 1.0 正式支持请求头/响应头，再到 1.1 引入持久连接，直到 HTTP 2.0 彻底重构二进制分帧与多路复用，每一次演进都为了解决性能瓶颈。

很多开发者对 1.0 和 2.0 的区别停留在“2.0 更快”的模糊认知上。今天我们从协议格式、连接模型、队头阻塞、服务端推送等角度，带流程图详细对比。

---

02. HTTP 1.0：基础但“短视”的早期设计

2.1 核心特点

• 每个请求/响应需要建立新的 TCP 连接（短连接）。
• 请求完成后立即断开，下一个请求必须重新三次握手。
• 支持 GET、POST、HEAD 方法。
• 有状态响应码、MIME 类型（Content-Type 引入）。
• 无 Host 头（导致虚拟主机难实现，后来 1.1 才加）。

2.2 典型流程图：HTTP 1.0 请求过程

客户端                    服务器
  |                        |
  |---- 建立 TCP 连接 ---->|
  |<--- SYN-ACK -----------|
  |---- ACK ---------------|
  |                        |
  |---- GET /index.html -->|
  |<--- 200 OK + HTML -----|
  |                        |
  |---- FIN ---------------|
  |<--- ACK ---------------|
  |<--- FIN ---------------|
  |---- ACK ---------------|
  |                        |
  |   (下一次请求重新握手)  |

2.3 主要问题

1. 连接无法复用：每请求一次 TCP 握手 + 慢启动，延迟高。
2. 队头阻塞 (HOL blocking)：一个请求未响应前，无法发下一个请求（虽然可以并发多个 TCP 连接，但浏览器限制 4~6 个）。
3. 头部冗余巨大：每次请求都重复携带 User-Agent、Accept 等大量文本头。

---

03. HTTP 2.0：性能重构的二进制时代

3.1 核心改进

• 二进制分帧层：将请求/响应拆分为更小的帧（Header 帧、Data 帧）。
• 多路复用：在一个 TCP 连接上交错发送多个请求/响应的帧。
• 头部压缩（HPACK）：消除重复头部，减少传输量。
• 服务端推送：服务器可主动推送相关资源（如 HTML 推送 CSS/JS）。
• 请求优先级：可指定资源加载优先级。

3.2 多路复用流程图

TCP 连接 (单一)
   │
   ├── 请求1: 帧 A1 (HEADERS) ──┐
   ├── 请求2: 帧 B1 (HEADERS) ──┤
   ├── 请求1: 帧 A2 (DATA)   ──┤  交错发送/接收
   ├── 请求3: 帧 C1 (HEADERS) ──┤  不阻塞彼此
   ├── 请求2: 帧 B2 (DATA)   ──┤
   ├── 请求1: 帧 A3 (DATA)   ──┘
   │
   └── 所有请求共享同一 TCP 连接

服务端响应同理，帧可以乱序但最终按 Stream ID 组装。

3.3 HTTP 2.0 如何解决 1.0 的痛点？

问题	HTTP 1.0 表现	HTTP 2.0 解决方式
连接无法复用	每次请求新连接，延迟高	单一持久连接，所有请求多路复用
队头阻塞（应用层）	请求串行，前一个慢则后一个等	帧级别交错，无应用层阻塞
头部冗余	纯文本，每次重复数百字节	HPACK 压缩，动态表 + 静态表，体积减少85%+
服务端被动响应	只能客户端请求什么返回什么	服务端推送（PUSH_PROMISE）
协议可读性	文本协议，抓包易读但效率低	二进制帧，机器高效解析

---

04. 详细对比表：HTTP 1.0 vs HTTP 2.0

对比维度	HTTP 1.0	HTTP 2.0
协议格式	文本（ASCII）	二进制帧（HEADERS/DATA/PRIORITY等）
连接模型	短连接，非持久	长连接，多路复用
并发请求方式	需多 TCP 连接（浏览器限制 4~6）	单 TCP 连接内无限并发流（Stream ID）
队头阻塞	有（应用层 HOL）	无（帧交错），但 TCP 层 HOL 仍存在
头部压缩	无（Gzip 仅压缩 body）	HPACK 压缩（索引表 + 霍夫曼编码）
服务端推送	不支持	支持（PUSH_PROMISE 帧）
优先级/依赖	无	支持流优先级与依赖树
流量控制	TCP 窗口	独立流级流量控制（WINDOW_UPDATE）
TLS 要求	可选	多数实现要求（h2 over TLS）
请求方法/状态码	方法少（GET/POST/HEAD）	兼容 1.x 方法，扩展状态码

---

05. 重要说明：不是所有“队头阻塞”都解决了

HTTP 2.0 解决了应用层的队头阻塞，但在 TCP 层仍存在 TCP 队头阻塞：
如果 TCP 连接丢失一个包，后面的所有帧（即便属于不同请求）必须等待重传完成。

这也是 HTTP 3.0 (QUIC) 引入的原因：基于 UDP 实现每个流独立丢包恢复。

---

06. 实践建议：什么时候还选 1.0，什么时候上 2.0？

• 仍然只用 HTTP 1.0 的场景：极简嵌入式设备、老旧客户端、纯文本 API 且单次请求为主。但大多数场景应至少升级到 HTTP 1.1。
• 强烈推荐 HTTP 2.0 的场景：
  • 高并发 Web 页面（大量小资源 CSS/JS/图标）
  • API 网关需要低延迟
  • 移动端网络（减少连接数省电）
  • 需要服务端推送（如资源预加载）

当前实际线上：绝大部分已使用 HTTP 1.1 或 2.0，纯粹的 1.0 几乎只存在于历史系统或教学示例中。

---

07. 总结：一张图看懂演进核心

HTTP 1.0       →        HTTP 2.0
 短连接             单一长连接
 文本请求/响应      二进制帧流
 串行请求          多路复用
 无压缩头          HPACK 压缩
 无推送            服务端推送

• HTTP 1.0 是 Web 起步期产物，简单但低效。
• HTTP 2.0 保留了 1.x 语义（方法/状态码/URI），但彻底重构了传输层效率。

---