1. 简介

在 HTTP/1.1 中 (见 [RFC7230]), header field 不会被压缩. 随着网页发展到需要数十到数百个请求, 这些请求中的冗余 header field 会不必要地消耗带宽, 并可测量地增加时延.

SPDY [SPDY] 最初通过使用 DEFLATE [DEFLATE] 格式压缩 header field 来解决这种冗余, 这种格式被证明能非常有效地表示冗余 header field. 但是, 这种方法暴露了安全风险, CRIME (Compression Ratio Info-leak Made Easy) 攻击已经证明了这一点 (见 [CRIME]).

本规范定义了 HPACK, 这是一种新的压缩器, 它可以消除冗余 header field, 限制对已知安全攻击的脆弱性, 并具有有界的内存需求, 适用于受限环境. HPACK 的潜在安全顾虑见 Section 7.

HPACK 格式有意保持简单且不灵活. 这两个特性都降低了因实现错误而产生互操作性问题或安全问题的风险. 本规范没有定义扩展机制; 只有通过定义完整替代方案, 才能更改该格式.

1.1. 概述

本规范定义的格式将 header field 列表视为 name-value pair 的有序集合, 其中可以包含重复的 pair. name 和 value 被视为不透明的 octet 序列, header field 的顺序在压缩和解压缩后保持不变.

编码由 header field table 提供依据, 这些表将 header field 映射到索引值. 随着新的 header field 被编码或解码, 这些 header field table 可以逐步更新.

在编码形式中, header field 要么按字面值表示, 要么表示为对某个 header field table 中 header field 的引用. 因此, header field 列表可以使用引用和字面值的混合方式进行编码.

字面值要么直接编码, 要么使用 static Huffman code 编码.

编码器负责决定将哪些 header field 作为新条目插入 header field table. 解码器执行编码器规定的 header field table 修改, 并在此过程中重构 header field 列表. 这使解码器能够保持简单, 并与多种编码器互操作.

Appendix C 提供了示例, 说明如何使用这些不同机制表示 header field.

1.2. 约定

本文档中的关键字 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 和 "OPTIONAL" 应按 RFC 2119 [RFC2119] 中的说明解释.

所有数值均采用网络字节序. 除非另有说明, 值均为无符号值. 字面值根据需要以十进制或十六进制给出.

1.3. 术语

本规范使用以下术语:

Header Field: 一个 name-value pair. name 和 value 都被视为不透明的 octet 序列.

Dynamic Table: dynamic table (见 Section 2.3.2) 是将已存储 header field 与索引值关联起来的表. 此表是动态的, 并且专属于某个编码或解码上下文.

Static Table: static table (见 Section 2.3.1) 是将频繁出现的 header field 与索引值静态关联起来的表. 此表有序, 只读, 始终可访问, 并且可以在所有编码或解码上下文之间共享.

Header List: header list 是一组共同编码的 header field 的有序集合, 可以包含重复的 header field. HTTP/2 header block 中包含的完整 header field 列表就是一个 header list.

Header Field Representation: header field 在编码形式中可以表示为字面值或索引 (见 Section 2.4).

Header Block: header field representation 的有序列表, 解码后会产生完整的 header list.

---