HTTP2

HTTP/2（超文本传输协议第2版）是继HTTP/1.1之后的一次重大升级，旨在解决现代网页加载速度慢、延迟高和资源利用率低的问题。它于2015年正式标准化（RFC 7540），并在随后几年内被全球绝大多数主流网站和浏览器广泛采用。

1. 核心痛点：为什么要升级？

在理解HTTP/2之前，必须先看它的"前任"HTTP/1.1存在的主要问题：

• 队头阻塞（Head-of-Line Blocking）：在HTTP/1.1中，一个TCP连接在同一时间只能处理一个请求/响应。如果前面的请求处理慢（例如下载一个大图片），后面的请求即使很小也必须等待。虽然可以通过建立多个TCP连接来并发，但这增加了服务器负担和握手延迟。
• 头部冗余：每次请求都携带大量的重复头部信息（如Cookie、User-Agent），且以明文文本传输，浪费带宽。
• 缺乏优先级：服务器通常按照接收顺序处理请求，无法智能判断哪些资源（如HTML、CSS）更重要，导致关键资源加载延迟。
• 服务器被动：服务器只能被动响应客户端的请求，无法主动推送客户端可能需要的资源。

2. HTTP/2 的四大核心特性

为了解决上述问题，HTTP/2引入了以下革命性的机制：

(1) 二进制分帧层 (Binary Framing Layer)

这是HTTP/2最根本的变化。

• 变化 ：HTTP/1.x是明文文本 协议，人类可读但解析效率低；HTTP/2是二进制协议，机器解析效率极高。
• 机制 ：
  • 帧（Frame）：通信的最小单位。
  • 消息（Message）：完整的请求或响应，由一个或多个帧组成。
  • 流（Stream）：一个虚拟的双向通道，对应一个逻辑上的请求/响应任务。
• 优势：在一个TCP连接上，不同的流可以交错发送（多路复用），接收端根据帧头的流标识符（Stream ID）重新组装成完整的消息。这彻底解决了应用层的队头阻塞问题。

(2) 多路复用 (Multiplexing)

• 原理 ：基于二进制分帧，客户端和服务器可以在同一个TCP连接上同时发送和接收多个请求和响应。
• 效果 ：
  • 不再需要为了并发而建立多个TCP连接（通常浏览器限制每个域名6个连接）。
  • 极大地减少了TCP握手（三次握手）和慢启动（Slow Start）带来的延迟。
  • 即使某个请求响应较慢，也不会阻塞同一连接上的其他请求。

(3) 头部压缩 (HPACK)

• 原理 ：使用专门的HPACK算法对头部进行压缩。
• 机制 ：
  • 静态表与动态表 ：客户端和服务器维护一份相同的头部字段表（如 :method: GET, content-type: application/json）。传输时只需发送索引号，无需重复发送完整字符串。
  • 消除冗余：对于同一连接上的后续请求，重复出现的头部（如Cookie）会被极大压缩。
• 优势：显著减少了网络流量，特别是在移动网络环境下，提升了加载速度并节省了用户流量。

(4) 服务器推送 (Server Push)

• 原理 ：允许服务器在客户端请求一个资源（如 index.html）时，主动 将客户端尚未请求但预判其需要的资源（如 style.css, app.js）推送给客户端。
• 优势：减少了往返次数（RTT），理论上能进一步加速页面渲染。
• 现状注意 ：虽然这是一个强大的特性，但在实际应用中，由于配置复杂、可能导致推送了客户端不需要的资源（浪费带宽）、以及浏览器缓存策略的复杂性，许多大型网站（如Google Chrome团队）在后期倾向于谨慎使用甚至默认禁用此功能，转而依赖更智能的资源提示（如 <link rel="preload">）。

3. HTTP/2 与 HTTP/1.1 的对比

特性	HTTP/1.1	HTTP/2
数据格式	明文文本 (ASCII)	二进制 (Binary)
连接方式	多连接并发（受浏览器限制），单连接串行	单连接多路复用
队头阻塞	存在（应用层阻塞）	消除（应用层无阻塞，但需注意TCP层阻塞）
头部传输	明文，无压缩，冗余大	HPACK压缩，高效
服务器推送	不支持	支持 (Server Push)
优先级	无（靠连接顺序）	支持 (Stream Priority)
安全性	可选 (HTTP/HTTPS)	标准虽未强制加密，但所有主流浏览器仅支持加密版本 (h2 over TLS)

4. 潜在局限性：TCP层面的队头阻塞

虽然HTTP/2解决了应用层 的队头阻塞，但它仍然依赖TCP协议。

• 问题：如果在网络状况较差的情况下，单个TCP数据包丢失，整个TCP连接都会暂停等待重传（因为TCP是可靠传输，保证顺序）。此时，尽管HTTP/2内部有多个流，但它们共享同一个TCP连接，因此所有流都会受到这个丢包的影响而停滞。
• 解决方案 ：这正是HTTP/3 诞生的原因。HTTP/3将传输层从TCP替换为基于UDP的QUIC协议，从而彻底解决了传输层的队头阻塞问题。

追问

• 追问 1：HTTP/2 必须用 HTTPS 吗？
  • 回答 ：协议标准本身不强制，但所有主流浏览器（Chrome, Firefox, Safari 等）都规定只有在 HTTPS 下才启用 HTTP/2。所以工程实践中，它就是绑定 HTTPS 的。
• 追问 2：既然有多路复用，为什么还需要域名分片（Domain Sharding）？
  • 回答 ：不需要了，甚至是有害的。域名分片是 HTTP/1.1 为了突破浏览器并发限制（6个连接）的 hack 手段。在 HTTP/2 下，单连接效率最高，分片反而增加了 DNS 解析和 TCP 握手的开销。
• 追问 3：说说 HPACK 是怎么压缩的
  • 回答 ：不用背算法细节，只要提到它维护了静态表 （常见头部）和动态表（历史请求头部），传输时只发索引号，并且利用哈夫曼编码（Huffman Coding）进一步压缩字符串。
• 追问 4：在项目中怎么验证 HTTP/2 生效了？
  • 回答 ：打开浏览器开发者工具（Network 面板），看 Protocol 列是否显示 h2；或者用 curl -I --http2 https://your-site.com 查看响应头。