一个常见的误解：开启HTTP/2就等于加速
先看关键判断
CDN HTTP看似简单，真正落地时却很容易踩坑。很多站长在接入CDN后，只要看到控制台里显示“HTTP/2已启用”，就觉得自己的网站已经享受到了新一代协议的红利。当他们用Chrome DevTools观察网络瀑布图时，却发现TTFB（首字节时间）依然高居不下，甚至偶尔出现连接重置或请求排队的情况。这时候很少有人会想到，问题可能出在HPACK——HTTP/2的头部压缩机制上。
HPACK的设计初衷非常优雅：通过静态表、动态表和Huffman编码，将一个典型HTTP请求头从几百字节压缩到几十字节。但在CDN边缘节点这种高并发、多租户的环境下，HPACK的动态表占用内存却可能失去控制，导致节点响应变慢、内存压力升高，最终拖累整站性能。本文的目标就是帮你彻底理解HPACK的内存模型，并给出可落地的调优思路。
相关阅读：此处可内链到“CDN HTTP常见问题”专题。
HPACK是什么？为什么必须压缩头部？与CDN HTTP
先看关键判断
在HTTP/1.1时代，每个请求都携带大量重复的文本头部，比如:method、:path、user-agent、cookie等。一次页面加载可能发起100个请求，光头部重复传输就要浪费几十KB的带宽。HTTP/2引入了二进制分帧和头部压缩（HPACK，RFC 7541），把重复的头部用索引代替，动态维护一个头部字段与索引的映射表。
HPACK的核心机制很简单：
- 静态表： 预定义了61个常用头部字段（如
:status: 200、content-type: text/html），双方共用，无需传输。 - 动态表： 用于存储会话中首次出现的自定义头部，后续相同头部直接引用索引。动态表的大小由双方协商（SETTINGS_HEADER_TABLE_SIZE），默认4KB。
- Huffman编码： 对不在表中的头部进行字符级压缩。
动态表是HPACK内存消耗的主要来源。当服务器或客户端收到新的头部字段时，会将其追加到动态表末尾。如果表大小超过约定限制，就会按LRU（最近最少使用）策略淘汰旧条目。
进阶阅读：此处可内链到“CDN HTTP性能优化”指南。
想继续深入：此处可内链到“CDN HTTP优化清单”文章。
CDN边缘节点的特殊性：高并发与多租户
我的处理经验
普通Web服务器的HPACK动态表是独立管理每个连接的。但CDN边缘节点同时维持数十万甚至数百万个HTTP/2连接，每个连接都有自己的动态表。这意味着：
- 内存放大： 如果每个连接的动态表都设置为4KB（默认值），100万个连接的理论内存占用约为3.8GB（考虑表结构开销）。实际中很多CDN厂商会调整默认值，但依然可能达到GB级别。
- 头部多样性： 不同网站的头部差异很大。比如一个使用大量自定义Cookie的电商站点，其动态表条目数可能远超默认表容量，导致频繁淘汰和重新索引，反而增加CPU开销。
- 连接复用影响： HTTP/2的多路复用会在一个连接上承载多个请求流。如果某个请求设置了一个新的头部，整个连接上的所有后续请求都能收益。但如果大量不同来源的请求（例如CDN回源请求）混合在同一连接上，动态表可能因局部性差而被污染。
这些因素导致HPACK内存调优在CDN场景下不是“一刀切”的配置，而需要根据业务流量特征做精细化调整。
核心调优参数：SETTINGS_HEADER_TABLE_SIZE与CDN HTTP
故障定位思路
HPACK规范允许服务器通过SETTINGS帧告知客户端自己愿意接收的最大动态表大小。这个值可以在连接建立时设置，也可以后续动态更新（但实际中很少变动）。
默认值4KB的由来： 这个值在2015年制定标准时被认为足够覆盖大多数典型场景——一个常见的请求头如user-agent + accept + cookie 大约1-2KB。但如今Web页面动辄带有几百字节的跟踪ID、一次性的JWT令牌、或者复杂的sec-fetch-*头，4KB很快被撑满。
增大表大小的收益与代价：
- 收益：减少头部传输量，降低延迟。尤其对长连接、频繁交换同一组头部的场景（如API网关）效果显著。
- 代价：每个连接的内存开销线性增长。在CDN节点上，如果设置为64KB，100万连接将额外消耗约60GB内存（理想计算）。实际中CDN节点通常只允许每个连接占用几KB到几十KB。
减小表大小的逻辑： 如果你的网站头部重复率极低（例如每个请求都会携带不同的JWT或签名），那么大表只会浪费内存而得不到压缩收益。此时可以将SETTINGS_HEADER_TABLE_SIZE设为0或很小的值（如256字节），强制客户端总是发送完整头部，从而节省内存。
实际调优策略：从监控到调整
第一步：量化当前的内存消耗
在CDN节点上，查看HPACK相关指标。Nginx的http2_max_requests和http2_max_concurrent_streams并不能直接反映内存。你可以通过以下方式间接估算：
- 使用
/proc/meminfo观察节点整体内存变化，对比开启HTTP/2前后的差值。 - 启用Nginx的$http2_connection_name变量日志，统计每个连接建立的频率。
- 借助第三方工具如h2load模拟并发连接，压测后检查内存峰值。
第二步：根据流量特征调整表大小
这里没有通用公式，但可以参考以下原则：
- 静态资源站点（图片、CSS/JS）： 请求头几乎相同，重复率高。可以适当增大表大小（如16KB），让所有头部都能被索引，减少HTTP/2数据帧中的头部块大小。注意，静态资源通常通过CDN加速，访问量大，连接复用率高，收益也高。
- 动态API接口（带Token、Session）： 头部变化频繁。建议保持默认4KB甚至降至2KB，避免动态表频繁淘汰造成CPU开销。同时检查是否可以通过合并Cookie或减少自定义头部来降低头部体积。
- 混合流量（普通网站）： 建议从8KB开始尝试，观察节点内存和CPU占用，结合响应时间进行调整。
第三步：验证并回滚
任何调优都必须有验证环节：
- 在非高峰期进行A/B测试：一组连接使用原配置，另一组使用新配置，对比TTFB、头部字节数（在Nginx日志中记录
$upstream_http_*）。 - 监控节点OOM Killer日志：如果节点内存使用率突增，立即回滚配置。
- 使用curl的
--http2并配合-v观察头部帧的大小变化。
容易被忽略的点：TLS与HPACK的交互
我的处理经验
HTTP/2强制使用TLS（实际环境中）。TLS握手阶段会协商ALPN，确认使用HTTP/2协议。但TLS层的内存（比如会话缓存、证书）也会与HPACK竞争节点内存。如果你同时开启了TLS 1.3的0-RTT，短时间内大量连接复用同一个会话缓存，此时SETTINGS帧的交换可能被优化掉，导致双方对表大小理解不一致。建议在CDN配置中明确指定http2_max_table_size（如Nginx的http2_header_table_size指令），确保一致性。
总结
实际操作要点
HPACK内存调优并非玄学，而是基于对头部重复模式的判断。作为CDN运维或站点所有者，你不需要深入HPACK编码细节，只需要记住三点：
- 默认4KB的表大小不一定适合你的场景，尤其是高并发、头部差异大的CDN环境。
- 调整SETTINGS_HEADER_TABLE_SIZE前，先评估头部重复率：重复高则增大，重复低则减小。
- 调优必须有监控和回滚机制，避免因内存不足导致节点崩溃。
最后，如果你的CDN提供商提供了HPACK相关的自适应调优功能（比如根据内存水位自动缩小表大小），开启它通常比手动调整更安全。毕竟，HPACK的初衷是减少带宽，而不是把节点内存吃光。后续只要定期检查关键指标，CDN HTTP就不会变成维护负担。
延伸阅读