在HTTP协议中，头部压缩（Header Compression）是优化网络性能的重要手段，尤其在HTTP/2和HTTP/3中成为核心特性。以下是主流的头部压缩算法及其工作原理和适用场景：
1. HPACK（HTTP/2 专用）
- 用途：HTTP/2的默认头部压缩算法，专为HTTP头部设计。
- 核心机制：
- 静态表（Static Table）：预定义61个常见HTTP头部字段（如
:method: GET、:path: /），直接通过索引引用，无需传输完整内容。 - 动态表（Dynamic Table）：根据请求上下文动态维护的键值对表，存储最近使用的头部字段，索引从62开始递增。
- 霍夫曼编码（Huffman Coding）：对头部值进行高频字符优化编码，进一步压缩体积。
- 优点：
- 避免冗余传输（如重复的
Cookie字段）。 - 安全性高（无依赖压缩上下文，避免CRIME攻击）。
- 示例：
- 静态表索引
2表示:method: GET，传输时只需发送0x82（二进制10000010）。 - 动态表会缓存如
user-agent: Mozilla/5.0等频繁出现的头部。
2. QPACK（HTTP/3 专用）
- 用途：HTTP/3的头部压缩算法，基于HPACK改进以适配QUIC协议（基于UDP）。
- 改进点：
- 独立流处理：允许头部块在多个QUIC流中乱序传输，解决TCP队头阻塞问题。
- 动态表异步更新：通过单独的“Encoder Stream”和“Decoder Stream”同步动态表状态，避免数据包丢失导致表不一致。
- 特点：兼容HPACK的静态表，但动态表管理更复杂。
3. DEFLATE（传统算法，已弃用）
- 历史背景：早期SPDY协议使用DEFLATE（基于LZ77和哈夫曼编码）压缩头部，后被HTTP/2弃用。
- 问题：
- CRIME攻击风险：攻击者可通过注入已知明文推测加密内容（如Cookie）。
- 上下文依赖：压缩状态跨请求保留，易被利用。
- 现状：不再推荐用于HTTP头部压缩。
4. 其他通用压缩算法
虽然不专用于头部压缩，但某些场景可能结合以下算法：
- gzip：通用压缩，但需全量压缩/解压，效率低于HPACK。
- Brotli（Br）：Google开发的高效压缩算法，常用于HTTP内容体（如HTML/CSS），但不适合小数据（如头部）。
- Zstandard（zstd）：Facebook开发的高性能压缩算法，压缩比和速度均衡，但未在HTTP头部中广泛应用。
对比总结
算法 | 协议 | 核心机制 | 安全性 | 适用场景 |
HPACK | HTTP/2 | 静态表 + 动态表 + 霍夫曼编码 | 高 | 基于TCP的HTTP/2通信 |
QPACK | HTTP/3 | HPACK改进 + 异步流管理 | 高 | 基于QUIC的HTTP/3通信 |
DEFLATE | SPDY | LZ77 + 哈夫曼编码 | 低（CRIME） | 历史协议，已弃用 |
gzip | 通用 | LZ77 + 哈夫曼 | 中 | 内容体压缩，非头部专用 |
HPACK 工作原理详解
- 静态表压缩
- 常见字段（如
:method: GET）直接用1字节索引表示（如0x82）。 - 示例：
头部字段: :path: /index.html
匹配静态表索引2 -> 编码为 0x82- 动态表更新
- 动态表按先进先出（FIFO）管理，新条目插入表头，旧条目超出容量时淘汰。
- 示例：
首次发送 user-agent: Mozilla/5.0 -> 动态表索引62
后续发送同一头部 -> 编码为 0xBE（二进制10111110）- 霍夫曼编码
- 对头部值进行高频字符优化，如字母
e用更短编码表示。 - 示例：
值 "example" 的霍夫曼编码可能为二进制11001010...为什么HTTP/2选择HPACK而非DEFLATE？
- 安全性：HPACK避免CRIME攻击，DEFLATE因上下文依赖存在风险。
- 性能：静态表和动态表减少冗余，压缩效率更高。
- 确定性：编码/解码过程无状态依赖，适合HTTP/2多路复用。
未来趋势
- QPACK普及：随着HTTP/3和QUIC协议的推广，QPACK将成为头部压缩主流。
- 算法优化：针对5G和高延迟网络，进一步减少压缩开销和提升解压速度。
通过选择专用头部压缩算法（如HPACK/QPACK），可显著降低HTTP头部体积（典型场景节省50%~80%带宽），提升网页加载速度和用户体验。
