HTTP/1.1 与 HTTP/2 的核心区别

1. 协议格式

• HTTP/1.1：基于文本格式的协议（明文传输），例如一个请求头如下：

  GET /index.html HTTP/1.1
  Host: example.com
  User-Agent: Chrome
  

• HTTP/2：基于二进制分帧的协议，将请求/响应拆分为更小的二进制帧（如 HEADERS 帧、DATA 帧），传输更高效。

案例：
HTTP/1.1 的文本格式易读但冗余，而 HTTP/2 的二进制帧减少了冗余字符。例如，同样的请求头在 HTTP/2 中会被压缩为二进制，体积更小。

2. 连接方式

• HTTP/1.1：

  • 短连接：默认关闭长连接（需显式添加 Connection: keep-alive）。
  • 队头阻塞（HOL Blocking）：同一 TCP 连接中的请求必须按顺序处理，若前一个请求延迟，后续请求会被阻塞。

• HTTP/2：

  • 多路复用（Multiplexing）：单个 TCP 连接上可并行传输多个请求/响应，无队头阻塞。
  • 流（Stream）：每个请求/响应被分配一个唯一流 ID，数据帧可乱序发送，接收端按流 ID 重组。

案例：

• HTTP/1.1：浏览器加载一个包含 10 张图片的页面时，若使用 1 个 TCP 连接，需依次下载图片（排队等待）；通常浏览器会开 6-8 个 TCP 连接并行下载，但连接数有限制且开销大。
• HTTP/2：只需 1 个 TCP 连接，所有图片请求并行发送，显著减少延迟（尤其在弱网环境下）。

3. 头部压缩

• HTTP/1.1：每次请求都携带完整的头部（如 User-Agent、Cookie），重复传输冗余数据。
• HTTP/2：使用 HPACK 算法压缩头部，通过静态表（常见头部字段）和动态表（自定义字段）减少传输量。

案例：

• 假设用户访问一个网站需要发送 10 个请求，每个请求的 User-Agent 字段为 100 字节：
  • HTTP/1.1 总传输量：10 * 100 = 1000 字节
  • HTTP/2 首次传输 100 字节后，后续请求仅需 1 字节（引用静态表），总传输量：100 + 9 * 1 = 109 字节。

4. 服务器推送（Server Push）

• HTTP/1.1：服务器必须等待客户端显式请求资源。
• HTTP/2：服务器可主动推送资源到客户端缓存（如提前推送 CSS/JS 文件）。

案例：

• 用户请求 index.html，HTTP/1.1 需先返回 HTML，再由客户端解析后请求 style.css 和 app.js。
• HTTP/2 服务器可在返回 HTML 时主动推送 style.css 和 app.js，减少往返次数，提升页面加载速度。

5. 流量控制

• HTTP/1.1：依赖 TCP 的流量控制（按字节滑动窗口）。
• HTTP/2：基于流的粒度控制流量，防止单个流占用过多带宽。

案例：

• 在视频网站中，HTTP/2 可优先传输用户当前观看的视频流，而暂停后台预加载的其他视频流。

实际场景对比

场景 1：加载包含多资源的网页

• HTTP/1.1：

  • 浏览器建立多个 TCP 连接（如 6 个），每个连接串行下载资源，导致资源竞争和延迟。
  • 大量重复的头部信息（如 Cookie）占用带宽。

• HTTP/2：

  • 单个 TCP 连接并行传输所有资源，无队头阻塞。
  • 头部压缩减少冗余，服务器推送提前加载关键资源。
  • 结果：页面加载时间减少 30%~50%。

场景 2：实时流媒体传输

• HTTP/1.1：

  • 无法支持流式传输（需依赖 WebSocket 或长轮询）。
  • 每个请求/响应独立，难以实现双向实时通信。

• HTTP/2：

  • 支持双向流（Bidirectional Streaming），服务端和客户端可同时发送数据帧。
  • 案例：gRPC 基于 HTTP/2 的双向流实现实时聊天或股票行情推送。

总结：HTTP/2 的核心优势

何时选择 HTTP/2？

1. 高延迟网络（如移动端）：减少往返次数和头部开销。
2. 资源密集型页面：通过多路复用和服务器推送优化加载。
3. 微服务通信：结合 gRPC 实现高效 RPC 调用。

何时仍需 HTTP/1.1？

1. 老旧客户端兼容性：部分设备不支持 HTTP/2。
2. 简单场景：少量请求时，HTTP/2 的优势不明显。

通过理解 HTTP/2 的底层机制，可以更好地设计高性能网络应用（如启用 TLS 加密、优化服务器推送策略）。