压缩

HTTP/2 改变 HTTP 传输分帧和多路复用方式；gzip 与 Brotli 编码的是表示数据。启用 HTTP/2 不会自动压缩响应正文，启用 gzip 也不能证明客户端协商出了 HTTP/2。HTTP/2 的头部压缩又是另一种机制。可靠检查应分别记录协商协议、响应 Content-Encoding、传输正文字节数，以及实际解码后得到的内容，不能用其中一项代替其他结果。 坏掉的样子 发送 Accept-Encoding: gzip, br，然后把结果保存成 .br，并不能证明使用了 Brotli。服务器可能选择 gzip，也可能发送仍被请求接受的原始表示。真实编码由响应头说明。根据请求列表或输出文件名猜测，会导致使用错误解码器，也可能让报告声称获得了实际上根本没有发生的压缩结果。文件名只是本地命名，不是协议证据。 Brotli 支持还属于部署能力，并不是安装 nginx 后自然具备的功能。Brotli 过滤和预压缩文件处理由独立模块提供，需要针对实际二进制与配置确认可用性、构建兼容性。添加不受支持的指令可能让配置验证失败，而客户端声明接受 Brotli 不会替服务器安装功能。检查模块时，应以当前程序行为为准，不能从另一台机器的配置推断。 客户端自动解码会制造另一种测量陷阱。curl --compressed 收到较小编码正文后，可以保存成较大的解码文件。把这个文件大小与原始压缩输出比较，实际比较的是不同对象。反过来，只使用 --http2 却不检查协商结果，也可能把允许的协议回落误当成 HTTP/2 已经成功验证。命令选项表达请求意图，结果字段才说明本次发生了什么。 分别核对实际协议、编码与解码一致性。字节数来自历史文章报告，当前集成仍待验证。 快速验证 下文结果归属于历史文章报告，本轮没有重跑；保留的验证文件中未找到原始集成运行日志。运行需备好本地固定镜像并启用 Python 断言；清理仅尽力执行，不能据此保证所有资源已删除。 ...

gzip 是响应内容编码：nginx 可以发送压缩表示，由接受该编码的客户端解码。启用它需要 gzip on；gzip_types 扩展有资格压缩的 MIME 类型，却不会单独激活压缩。最终结果取决于响应、请求方能力和实际生效配置。只有压缩后仍能正确还原目标内容，较小正文才有价值，不能把“传输字节变少”与“功能已经正确”直接画等号。 坏掉的样子 在 gzip off 下列出 MIME 类型，不会让响应变成 gzip。另一个常见遗漏是 gzip_vary on。nginx 并不会仅因为发生压缩，就无条件添加 Vary: Accept-Encoding；该行为受对应指令控制。共享缓存需要知道哪些请求头维度影响表示选择，否则不同解码能力的客户端可能拿到不合适的已存响应。压缩成功和缓存选择正确是两个需要分别检查的结果。 最小长度设置的契约比名称暗示的更窄。gzip_min_length 根据响应 Content-Length 字段确定长度，不一定知道未指定长度响应的最终大小。因此，一个很短的动态流式响应仍可能被压缩，而同样短的静态文件会因为已知长度低于阈值而跳过压缩。不能从阈值配置推断所有小响应都不会进入压缩路径。 测量方法也可能误导。解压后输出文件的大小，不是压缩传输正文大小；压缩正文字节也不包含全部 HTTP 分帧、响应头和 TLS 流量。.gz 等文件扩展名本身不能证明实际编码。解释任何表面上的带宽节省之前，都应检查真实 Content-Encoding，并解码核对字节，否则可能只是把两种不同计量对象放在一起比较。 解码后应还原同一份字节。 依据原文与明确限制静态绘制；未为本图重跑原文夹具。 快速验证 下文集成实验的结果保留自历史运行记录；本次修订没有重新执行该实验，不能将这些记录当成本次环境的新实测。 ...

HTTP 压缩选择的是施加了内容编码的表示，不是一种新的媒体类型。经过 gzip 的文本，解压后仍然是文本。因此有效验证需要回答三个问题：编码是否可接受、传输内容是否变小、解码后是否恢复了原本要提供的字节。配置里勾选了压缩，或者接口返回成功状态，都不能同时证明这三件事。 分别检查编码可接受性、传输内容字节与解码后字节一致性。已记录的排除条件失败仍然是失败。 区分缺失、排除与偏好 根据 RFC 9110，Accept-Encoding 缺失时，任何内容编码都被认为可接受；显式空值则表示不希望使用内容编码。identity 代表没有内容编码，通常默认可接受，除非被 identity;q=0 或适用的 *;q=0 排除。通配符还可以让没有逐个列出的编码成为可接受候选，因此“只能发送客户端单独点名的编码”并不是完整规则。 ...