如何测试代理链路中的 gzip 与 Brotli 内容完整性

HTTP 响应返回 200 时，客户端、代理或运行时仍可能对压缩状态理解不一致。过期的 Content-Encoding、重复解压、流被截断或字节计量错误，会破坏采集数据并扭曲代理成本。只搜索一个正文标记的健康检查很容易漏掉这些问题。

本指南建立可复现的 gzip 与 Brotli 代理试用测试。只在自有或明确获准的终点运行。

区分线缆字节与解码正文

每个响应记录测试编号、路由别名、Accept-Encoding、Content-Encoding、长度头、线缆字节、解码字节、线缆摘要、解码摘要、流是否完整及失败阶段。

线缆摘要证明解压前收到什么，解码摘要证明是否还原原始夹具。高层客户端可能自动解压，并以不同方式保留或移除响应头，因此必须记录实际行为。测试使用已知摘要的合成载荷，不记录代理密码、Cookie、授权头或个人数据。

建立自有夹具

• 高度可压缩的 UTF-8 重复文本；
• 已压缩、几乎不会继续缩小的二进制；
• 在分块边界附近切开的多语言与表情字符；
• 大型流式响应；
• 空正文、204 与 HEAD；
• 故意截断的 gzip 和 Brotli 负向样本。

响应加入随机挑战，并通过另一个获准控制通道提供预期解码摘要，避免共享缓存混淆结果。

直连与代理矩阵

固定目标、载荷种子、请求头、超时与客户端版本。每格重复取样，区分确定性不匹配与瞬时传输失败。

步骤一：建立 identity 与直连对照

先请求 identity，验证解码摘要和长度；再直连请求 gzip 与 Brotli，确认二者都能精确还原同一原始夹具。直连失败时，不能用代理对比判断根因。

步骤二：逐条代理路由复测

通过每个购买网关和地区选择器重复请求，比较状态、编码头、线缆长度、解码长度与两层摘要。

结果分为：头部、流和摘要一致的通过；线缆表示变化但正文正确且头部同步的透明转换；声明与正文不符的头部错配；两层都尝试解压的重复解码；流未正常结束的截断；解码完成但摘要不同的内容损坏。

透明转换不一定是缺陷，但若违反产品承诺、破坏签名、改变计费或随路由漂移，就具有采购影响。

步骤三：覆盖分块与流边界

压缩问题常在响应头或多字节字符跨分块时出现。改变服务端分块大小并加入受控暂停，以增量方式读取，确认解码器报告正常结束。

长任务要分开设置空闲超时和总超时。部分解码文档不得标为完整记录。传输层通过后，可用代理响应完整性测试继续检查语义内容。

步骤四：排除缓存混淆

存在缓存时，要确认响应会正确随 Accept-Encoding 变化。不能把 gzip 对象以不兼容头部交给只接受 identity 的客户端。使用唯一挑战，并分开比较命中和未命中缓存的路径。

不得绕过第三方缓存控制，只测试自有夹具或明确获准环境。

公平测量带宽与成本

供应商和客户端可能报告不同字节层。每项指标都标明线缆、解码、请求、响应或总计。计算压缩比、完整有效流占比、有效解码字节/计费字节，以及每份有效文档成本。

结合代理带宽成本估算和每次成功请求成本评估。不能把一个供应商的解码字节与另一个供应商的线缆字节比较。

失败与重试策略

只有操作可安全重放时，才能重试截断或重置读取。设计不当的 GET 也可能触发副作用，应在自有终点验证。不得盲目重放 POST、注册、订单或消息。保留失败发生在响应头前、压缩正文读取、解码还是摘要验证之后。

上线检查清单

• identity、gzip、Brotli 直连对照通过；
• 线缆与解码摘要分开保存；
• 响应头符合实际正文表示；
• 多语言及分块边界夹具通过；
• 截断负向样本按预期失败；
• 部分文档不会被标记完整；
• 缓存变体尊重编码提供；
• IPv4、IPv6 与网关分别统计；
• 计费指标明确字节层；
• 日志不含凭据或用户数据。

常见问题

为什么 Content-Length 与解码正文长度不同？

它通常描述线缆上的编码表示，自动解压后正文可能更大，应明确记录两层。

Brotli 一定比 gzip 小吗？

不一定，取决于载荷、设置与是否已经压缩，应使用代表性夹具测量。

只用 JSON 解析器验证可以吗？

不可以。部分损坏内容仍可能解析，流也可能在完成前失败，必须验证正常结束和已知摘要。

是否应完全关闭压缩？

identity 是有用的诊断和回退，但会增加带宽与延迟。应先修复错配层并测量代价。

合规说明

使用合成或获准内容，遵守目标政策和速率限制，并最小化载荷留存。不得检查第三方私有流量或泄露凭据。压缩验证用于提高数据正确性，不得用于绕过访问控制。