后端 Web 协议（05）：HTTP 版本演进——HTTP/1.1、HTTP/2、HTTP/3 对比、性能优化
更新时间：2026-09-01。本文是
backend/web-protocol/Web 协议第 05 篇，接 WebSocket 与 SSE。HTTP 从 1.1 到 2 到 3，每次版本升级都解决了上一个版本的核心性能问题。理解它们，才能为你的服务选择合适的协议。
本文要回答的问题
- HTTP/1.1 的队头阻塞是什么？
- HTTP/2 的多路复用和 HPACK 怎么提升性能？
- HTTP/3 的 QUIC 协议解决了什么问题？
- 什么时候用 HTTP/2，什么时候用 HTTP/3？
一、HTTP/1.1 的问题
http
# HTTP/1.1 的队头阻塞（Head-of-Line Blocking）
# 一个连接上一个请求没完成，后面的请求不能开始
# 浏览器通常开 6 个连接并行，但每个连接还是串行
# 请求 1：GET /large-image.jpg
# 请求 2：GET /api/data
# 如果请求 1 的响应很大，请求 2 要等
# 解决方法：domain sharding（分域名）
# static.example.com（图片）
# api.example.com（API）
# 静态资源分多个域名，浏览器开更多连接HTTP/1.1 性能瓶颈：
- 队头阻塞：一个连接上一个请求响应慢，后续请求排队
- 连接数限制：浏览器对每个域名开 6 个连接，不够且浪费
- 头冗余：每次请求都带重复的请求头，浪费带宽
- 无法服务端推送：只能等客户端请求
二、HTTP/2 多路复用
http
# HTTP/2 解决了队头阻塞
# 一条连接上，多个请求可以并行发送和接收
# 每个请求是独立的 stream，stream 之间互不阻塞
# stream 1：GET /large-image.jpg（慢，但 stream 2 不受影响）
# stream 2：GET /api/data（先返回）
# 二进制帧：HTTP/2 把消息分成帧，帧是二进制的
# 帧头包含 stream ID，接收方按 stream ID 重组
# 多路复用：多个 stream 的帧交错发送HTTP/2 核心特性：
- 多路复用：一个连接上多个请求并行，无队头阻塞
- HPACK 压缩：请求头用 HPACK 压缩，减少重复头（压缩率 80%+）
- 服务端推送：服务端可以主动推送资源，不需要客户端请求
- 二进制帧：不是文本协议，帧头小，解析快
- 流优先级：客户可以设置 stream 的优先级
三、HTTP/2 的队头阻塞
http
# HTTP/2 在应用层解决了队头阻塞，但传输层还在 TCP
# TCP 是可靠的、有序的，如果丢了一个包，后面的包要等重传
# 这就是 TCP 层的队头阻塞
# HTTP/2 在一条 TCP 连接上多路复用
# 如果丢了一个包，所有 stream 都要等这个包重传
# 影响：丢包率 2% 时，HTTP/2 性能可能不如 HTTP/1.1四、HTTP/3 和 QUIC
http
# HTTP/3 把传输层从 TCP 换成 QUIC（基于 UDP）
# 每个 stream 独立传输，一个 stream 丢包不影响其他 stream
# QUIC 特性：
# 1. 0-RTT 连接：之前连接过的，可以直接发数据，不需要握手
# 2. 连接迁移：从 Wi-Fi 切换到移动网络，连接不中断
# 3. 独立流：一个流丢包，只影响这个流，其他流不受影响
# 4. 加密是内置的：TLS 1.3 集成在协议中HTTP/3 性能优势：
- 连接建立快：0-RTT（之前连接过）或 1-RTT（首次连接）
- 无队头阻塞：每个 stream 独立，丢包只影响一个 stream
- 连接迁移：网络切换连接不中断
- 移动网络友好：UDP 比 TCP 更适合移动网络
五、HTTP 版本对比
| 特性 | HTTP/1.1 | HTTP/2 | HTTP/3 |
|---|---|---|---|
| 传输层 | TCP | TCP | QUIC (UDP) |
| 多路复用 | 不支持 | 支持 | 支持 |
| 队头阻塞 | 应用层 + TCP 层 | TCP 层 | 无 |
| 头压缩 | 无 | HPACK | QPACK |
| 连接建立 | 2-RTT (TCP) | 2-RTT (TCP + TLS) | 0/1-RTT |
| 连接迁移 | 不支持 | 不支持 | 支持 |
| 服务端推送 | 不支持 | 支持 | 支持 |
六、选择建议
- HTTP/1.1：小项目、简单 API、对性能不敏感
- HTTP/2：通用场景，大多数 Web 应用推荐（CDN 都支持）
- HTTP/3：移动端优先、网络不稳定场景、需要快速连接建立
七、常见坑对照
| 坑 | 现象 | 对策 |
|---|---|---|
| HTTP/2 在丢包率高时性能下降 | 所有 stream 等待重传 | 高丢包环境用 HTTP/3 |
| HTTP/2 服务端推送过度 | 推送不需要的资源，浪费带宽 | 谨慎使用推送，推送关键资源 |
| QUIC 被防火墙拦截 | 连接建立失败 | 回退到 HTTP/2 或 HTTP/1.1 |
相关与延伸
Web 协议篇 5 篇完成。下一篇：后端框架：Node.js 与 NestJS——事件循环、libuv、性能陷阱；HTTP 协议基础，见 HTTP 协议。
一句话总结
HTTP 版本演进：HTTP/1.1 队头阻塞（一个连接上一个请求排队），浏览器开 6 个连接并发；HTTP/2 多路复用（一个连接上多个 stream 并行）+ HPACK 头压缩，解决应用层队头阻塞，但 TCP 层仍有队头阻塞；HTTP/3 用 QUIC（UDP）替代 TCP，每个 stream 独立，一个丢包不影响其他 stream，0-RTT 连接建立，连接迁移；移动端/高丢包推荐 HTTP/3，通用场景推荐 HTTP/2。