什么是Brotli？br压缩如何在网络上工作

什么是Brotli？

Brotli是一种无损压缩数据格式，它结合了LZ77风格的回引用、霍夫曼编码和一个预定义字典，旨在有效表示常见数据模式。在HTTP中，它通过br内容编码令牌进行识别。客户端在Accept-Encoding中宣传br，而选择它的服务器返回Content-Encoding：br。

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

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

Brotli如何生成和交付br内容

编码器将输入分为元块，并表示字节文字加上对重复序列的引用。上下文建模和前缀码降低了常见模式的成本，而静态字典可以紧凑地表示熟悉的单词和片段。解码则反转这些命令以恢复原始字节。

HTTP协商与压缩算法是分开的。客户端在受支持的编码中列出br，而服务器或边缘选择预压缩或动态编码的变体。响应保持其原始Content-Type，并添加Content-Encoding：br。

静态资产可以在构建过程中进行压缩，因此请求时的工作量较低。动态响应可以在生成时进行编码，但压缩级别、响应大小和服务器容量需要测量。如果编码延迟主导请求预算，则较小的表示并不实用。

浏览器和现代HTTP库通常会自动解码br。网络面板可以显示编码的传输大小，而应用程序代码看到解码的文本。原始收集工具必须请求身份或在解析之前支持Brotli解码。

对于HTTP重要的Brotli概念

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

为什么Brotli在Web数据收集中重要

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

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

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

解析仅在表示验证之后开始。在提取字段之前确认最终主机、可用的规范身份、媒体类型、解码状态和所需的商业标记。这一顺序防止解析器将错误文档变成看似成功的空记录。

中介需要明确的关注。内容分发网络可以选择编码变体，网关可以回答OPTIONS，请求，缓存可以重用协商后的响应，应用服务器可以设置cookie或授权字段。只比较应用代码与最终页面输出会跳过可能做出决定的层。

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

Brotli常见的应用

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

Web交付中的Brotli和gzip

Brotli属于HTTP的一个层，不能与相邻层混淆。良好的实现识别选择值的组件，能够改变它的组件，以及什么证据可以证明最终表示是正确的。

只有在保留层边界时比较才有意义。两种机制可以共存于一个请求中，替换一个并不会自动替换另一个。在输入、可观察输出、失败状态和所有权方面记录所选的行为。

Brotli部署错误

• 在没有Content-Encoding的情况下提供br。 接收者会将压缩字节视为原始媒体类型，解析将失败。
• 将br发送到不支持的客户端。 选择必须遵循Accept-Encoding并提供兼容的回退。
• 对每个动态主体使用最大工作量。 更高的编码器工作量可能会增加延迟和CPU成本，而几乎没有实际的大小增益。
• 忽视缓存变化。 对于仅声明 gzip 或 identity 的客户端，不可重复使用 br 响应。
• 压缩密集的二进制格式。 已经压缩的图像、档案和视频通常从另一种编码中获得的收益很小。
• 解码已经解码的库响应。 客户端默认值可以隐藏应用程序代码中的内容编码，因此请分别检查原始和暴露的层。

在消除关于库或浏览器自动执行的假设后，大多数故障更容易诊断。捕获最小的追踪，遮蔽秘密，并逐步改变一个可控变量。目标是对返回表示的稳定解释，而不是一系列无关的头部调整。

Brotli 发布和验证计划

该顺序在启动前作为设计审查，并在行为变化后作为生产诊断。它将协议证据与应用程序结果保持关联。

1. 在选择编码器设置之前，测量代表性的 HTML、CSS、JavaScript、JSON 和 SVG 资产。
2. 预压缩稳定资产，并将动态压缩设置保持在服务器的延迟和 CPU 预算内。
3. 通过 Accept-Encoding 进行协商并保留 gzip 或 identity 后备。
4. 返回 Content-Encoding: br 并保留原始 Content-Type。
5. 设置 Vary 并确认 CDN 缓存密钥区分 br、gzip 和 identity 变体。
6. 测试一个浏览器、一个现代 HTTP 库和一个原始客户端，以揭示自动解码差异。
7. 验证解码内容并比较端到端延迟，而不仅仅是压缩字节数。

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

Brotli 的安全性和可观察性

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

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

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

定义 Brotli 的标准

Brotli 压缩数据规范 定义无损格式和解码器。这个主要来源修正了本文中使用的词汇和边界，同时实施行为仍需在选定的客户端和部署中观察。

HTTP 内容编码语义 定义表示编码和协商。这个主要来源修正了本文中使用的词汇和边界，同时实施行为仍需在选定的客户端和部署中观察。

MDN 的 Content-Encoding 参考 记录了 HTTP 响应中的 br 令牌。这个主要来源修正了本文中使用的词汇和边界，同时实施行为仍需在选定的客户端和部署中观察。

官方 Brotli 实现 提供编码器和解码器的源代码。这个主要来源修正了本文中使用的词汇和边界，同时实施行为仍需在选定的客户端和部署中观察。

Brotli 部署规则

使用 Brotli 作为协商的表示编码，保留 gzip 或 identity 后备，并根据测量的端到端结果选择编码器工作，而不是最小的隔离文件。

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

参考文献

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