HTTP/2 通过头部压缩算法 HPACK 有效解决了 HTTP/1.x 时代重复头部冗余传输的问题。在反向代理架构中，Nginx 作为中间节点，往往需要以 HTTP/2 协议向后端应用服务器回源，此时 Nginx 自身就是一个 HTTP/2 客户端，负责与上游服务器协商并维护 HPACK 动态表。但动态表的状态通常只存在于连接的内存中，一旦遇到回源超时、头部大小不匹配或压缩效率低下等问题，仅靠 Nginx 默认的访问日志很难定位根因。RFC 9570 正是为此而生，它从日志记录的角度给出了 HPACK 动态表事件的标准化描述。本文将围绕 Nginx 回源场景，深入解析 HPACK 动态表的工作方式，并结合 RFC 9570 探讨如何让压缩过程变得可观测。
HTTP/2 回源的基本逻辑与 HPACK 动态表
Nginx 本身支持对后端服务器发起 HTTP/2 连接，只需在配置中指定 proxy_http_version 2.0 即可。但这一行为的底层细节远比表面上复杂。当 Nginx 以 HTTP/2 协议向上游发送请求时，它实际上扮演了客户端角色，会与上游服务器完成 HTTP/2 连接前言、SETTINGS 帧交换，并基于 SETTINGS_HEADER_TABLE_SIZE 参数协商双方动态表的最大容量。HPACK 动态表采用先入先出（FIFO）的淘汰策略，任何一方都可以在连接期间通过 SETTINGS 帧动态调整表的大小，也可以发送带有动态表大小更新指令的头部块来主动回收空间。
回源场景的独特之处在于，每一个 TCP 连接上可能承载多个并发的 HTTP/2 流，所有流共享同一个动态表。这意味着从 Nginx 发出的第一条请求头部会影响后续请求的压缩效果。例如，第一个请求中包含了自定义的统一头字段，这些字段会被编码并可能被加入动态表；当第二个请求携带相同的字段时，只需要发送一个小整数索引引用即可完成传输，省去了几十甚至上百字节的重复数据。但如果上游服务器主动缩小动态表，导致已经被引用的条目被淘汰，那么接下来的引用就会失败，Nginx 必须重新编码该头部。这种压缩效率的波动在日志中很难体现，因为日志记录的通常是解压后的完整头部，无法反映当时动态表的真实状态。
一个常见的配置示例如下，它开启了 Nginx 对上游的 HTTP/2 回源，并通过 proxy_set_header 主动传递一些头部信息，这些信息都会被 HPACK 压缩处理：
location /api/ {
proxy_http_version 2.0;
proxy_pass https://backend;
proxy_set_header X-Request-ID $request_id;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Custom-Trace $http_x_custom_trace;
}
这段配置中，X-Request-ID 等头部在多个请求间可能保持不变，非常适合被 HPACK 动态表缓存。但要想量化实际节省了多少字节、动态表被更新了多少次，就必须深入 HPACK 的编码细节，这正是 RFC 9570 的切入点。
HPACK 动态表在回源连接中的几个隐蔽问题
HPACK 动态表并非总是按开发者的预期高效运行。一个典型的问题是“表大小不匹配”。Nginx 向上游发送的 SETTINGS_HEADER_TABLE_SIZE 默认为 4096 字节，上游服务器可能返回不同的值，比如 2048 或 8192。根据 HPACK 规范，双方必须采用较小的那个值作为实际表大小上限。这种协商过程对上下游透明，但一旦上游服务器在连接中途主动发送 SETTINGS 帧将表大小降为 0（清空动态表），Nginx 当前正在压缩或即将发送的请求头部就会受到影响，压缩率瞬间跌到静态表水平，甚至引发 REFUSED_STREAM 错误。
第二个问题与 Nginx 的 keepalive 连接复用机制有关。当使用 keepalive 配置指定连接池大小后，Nginx 会在不同请求间复用与上游的 HTTP/2 连接。此时动态表中可能已经积累了大量针对某一类请求的头部，而新的请求横跨不同的虚拟主机或应用，携带完全不同的头部集合，导致动态表被迅速占满，原有高命中率的条目被逐出，压缩效率反而下降。这种“缓存污染”效应很难在未开启详细日志的情况下发觉，因为从总请求延迟或带宽曲线上看，它仅表现为偶发性的头部开销增长，很容易被埋没在整体统计中。
第三个问题在于日志可见性。Nginx 通过 $upstream_http_* 变量可以获取上游返回的响应头部，但这些都是解压后的明文，完全丢失了 HPACK 编码过程的信息。对于请求方向，Nginx 更没有提供原生变量来记录某一条头部在 HPACK 压缩后的大小或它是否被动态表命中。当怀疑压缩效率问题时，工程师只能借助 tcpdump 或 Wireshark 抓取加密前的 TLS 明文（需要解密），然后手动分析 HPACK 编码字节流，这无疑拉长了排障链路。RFC 9570 的目标就是让这些信息可以直接从日志中提取，无需侵入式抓包。
RFC 9570 定义的 HPACK 动态表日志格式
RFC 9570 是一个信息型 RFC，它并不改变 HTTP/2 或 HPACK 协议本身，而是提出了一种标准化的日志事件格式，用于记录 HPACK 编码器和解码器在动态表上的操作。它定义了三类主要事件：表大小更新（Table Size Update）、动态表条目添加（Entry Added）以及动态表条目淘汰（Entry Evicted）。每一个日志事件都包含时间戳、连接标识、流标识以及具体的表更新参数，能够让分析工具精确重现整个连接生命周期内的动态表状态变化。
以“Entry Added”事件为例，日志中会记录被添加的头部名字和值的哈希值（出于隐私安全考虑，不直接记录明文内容，以避免日志泄露敏感信息）、该条目在动态表中的索引、条目所占用的字节数以及添加操作后动态表的总大小。这些信息足以回答“某个头部是否在动态表中被缓存”“动态表何时达到容量上限”“淘汰策略是如何执行的”等关键问题。对于“Table Size Update”事件，则会记录新的大小上限以及本次变更触发淘汰的条目数量，直接反映了协商调整对压缩效率的影响程度。
虽然 RFC 9570 定义的是客户端和服务器两端均可采用的日志格式，但在 Nginx 回源的应用中，Nginx 端的 HPACK 编码器是实现该日志的理想位置。目前主流 Nginx 软件包尚未原生集成 RFC 9570 日志输出，但这一规范为第三方模块或补丁提供了明确的实现参考。例如，可以在 Nginx 的 HTTP/2 处理流程中嵌入回调，每当动态表发生变更时，生成符合 RFC 9570 的 JSON 格式日志并写入独立的日志文件，供后续 ELK 或 Prometheus 采集。以下是一个潜在的可自定义的日志格式设想：
{
"timestamp": 1716500000.123,
"connection_id": "0x7fc400a8b0",
"stream_id": 1,
"event_type": "entry_added",
"name_hash": "a1b2c3d4e5",
"value_hash": "f6e7d8c9b0",
"index": 62,
"entry_size": 47,
"table_size": 1024
}
借助这样的日志，工程师可以快速定位某个请求流的头部压缩行为：例如，当 table_size 频繁达到上限并触发淘汰时，说明当前动态表容量可能偏小，可通过增大 SETTINGS_HEADER_TABLE_SIZE 或调整上游服务器配置来提升缓存命中率。同时，也能检测到上游服务器意外清空动态表的操作（即收到 Table Size Update 事件且大小为 0），及时排查对端行为异常的原因。
在 Nginx 环境下增强 HPACK 动态表可观测性的实践
即便没有完整的 RFC 9570 实现，我们也可以利用现有工具和 Nginx 的灵活日志机制来逼近同样的效果。一种折中方案是在 Nginx 日志中记录上游连接是否使用了 HTTP/2，并采集每次回源请求的总体头部大小。尽管这不能追溯到单条头部，但可以帮助建立基线。例如，使用 $upstream_http_vary、$sent_http_content_type 等变量辅助推断响应头压缩情况，通过 Lua 模块（如 OpenResty）获取请求头部原始大小并与压缩后大小对比，但前提是能够拿到原始流数据，这一点依然需要模块支持。
更实际的途径是对回源流量进行采样抓包，并结合 Wireshark 内置的 HPACK 解析器进行分析。Wireshark 在解密 TLS 流量后，能够直接展示 HPACK 编码的每个头部块，标注出哪些是索引引用、哪些是字面量编码，甚至单独列出动态表操作。在问题排查阶段，针对特定连接导出 Flow Graph 或 IO Graph，观察表大小变化与压缩效率的波动趋势，能够快速验证优化效果。虽然不是实时日志，但可以作为 RFC 9570 理念的临时替代。配合 tcpdump 的循环抓包和过滤规则，可以在不影响性能的前提下保留关键样本。
对于追求极致控制力的场景，可以考虑在 Nginx 上应用社区补丁或使用支持动态表日志的 HTTP/2 库（如 nghttp2）构建测试环境。在生产集群中，也可以通过 Envoy、Traefik 等现代代理替换部分回源链路，这些代理普遍内置了更丰富的 HTTP/2 监控指标，包括直接暴露的 HPACK 压缩率指标，从而降低对 RFC 9570 日志格式的依赖。但回到 Nginx 本身，随着 RFC 9570 的逐步推广，未来有望在主分支或至少主流分支中看到实验性支持，届时只需开启一个指令即可将动态表事件注入到访问日志中，彻底打通压缩链路的最后一公里可观测空白。
HTTP/2_HPACKRFC9570Nginx修改时间：2026-08-12 15:19:25