什么是 Gzip 压缩？HTTP gzip 如何工作

什么是 Gzip 压缩？

Gzip 压缩是一种无损格式，将 DEFLATE 压缩的数据与包含元数据和完整性检查的 gzip 包装器结合在一起。在 HTTP 中，gzip 是一种内容编码：客户端通过接受编码广告支持，服务器通过内容编码：gzip 确定压缩表示，接收者在解释原始媒体类型之前解码字节。

有用的定义包括机制及其边界。Gzip 压缩影响交换的特定部分，而相邻的责任仍在于 HTTP、浏览器、选定的传输、应用程序或服务器的数据模型。保持这些层分开，使错误报告可重复，并防止配置更改被误认为是访问控制决策。

对于 API 开发者，第一个问题是是谁创建了这个值或行为。下一个问题是谁来解释它。最后一个问题是什么可观察的结果证明解释工作成功。这三个答案将一个术语转化为一个可测试的接口合同。

从普通表示到 gzip 字节

来源始于例如 HTML、JSON、CSS 或 JavaScript 的表示。压缩器找到重复的字节序列并通过 DEFLATE 方法对其进行编码，然后 gzip 包装器记录格式信息和校验和。解压缩会精确重建原始字节。

客户端发送带有其可以解码的编码的接受编码。当可用且合适时，服务器或中介选择 gzip，添加内容编码：gzip，并发送编码的表示。内容类型仍然描述原始媒体类型，而不是压缩格式。

内容长度（如果存在）描述编码消息的长度。库和浏览器通常自动解码内容，这意味着应用代码可以接收纯文本，即使网络工具显示 gzip 响应。原始字节调试必须考虑到客户端行为。

压缩在重复文本中最有用。已经包含密集压缩的格式，例如许多图像、归档和视频格式，经过另一个编码步骤后收益很小，甚至可能变得更大。

Gzip 和 HTTP 层

以下术语将通常合并为一个标签的组件分开。将它们视为参与者之间的接口，而不是网络跟踪中的装饰。

为什么 Gzip 压缩在网络数据收集中很重要

Gzip 压缩可以改变到达的字节、如何解释这些字节或浏览器代码是否可能观察到结果。收集工作流应在更换工具之前定位该效果。记录请求的 URL、最终 URL、响应状态、表示类型、相关协议字段和一个预期的内容标记。该紧凑记录将正确的页面与访问消息、同意屏幕、重定向目标、空的应用程序外壳或不兼容的编码区分开。

直接 HTTP 是当所需数据存在于开放的服务器呈现响应中的最简单获取路径。当经过批准的内容依赖于 JavaScript 执行、浏览器管理的状态、导航或浏览器安全策略时，浏览器变得相关。这两条路径不应强制看起来相同：浏览器根据平台规则管理 cookies、压缩、重定向、CORS 和存储，而直接客户端则暴露出不同的默认设置。

会话连续性在每当一个响应为下一个请求建立状态时都很重要。保持授权的序列在一个有界客户端上下文内，维护所需的地区和网络来源，并避免从无关工作的状态中混淆。代理更改网络来源；它不会复制头部、解码表示、执行脚本或授予对受限内容的访问。

解析仅在表示验证后开始。在提取字段之前确认最终主机、规范身份（如果可用）、媒体类型、解码状态和所需的业务标记。此顺序防止解析器将错误文档转换为看起来技术上成功的空记录。

中介值得明确关注。内容交付网络可以选择编码变体，网关可以回答OPTIONS，缓存可以重用协商的响应，应用服务器可以设置cookie或授权字段。仅比较应用代码与最终页面输出跳过了可能做出决策的层。

无刮擦通用抓取API在团队需要管理允许的公共内容检索时相关，包括JavaScript呈现的页面。收购合同仍应定义目标、允许字段、预期表示、接受标记和停止条件。产品能力不能替代源条款、隐私审查或应用级验证。

通常受益于gzip的内容

当Gzip压缩改变具体的产品行为、兼容性要求或诊断决策时，它在架构中占有一席之地。这些用例首先描述工作，再描述协议特性。

gzip、deflate、Brotli和归档文件

Gzip压缩属于HTTP的一层，不应与相邻层混淆。一个合理的实现识别哪个组件选择值，哪个组件可以更改它，以及什么证据证明最终表示是正确的。

仅当它保持层边界时，比较才有价值。两个机制可以共存于一个请求中，替换一个并不自动替换另一个。以输入、可观察输出、失败状态和所有权来记录所选行为。

gzip部署和解析错误

• 压缩已经压缩的媒体。 额外的工作可能产生微不足道的节省或更大的结果。
• 忘记内容编码。 接收者无法知道原始字节需要gzip解码。
• 更改字节但保持旧长度。 Content-Length必须描述实际发送的编码表示。
• 为每个客户缓存一个变体。 变更和缓存键应区分接受编码选择。
• 解码两次。 许多 HTTP 库会自动解码，因此第二个应用步骤在已经是明文字节的情况下失败。
• 将 gzip 与 ZIP 混淆。 gzip 代表一个压缩数据流，而 ZIP 是具有不同结构的归档容器。

在去除关于库或浏览器自动操作的假设后，大多数故障变得更容易诊断。捕获一个最小的追踪，删除机密信息，并逐次改变一个可控变量。目标是对返回的表现提供一个稳定的解释，而不是一系列不相关的头部调整。

一个 gzip 响应检查

这个序列在发布前作为设计审查以及在行为变化后作为生产诊断。它使得协议证据与应用结果保持关联。

1. 发送一个具有控制的接受编码值的请求并记录最终响应。
2. 在读取原始字节之前检查内容编码，在解析解码字节之前检查内容类型。
3. 确定客户端是否自动解码响应并调整暴露的字段。
4. 将编码的传输大小与代表性内容的身份表示进行比较。
5. 检查变更和 CDN 缓存键以便编码变体与接收者保持兼容。
6. 跳过已压缩的类型，除非测量显示出真正的收益。
7. 用预期的标题、架构或内容标记而不是仅仅大小来验证解码后的主体。

通过保存一个小的接受样本和一个被拒绝样本，并使用相同的删除规则来结束审查。未来的更改可以与已知页面身份、预期字段和解码内容进行比较，而不是仅仅依赖记忆或屏幕截图。

Gzip 压缩的安全性和可观察性

Gzip 压缩参与一个请求路径，这个路径可以穿越浏览器、网关、缓存和源服务器。每个跳跃应该仅接受它理解的值，保留必须存活的字段，并避免将凭证或个人数据复制到日志中。协议语法不是授权。

操作记录应捕获请求的 URL、最终 URL、状态、表现类型、相关字段名称和一个界定的内容标记。完整的主体和凭证值在常规诊断中很少需要，可能会造成不必要的保留风险。

浏览器行为与直接 HTTP 行为是不同的测试表面。CORS、cookie 存储、自动解压和重定向处理可能由浏览器或库在应用代码看到结果之前执行。在比较捕获结果时记录客户端及其默认设置。

定义 Gzip 压缩的标准

gzip 格式规范 定义无损的 gzip 数据格式。这个主要来源修正了本文中使用的词汇和边界，而实现行为仍需要在所选择的客户端和部署中观察。

DEFLATE 规范 定义压缩方法，在 gzip 内部使用。这个主要来源修正了本文中使用的词汇和边界，而实现行为仍需要在所选择的客户端和部署中观察。

HTTP 内容编码语义 定义 gzip 作为 HTTP 内容编码。这个主要来源修正了本文中使用的词汇和边界，而实现行为仍需要在所选择的客户端和部署中观察。

MDN 的 Content-Encoding 参考 显示协商和解码字段。这个主要来源修正了本文中使用的词汇和边界，而实现行为仍需要在所选择的客户端和部署中观察。

gzip 实现规则

明确协商 gzip，正确标记编码的表现，保持缓存对变体的意识，测量实际内容而不是习惯性地压缩每种媒体类型。

将该规则放入一个接受测试中。说明哪个参与者发送信号，哪个参与者解释它，哪个中介可以改变路径，以及哪个内容标记证明成功。这使得 Gzip 压缩成为一个可观察系统的一部分，而不是一个在失败之后附加的标签。

参考文献

• 无损通用抓取API文档
• 无损通用抓取API产品概述
• 无损关于头部、Cookie、会话和表示验证的指南
• 无损在GitHub上