HTTP/2
[!abstract] 一句话定义 HTTP/2 是 HTTP 协议的第二个主要版本，通过多路复用、头部压缩、服务端推送等技术，解决了 HTTP/1.1 的队头阻塞问题，大幅提升 Web 性能。
为什么需要它？
想象你打开一个包含 50 个资源的网页。在 HTTP/1.1 下，浏览器需要建立 6-8 个 TCP 连接，每个连接串行请求资源，前面的请求慢了会阻塞后面所有请求（队头阻塞）。用户看到的是白屏等待。HTTP/2 让所有请求在一个连接上并行传输，页面加载时间可减少 50% 以上。
核心直觉
类比：餐厅点餐
| 版本 | 类比 |
|---|---|
| HTTP/1.0 | 每道菜都要等前一道上完才能点下一道，换一桌客人要换一张桌子 |
| HTTP/1.1 | 可以连续点菜（持久连接），但厨师一次只能做一道菜（串行处理） |
| HTTP/2 | 厨师有多个灶台同时做菜（多路复用），还能提前准备你可能会要的菜（服务端推送） |
它是怎么工作的？
版本演进概览
graph LR
A[HTTP/1.0<br/>1996] -->|持久连接| B[HTTP/1.1<br/>1997]
B -->|二进制分帧| C[HTTP/2<br/>2015]
C -->|QUIC/UDP| D[HTTP/3<br/>2022]
style A fill:#ffcccc
style B fill:#ffffcc
style C fill:#ccffcc
style D fill:#ccccff
HTTP/2 核心机制
sequenceDiagram
participant Client as 客户端
participant Server as 服务器
Note over Client,Server: HTTP/1.1: 串行请求（队头阻塞）
Client->>Server: 请求 A
Server-->>Client: 响应 A（耗时 2s）
Client->>Server: 请求 B
Server-->>Client: 响应 B（耗时 1s）
Client->>Server: 请求 C
Server-->>Client: 响应 C（耗时 1s）
Note over Client,Server: 总耗时: 4s
Note over Client,Server: HTTP/2: 多路复用（并行传输）
Client->>Server: 请求 A + 请求 B + 请求 C
Server-->>Client: 响应 C 片段
Server-->>Client: 响应 A 片段
Server-->>Client: 响应 B 片段
Server-->>Client: 响应 C 片段
Server-->>Client: 响应 A 片段
Note over Client,Server: 总耗时: 2s
关键技术细节
1. 二进制分帧层
- HTTP/1.x 是文本协议，解析复杂且易出错
- HTTP/2 将数据拆分为更小的帧（Frame），用**流（Stream）**标识属于哪个请求
- 帧格式：
Length (9 bits) + Type (8 bits) + Flags (8 bits) + Stream ID (31 bits) + Payload
2. 多路复用（Multiplexing）
- 一个 TCP 连接上可以并行发送多个请求/响应
- 每个请求/响应拆分成帧，帧之间可以交错发送
- 通过 Stream ID 区分不同请求的帧
3. 头部压缩（HPACK）
- HTTP/1.x 每次请求都携带完整头部（Cookie 等可达数 KB）
- HTTP/2 使用 HPACK 算法：维护头部字段表，只发送差异部分
- 压缩率可达 80%-95%
4. 服务端推送（Server Push）
- 服务器可以主动推送客户端可能需要的资源
- 例如：请求
index.html时，服务器主动推送style.css、script.js - 减少一轮 RTT（往返时间）
关键组件 / 核心要素
| 组件 | 作用 | 类比 |
|---|---|---|
| 帧（Frame） | 最小通信单位，携带特定类型数据 | 快递包裹 |
| 消息（Message） | 一个完整的请求或响应，由多个帧组成 | 一批快递 |
| 流（Stream） | 一个完整的请求-响应双向帧序列，有唯一 ID | 快递单号 |
| 连接（Connection） | 一个 TCP 连接，可承载多个流 | 快递员 |
与相关概念的关系
[!info] vs HTTP1.1
- 队头阻塞：HTTP/1.1 在应用层有队头阻塞，HTTP/2 在应用层解决了，但 TCP 层仍有
- 连接数：HTTP/1.1 需要 6-8 个连接，HTTP/2 只需 1 个
- 协议格式：HTTP/1.1 是文本，HTTP/2 是二进制
- 头部处理：HTTP/1.1 每次完整发送，HTTP/2 增量压缩
[!info] vs HTTP3
- 传输层：HTTP/2 基于 TCP，HTTP/3 基于 QUIC（UDP）
- 队头阻塞：HTTP/2 在 TCP 层仍有队头阻塞，HTTP/3 完全解决
- 连接建立：HTTP/2 需要 TCP+TLS 握手（2-3 RTT），HTTP/3 只需 1 RTT
- 连接迁移：HTTP/2 切换网络需要重建连接，HTTP/3 支持无缝迁移
[!tip] 被 HTTPS 使用 现代 HTTPS 站点普遍采用 HTTP/2，浏览器要求 HTTP/2 必须使用 TLS
典型应用场景
- 高并发 Web 应用 — 一个连接承载所有请求，减少连接开销
- 移动端网页 — 网络不稳定时，多路复用避免单个慢请求阻塞整体
- API 服务 — 微服务间通信，头部压缩减少重复元数据传输
- 实时应用 — 服务端推送可替代部分长轮询场景
HTTP/1.1 vs HTTP/2 详细对比
| 特性 | HTTP/1.0 | HTTP/1.1 | HTTP/2 |
|---|---|---|---|
| 连接方式 | 短连接（一次请求一个连接） | 持久连接 + 管线化 | 单连接多路复用 |
| 协议格式 | 文本 | 文本 | 二进制分帧 |
| 头部压缩 | 无 | 无（仅支持 gzip body） | HPACK 静态/动态表 |
| 队头阻塞 | 严重 | 存在（管线化不完善） | 应用层无，TCP 层仍有 |
| 服务端推送 | 不支持 | 不支持 | 支持 |
| 并发连接数 | N 个请求 N 个连接 | 6-8 个连接 | 1 个连接 |
| 优先级控制 | 无 | 无 | 支持流优先级 |
| 典型延迟 | 高 | 中 | 低 |
常见误解与陷阱
[!danger] ❌ 误以为：HTTP/2 完全解决了队头阻塞 ✅ 实际上：HTTP/2 只解决了应用层的队头阻塞，TCP 层的队头阻塞仍然存在（HTTP/3 通过 QUIC/UDP 才完全解决）
[!danger] ❌ 误以为：HTTP/2 不需要优化 ✅ 实际上：HTTP/2 改变了优化策略——不再需要域名分片、资源合并（雪碧图），但仍有其他优化点
[!danger] ❌ 误以为：HTTP/2 一定比 HTTP/1.1 快 ✅ 实际上：在高延迟、丢包严重的网络下，TCP 层队头阻塞可能导致 HTTP/2 性能不如多个 HTTP/1.1 连接
延伸阅读
- 想深入理解原理 → 阅读 RFC 7540（HTTP/2 规范）和 RFC 7541（HPACK 规范）
- 想看工程实践 → 浏览器开发者工具 Network 面板可查看 HTTP/2 帧信息
- 想了解前沿进展 → 关注 HTTP/3（RFC 9114）和 QUIC 协议
关联笔记
前置知识：HTTP协议基础 · TCP三次握手 同族概念：HTTP1.1 · HTTP3 · HTTPS 应用场景：Web性能优化 · Nginx配置 · CDN加速