🌅 诞生背景与核心设计目标
🐌 HTTP/1.1 的致命痛点
队头阻塞 (Head-of-Line Blocking)：同一连接同一时刻只能处理一个请求，后续请求必须排队等待
头部冗余 (Header Redundancy)：HTTP 头部包含大量重复文本（如 Cookie、User-Agent），且无法被 gzip 有效压缩，浪费带宽
缺乏优先级机制：无法告知服务端哪些资源（如 HTML/CSS）更重要，导致关键资源加载延迟
服务端推送受限：只能被动响应，无法主动向客户端推送预测需要的资源
🚀 SPDY 协议 (HTTP/2 的前身)
由 Google 主导开发，作为 HTTP/2 的实验床
首次引入多路复用、头部压缩、服务器推送等核心概念
证明了在应用层解决 HTTP/1.1 性能瓶颈的可行性
🎯 HTTP/2 的核心设计目标 (RFC 7540)
解决 HTTP/1.1 的队头阻塞问题 (通过多路复用)
大幅降低头部开销 (通过 HPACK 算法)
支持请求优先级 (通过依赖树和权重)
支持服务器主动推送资源
保持与 HTTP/1.1 的语义兼容性 (方法、状态码、URI 不变，只改底层传输)
🧱 核心基石：二进制分帧层 (Binary Framing Layer)
🔄 从文本到二进制的范式转变
HTTP/1.1 是面向文本的，依赖换行符解析，容易出错且解析效率低
HTTP/2 将所有传输的数据（请求、响应、控制信息）分割为更小的二进制帧
优势：解析高效、容错率高、易于扩展、为多路复用奠定基础
📦 帧 (Frame) 的微观结构 (最小传输单元)
长度 (Length, 24 bit)：帧负载的长度，最大 16383 字节 (可通过 SETTINGS 扩展至 16MB)
类型 (Type, 8 bit)：标识帧的类型 (如 0x0 是 DATA, 0x1 是 HEADERS)
标志 (Flags, 8 bit)：特定于帧类型的布尔标志 (如 END_STREAM, END_HEADERS)
保留位 (R, 1 bit)：必须为 0，否则视为协议错误
流标识符 (Stream Identifier, 31 bit)：标识该帧属于哪个流 (0 号流用于连接控制)
帧负载 (Payload)：实际携带的数据
🧩 核心帧类型深度拆解
DATA (0x0)：携带 HTTP 消息体 (Body) 数据
HEADERS (0x1)：携带 HTTP 头部，可开启 END_HEADERS 标志，或后续跟 CONTINUATION 帧
PRIORITY (0x2)：指定或调整流的优先级和依赖关系
RST_STREAM (0x3)：异常终止某个流 (流级错误)
SETTINGS (0x4)：交换连接级配置参数 (如 HEADER_TABLE_SIZE, ENABLE_PUSH)，仅在 0 号流发送
PUSH_PROMISE (0x5)：服务端通知客户端即将推送的资源头部
PING (0x6)：测量往返时间 (RTT) 和检测连接存活 (类似 ICMP ping)
GOAWAY (0x7)：优雅关闭连接，告知客户端最后处理的流 ID，拒绝新请求
WINDOW_UPDATE (0x8)：用于流量控制，通知对方增加发送窗口
CONTINUATION (0x9)：用于延续过大的 HEADERS 或 PUSH_PROMISE 帧
🌊 核心特性一：多路复用与流 (Multiplexing & Streams)
🛶 流 (Stream) 的概念与生命周期
定义：TCP 连接内的一条双向字节流通道，承载一个完整的 HTTP 请求/响应
核心特性：多个流共享同一个 TCP 连接，帧可以交错传输
流状态机 (Stream State Machine)
idle (空闲)：初始状态，收到 HEADERS 帧后转为 open 或 reserved
reserved (local/remote)：收到 PUSH_PROMISE 后的状态，等待 HEADERS
open (打开)：双向均可发送数据，收到 END_STREAM 标志后转为 half-closed
half-closed (local/remote)：单向关闭，只能接收或只能发送
closed (关闭)：收到 END_STREAM 且数据传完，或收到 RST_STREAM
🔢 流标识符 (Stream ID) 规则
客户端发起的流：使用奇数 (1, 3, 5...)
服务端发起的流 (推送)：使用偶数 (2, 4, 6...)
0 号流：专用于连接控制 (如 SETTINGS, PING, GOAWAY)，不承载业务数据
耗尽处理：当 ID 达到 2^31-1 时，必须发起 GOAWAY 关闭连接并重建
💡 多路复用如何解决 HTTP/1.1 队头阻塞
应用层解耦：多个请求的帧在同一个 TCP 连接上交错发送，无需等待前一个响应完成
并行处理：服务端可以同时处理多个请求并交错返回响应帧
彻底消除 HTTP 层面的队头阻塞 (但引入了 TCP 层面的队头阻塞，见后文)
🗜️ 核心特性二：HPACK 头部压缩算法
🎯 为什么需要专门的头部压缩？
HTTP 头部重复率极高 (如 Cookie 每次请求都带)
使用通用压缩 (gzip) 会引发 CRIME/BREACH 等 TLS 侧信道攻击
需要一种既能高效压缩，又能保证安全性的专用算法
📚 静态字典 (Static Table)
预定义的 61 个常见 HTTP 头部 (如 :method: GET, :status: 200, content-type)
通过简单的索引号 (1-61) 直接引用，无需传输实际字符串
🔄 动态字典 (Dynamic Table)
连接级别的上下文，通信双方同步维护
采用 FIFO (先进先出) 策略，当大小超过 SETTINGS 协商的 HEADER_TABLE_SIZE 时，淘汰旧条目
支持增量更新：只需传输新增的头部或引用已有条目的索引
🔤 哈夫曼编码 (Huffman Coding)
对字符串值进行无损压缩，基于字符出现频率构建前缀编码树
常见字符 (如 e, t, /) 用短码，罕见字符用长码，平均压缩率极高
强制要求：实现必须支持哈夫曼编码，以最大化压缩效率
🛡️ 安全性设计
动态表不跨请求共享：防止攻击者通过观察压缩后的大小推断加密前的头部内容
⚖️ 核心特性三：流优先级与依赖调度
🌳 依赖树模型 (Dependency Tree)
流之间可以建立父子依赖关系，形成一棵树 (0 号流为根节点)
语义：父流应优先于子流分配资源 (如 HTML 是父，CSS/JS 是子)
⚖️ 权重 (Weight) 分配
每个流分配 1-256 的权重值 (默认 16)
同级流之间按权重比例分配带宽 (如权重 128 和 64，分配比例为 2:1)
🔄 动态优先级调整
客户端可通过 PRIORITY 帧在运行时动态修改流的依赖关系和权重
应对场景：用户滚动页面时，动态提升视口内图片流的优先级
⚠️ 服务端实现策略
RFC 规定优先级仅为“建议”，服务端可以选择忽略
优秀的服务端 (如 Nginx, Envoy) 会根据优先级队列进行严格的调度
📦 核心特性四：服务器推送 (Server Push)
🚀 工作原理
客户端请求 HTML -> 服务端解析 HTML，发现需要 CSS/JS
服务端发送 PUSH_PROMISE 帧 (包含 CSS/JS 的伪头部)
服务端紧接着发送 HEADERS 和 DATA 帧，将 CSS/JS 推送给客户端
客户端收到后，将其放入缓存，后续请求直接命中缓存
🎛️ 客户端控制机制
禁用推送：客户端在 SETTINGS 帧中设置 ENABLE_PUSH = 0
取消推送：客户端收到 PUSH_PROMISE 后，若不需要，可立即发送 RST_STREAM 取消
并发限制：推送流受服务端 MAX_CONCURRENT_STREAMS 限制
📉 局限性与现代替代方案
痛点：浪费带宽 (推送已缓存的资源)、引发推送风暴、增加服务端 CPU 负担
替代方案 1：HTML 中使用 <link rel="preload"> (由客户端主动发起高优先级请求)
替代方案 2：103 Early Hints (服务端先返回 103 状态码和 Link 头，提示客户端预加载)
🚦 核心特性五：流量控制 (Flow Control)
🎯 设计目的
防止发送方发送数据过快，导致接收方缓冲区溢出或网络拥塞
与 TCP 流量控制不同，HTTP/2 流量控制是应用层级别的，且基于流和连接双重维度
🪟 基于窗口的控制机制
初始窗口：连接建立时，流级别和连接级别的初始窗口均为 65535 字节
窗口更新：接收方处理完数据后，发送 WINDOW_UPDATE 帧，增加对方的发送窗口
窗口耗尽：当窗口降为 0 时，发送方必须暂停发送该流或连接的数据
📊 双层控制模型
流级别流量控制：限制单个流的最大 Inflight 数据量
连接级别流量控制：限制整个 TCP 连接的最大 Inflight 数据量 (所有流之和)
发送逻辑：发送数据量必须同时小于 流窗口 和 连接窗口
🔌 连接管理与错误处理机制
🤝 连接前导码 (Connection Preface)
客户端前导码：发送魔法字符串 PRI * HTTP/2.0\r\n\r\nSM\r\n\r\n (用于兼容 HTTP/1.1 服务器)
紧接着发送 SETTINGS 帧 (声明客户端参数)
服务端前导码：直接回复 SETTINGS 帧 (声明服务端参数)
协商完成：双方收到对方的 SETTINGS 并回复 ACK 后，连接正式建立
🛑 优雅关闭 (Graceful Shutdown)
触发场景：服务端需要重启、负载均衡器需要漂移连接
GOAWAY 帧：携带 Last-Stream-ID，告知客户端“大于此 ID 的请求将被拒绝”
行为：客户端停止发送新请求，服务端继续处理已接收的请求，直到所有流关闭
⚠️ 错误处理机制
连接级错误 (Connection Errors)：如帧格式错误、前导码不匹配。发送 GOAWAY 帧并关闭 TCP 连接
流级错误 (Stream Errors)：如某个流的数据损坏。发送 RST_STREAM 帧，仅终止该流，不影响其他流
⚔️ HTTP/2 vs HTTP/1.1 深度对比与 TLS 要求
📊 核心维度全方位对比
数据格式：HTTP/1.1 文本 vs HTTP/2 二进制分帧
多路复用：HTTP/1.1 不支持 (需多连接/管线化) vs HTTP/2 原生支持 (单连接多流)
头部压缩：HTTP/1.1 无 (或仅 gzip 压缩 body) vs HTTP/2 HPACK 高效压缩
优先级：HTTP/1.1 无 vs HTTP/2 依赖树与权重
服务器推送：HTTP/1.1 不支持 vs HTTP/2 原生支持
🔒 强制 TLS 要求与 ALPN
RFC 规范：HTTP/2 规范本身不强制要求 TLS (支持 h2c 明文模式)
浏览器现实：所有主流浏览器强制要求 HTTP/2 必须运行在 TLS 之上
ALPN (应用层协议协商)：在 TLS 握手阶段 (ClientHello) 协商使用 h2 协议，避免额外的往返延迟
🚀 配合 TLS 1.3 的性能飞跃
TLS 1.3 将握手从 2-RTT 降至 1-RTT (甚至 0-RTT)
结合 HTTP/2 的多路复用，实现极致的首屏加载速度
🛠️ 实战调优、排障与向 HTTP/3 的演进
⚙️ 服务端配置调优指南
并发流限制：调整 MAX_CONCURRENT_STREAMS (默认 128)，防止单个客户端耗尽服务端资源
初始窗口大小：适当调大 INITIAL_WINDOW_SIZE，减少高延迟网络下的 WINDOW_UPDATE 开销
动态表大小：根据头部复杂度调整 HEADER_TABLE_SIZE，平衡内存与压缩率
🕵️ Wireshark 抓包与分析技巧
解密 TLS：配置 Pre-Master Secret 日志，解密 HTTPS 流量
查看帧结构：在 Packet Details 中展开 Hypertext Transfer Protocol V2 查看帧类型和标志位
流追踪：使用 Follow Stream 功能，按 Stream ID 过滤，还原完整的请求/响应交互
🚨 HTTP/2 的终极痛点：TCP 队头阻塞
问题本质：HTTP/2 解决了应用层队头阻塞，但底层仍依赖 TCP。若 TCP 层丢失一个包，整个 TCP 连接上的所有 HTTP/2 流都必须等待该包重传 (传输层队头阻塞)
影响：在高丢包的弱网环境下，HTTP/2 的性能甚至可能不如 HTTP/1.1 (因为 HTTP/1.1 可以用多个 TCP 连接规避)
🌌 终极演进：HTTP/3 (基于 QUIC)
核心变革：将底层传输协议从 TCP+TLS 替换为基于 UDP 的 QUIC
彻底解决队头阻塞：QUIC 在 UDP 之上实现可靠传输，每个流独立重传，一个流丢包不影响其他流
0-RTT 建连：将 TLS 握手与传输层握手合并，实现真正的 0-RTT 连接建立
连接迁移：基于 Connection ID 而非 IP+Port，Wi-Fi 切换 4G 时连接不中断
