Cloudflare 共享字典压缩：一行代码改动，不再触发全量重下载

网页越来越重部署越来越频繁传统压缩却对冗余数据束手无策。共享字典压缩给压缩算法装上了记忆让它终于能看见客户端已经缓存了什么。一、一个持续恶化的问题过去十年网页体积每年增长 6–9%由框架化、交互化和媒体富化共同驱动这一趋势没有任何放缓迹象。真正在变化的是页面重建的频率和请求页面的客户端数量——两者都因 AI Agent 的崛起而急剧攀升。2026 年 3 月Agentic 爬虫在 Cloudflare 全网请求中占比接近 10%同比增长约 60%。Agent 不只是在消费网络也在帮助构建网络。AI 辅助开发意味着团队交付更快部署更频繁——这对产品迭代速度是好事对缓存却是灾难。二、越部署越浪费当 Agent 推送一行修复时打包工具重新分块文件名随之改变全球每个用户都可能重新下载整个应用。不是因为代码有实质性不同而是浏览器没有办法知道具体改变了什么——它看到一个新 URL从零开始。传统压缩能缩小每次下载的体积但对冗余无能为力。它不知道客户端已经缓存了 95% 的文件内容。每次部署对每个用户对每个爬虫都在重复发送冗余字节。一天发布十次小改动你实际上已经选择退出缓存机制。这在硬件正在成为瓶颈的今天既浪费带宽又消耗 CPU。压缩必须变得更聪明才能跟上这个世界的节奏。三、什么是共享字典压缩字典压缩的基本逻辑压缩字典是服务端和客户端之间的一份共享参考类似于备忘单。服务端不从零开始压缩响应而是说这部分文件你之前缓存过你已经知道了只发送新增的内容。客户端持有同一份参考用它在解压时还原完整响应。字典能引用的文件内容越多传输给客户端的压缩输出就越小。现代主流压缩算法对字典的支持各有侧重Brotli 内置了包含常见 HTML 属性和常用词组的静态字典Zstandard 专为自定义字典设计可以输入代表性内容样本来生成针对特定内容类型的优化字典Gzip 两者都没有只能在实时压缩过程中动态寻找规律。增量压缩把旧版本变成字典共享字典将这一原理推进了一步之前缓存的资源版本本身就成了字典。还记得那个团队推送一行修复所有用户重下载完整包的问题吗有了共享字典浏览器已经缓存了旧版本。服务端以旧版本为字典对新版本进行压缩只发送差异部分。一个有一行改动的 500KB 包在网络上只需传输几 KB。以每天 10 万用户、10 次部署计算这是 500GB 传输量与几百 MB 之间的差距。协议握手机制协议流程是这样的服务端首次提供资源时附上Use-As-Dictionary响应头告知浏览器保留这个文件供后续使用。下次请求同一资源时浏览器发回Available-Dictionary头告诉服务端我有这个版本。服务端随即将新版本与旧版本做差异压缩只发送 diff。不需要单独的字典文件。这种收益是累积的版本 3 对版本 2 做差异版本 47 对版本 46 做差异节省效果不会重置贯穿整个发布历史。四、这个想法为什么沉寂了将近 20 年如果共享字典如此强大为什么没有普及因为上一次尝试时实现方案无法经受开放网络的考验。Google 2008 年的 SDCH 实验Google 在 2008 年就在 Chrome 中发布了 SDCHHTTP 共享字典压缩。它在早期用户中取得了不错的效果部分人报告页面加载时间改善了两位数百分比。但问题积累的速度超过了修复速度。压缩侧信道攻击最著名的问题是一类压缩侧信道攻击CRIME、BREACH。研究人员证明如果攻击者能在与敏感内容如 Session Cookie一同压缩的数据中注入内容压缩输出的大小就会泄露关于这个秘密的信息。攻击者可以每次猜一个字节观察资产体积是否缩小不断重复直到提取出完整的秘密。架构层面的根本矛盾安全问题并非唯一症结。SDCH 暴露了若干架构问题比如违反同源策略——而这恰恰是它性能表现出色的部分原因。它的跨域字典模型无法与 CORS 调和且在与 Cache API 等机制的交互上缺乏清晰规范。2017 年唯一支持它的浏览器 Chrome 将其下线。RFC 9842现代标准如何修复这些问题让网络社区重新拾起这个想法花了整整十年但这等待是值得的。现代标准 RFC 9842压缩字典传输弥合了使 SDCH 无法为继的关键设计缺口。例如它强制规定广播出来的字典只能用于同源响应从而消除了许多使压缩侧信道攻击成为可能的条件。Chrome 和 Edge 已经发布了支持Firefox 也在跟进中。标准正在走向广泛采用但完整的跨浏览器支持仍在追赶中。五、Cloudflare 的三阶段落地计划共享字典压缩涉及浏览器到源站之间栈的每一层。RFC 标准虽然修复了安全问题但字典传输的实现复杂度始终没有降低源站可能需要生成字典、用正确的 Header 提供字典、检查每个请求是否有Available-Dictionary匹配、对响应做实时增量压缩并在客户端没有字典时优雅降级。缓存也变得复杂——响应要同时按编码方式和字典哈希做变体缓存每个字典版本都会产生独立的缓存副本。这种复杂度是一个协调问题恰恰适合交给边缘层来解决。阶段一透传支持源站自管字典Cloudflare 透传共享字典所需的 Header 和编码Use-As-Dictionary、Available-Dictionary以及dcb和dcz内容编码不做剥离、修改或再压缩。缓存键扩展为按Available-Dictionary和Accept-Encoding做变体确保字典压缩的响应被正确缓存。这一阶段服务于在源站自行管理字典的用户。开放 Beta 时间2026 年 4 月 30 日。使用条件Cloudflare Zone 已开启该特性、源站以正确 Header 提供字典压缩响应、访客使用 Chrome 130 或 Edge 130。阶段二边缘托管字典源站零感知Cloudflare 开始替你完成这些工作。你通过规则告知 Cloudflare 哪些资产应当用作字典剩下的由 Cloudflare 全权处理注入Use-As-DictionaryHeader、存储字典字节、对新版本相对旧版本做增量压缩并向每个客户端提供正确的变体。你的源站只需提供普通响应所有字典复杂度都转移到边缘。阶段三全自动字典生成无需任何配置字典由 Cloudflare 自动为网站生成不需要用户指定哪些资产应当用作字典。Cloudflare 的网络已经观察到流经它的每个资源的每个版本覆盖数百万个站点、数十亿次请求和每一次新部署。当网络发现某个 URL 模式中连续响应共享绝大多数内容、仅哈希值不同时就有强烈信号表明这是版本化资源可以进行增量压缩。它存储前一版本作为字典并对后续版本进行差异压缩。零配置零维护。这是整个计划最有价值的部分——让数百万个没有工程资源手动实现自定义字典的站点也能获得这项能力。六、真实测试数据压缩率对比在内部测试中Cloudflare 依次部署了两个 JS 包它们几乎相同仅有少量局部改动。未压缩时资产大小为 272KBGzip 压缩后降至 92.1KB压缩率 66%。使用以前一版本为字典的 DCZ 共享字典压缩后同一资产降至 2.6KB——相比已经压缩过的结果再减少 97%。下载时间对比在客户端两个关键时间点的测量中首字节时间TTFB方面缓存未命中时 DCZ 仅比 Gzip 慢约 20ms开销几乎可以忽略不计。下载完成时间才是差距所在缓存未命中时DCZ 为 31msGzip 为 166ms改善 81%缓存命中时DCZ 为 16msGzip 为 143ms改善 89%。响应体积小到即便起步略慢完成时也远远领先。演示站点数据Cloudflare 构建了一个演示站点 canicompress.com每分钟部署一个约 94KB 的新 JS 包来模拟典型生产单页应用。每次部署只有一小段配置块发生变化其余代码完全相同。结果94KB 压缩至约 159 字节比 Gzip 减少 99.5%——因为网络上传输的只有实际差异。七、更大的背景压缩需要有记忆在互联网历史的大部分时间里压缩是无状态的——每个响应都被压缩仿佛客户端从未见过任何东西。共享字典改变了这一点它给压缩装上了记忆。这在今天比五年前更重要。Agentic 编程工具正在压缩部署间隔同时也在驱动越来越大份额的流量来消费这些部署。随着 Agent 获得更多上下文、对代码改动越来越精准加之更频繁的发布和更多的自动化客户端每次请求的冗余字节在不断累积。增量压缩从两个维度同时提供帮助减少每次传输的字节数以及减少需要发生的传输次数。八、总结共享字典压缩的核心思想其实很朴素浏览器已经有了旧版本服务端只需要发送变了什么。这个想法在 2008 年就被尝试过被安全漏洞和架构缺陷打下去又花了将近二十年才在 RFC 9842 中以正确的方式重新站起来。Cloudflare 的三阶段计划从透传到托管再到全自动本质上是在把这项需要相当工程投入才能用好的技术变成一个对开发者几乎透明的基础设施能力。Phase 1 Beta 已于2026 年 4 月 30 日开放关注 Cloudflare Changelog 即可获取最新进展。原文链接https://blog.cloudflare.com/shared-dictionaries/