RAM 和硬盘同时涨价，CDN 的账本变了
过去一年，RAM 与 HDD 价格同步暴涨。对 Cloudflare 这种在全球部署数百个 PoP 节点、缓存层占存储大头的公司来说，每 GB 磁盘成本的上升直接推高运营支出。传统做法是按源站给什么就存什么——源站没压缩，CDN 就存未压缩字节。
Cloudflare 的 1.1.1.1 Intern Program 实习生提出了另一种思路：既然磁盘变贵了，能不能在资产写入缓存前先用 zstd 压一遍？这个原型叫 Cache Transcoding，跑在 Cloudflare 自研的 Rust 代理框架 Pingora 里。初始测试结果：合格资产的磁盘体积平均缩至原来的 1/3。
需要强调：这是一个实习生的原型研究项目，不是 Cloudflare 已上线的产品功能。原文用的是「intern project」，压缩比数据来自刻意可压缩的测试语料。但原型验证的工程逻辑——磁盘比 CPU 贵之后，压缩应该从传输层搬进存储层——成立。
传输压缩和存储压缩差在哪里
我们日常接触的 gzip、Brotli 压缩发生在出站环节：服务器把响应体压缩后通过网络发给浏览器，省的是带宽。CDN 节点存储的仍然是未压缩（或源站原始编码）的字节。每次缓存命中，磁盘读出的都是原始体积。
Cache Transcoding 做法不同。资产首次填充（cache fill）时，Pingora 代理拦截响应，用 zstd 编码后再写盘。此后这份资产在缓存的整个生命周期内保持压缩态——包括通过 Tiered Cache 在上下层数据中心之间传输时。只在发给客户端前才解码。
一次编码成本换来两层收益：磁盘空间省了，数据中心之间的骨干带宽也省了。编码只在 cache fill 时付一次，而缓存资产的复用次数远高于填充次数——CDN 的核心价值就建立在高命中率上。
2.834 倍压缩比背后有限定条件
原型的受控语料测试给出了 2.834 倍的压缩比，两个具体测试资产（约 195 KiB 和 272 KiB）均达到约 2.8 倍。编码速度 4.31 ns/byte（约 232 MB/s），解码速度 1.56 ns/byte（约 641 MB/s），使用 zstd level 3。
下面这张表整理了原型的核心性能参数：
| 指标 | 数值 | 备注 |
|---|---|---|
| 受控语料压缩比 | 2.834x | 刻意可压缩文本，不代表全网平均水平 |
| 编码速度 | 232 MB/s（4.31 ns/byte） | 仅 cache fill 时付一次 |
| 解码速度 | 641 MB/s（1.56 ns/byte） | 每次 serve 都付 |
| zstd 级别 | level 3 | 默认均衡档，后续计划测试更高级别 |
| 合格资产最小阈值 | 4 KiB | 砍掉大量小请求，仅损失约 1% 合格字节 |
| 边缘代理额外 CPU 开销 | 几个百分点 | 模型估算，非生产环境实测 |
原文对数字的限定很明确：压缩比来自刻意可压缩的测试语料，「不代表互联网上每个文本对象」。大规模上线前需要更广泛语料验证。把原型数据直接等同于生产预期，是对这份工作的误读。
图：Cache Transcoding 架构示意，展示缓存命中/未命中及 Tiered Cache 下压缩对象的流转路径。来源：Cloudflare Blog
67% 请求是文本，但 71% 到达时没压缩
原型为什么只压文本？看流量结构就明白了。媒体类内容（图片、视频、字体）占请求量的 21.4%，却占字节量的 63.3%——JPEG、H.264、WOFF2 本身已是压缩格式，再压收益极低。可压缩文本（HTML、JSON、CSS、JS）占请求量 67.3%、字节量 22.3%，其中约 71% 到达 CDN 时没有 Content-Encoding 头。源站没压缩，CDN 照存原始字节，这是最大的浪费点。
4 KiB 的最小阈值筛选效率很高：砍掉了大量小文件请求，却只损失约 1% 的合格字节总量。压缩 4 KiB 以下的小文件，编解码开销与收益几乎打平，跳过更合理。
合格条件还包括 HTTP 200、Content-Length 已知、Content-Type 属于可压缩文本类型。原型排除了 slice 子请求、range 请求、源站主动压缩的响应、未知长度 body 和二进制内容。这些排除项界定了原型的适用边界。
图：Cloudflare Cache Transcoding 博客头图。来源：Cloudflare Blog
全量压比只压热门更划算
一个直觉上合理的方案是「只压热门内容」——高频资产压缩后省的磁盘读取最多。但原型的分析否定了这条路：解码发生在每次 serve，不管资产冷热都要付 CPU；限定只压热门省不了多少 CPU，却会放弃冷内容的存储收益。
全量压缩合格文本反而更优。逻辑很简单：磁盘单价涨幅超过 CPU 时，用几个百分点的额外 CPU 换回三分之二的磁盘空间，每个 PoP 节点都算得过来。模型估算显示，边缘代理额外 CPU 成本仅为「几个百分点」。
防重复编码的设计也到位。原型在存储层标记了编码状态，上层 tier 传下来的 zstd 对象，下层节点直接保留压缩态，不做重复编解码。验证阶段向 10 台缓存服务器发起超过 100 万请求，一半启用 Tiered Cache，一半关闭，通过请求日志、Prometheus 指标和 Jaeger trace 逐请求交叉验证。
zstd 选型有数据支撑
为什么选 zstd？Cloudflare 此前的浏览器压缩测试已有对比数据：zstd 比 Brotli 快 42%，压缩后体积几乎相同；与 gzip 同速度下，zstd 产出文件小 11.3%。641 MB/s 的解码吞吐量意味着每次 serve 解一遍，对现代 CPU 来说延迟增量在微秒级。
这解释了原型为什么敢把「每次 serve 都解码」当可接受的代价。zstd 解码够快，在当前硬件价格比下，CPU 周期比磁盘空间便宜得多。
原型验证了方向，离上线还有距离
Cache Transcoding 后续计划包括测试更高 zstd 级别、扩展内容类型与尺寸范围、处理 range 请求与源站预压缩场景，以及把压缩对象直接透传给已支持 zstd 的下游组件省掉一次解码。这些待办项说明原型距离生产部署还有工程距离。
但原型回答了最关键的问题：RAM 和 HDD 同时涨价时，把压缩从传输层搬进存储层，用「每次 fill 多付一次编码」换「此后每次 hit 都省磁盘和骨干带宽」，账算得过来。CDN 缓存系统的成本模型正在从「磁盘便宜、省 CPU」转向「CPU 便宜、省磁盘」——一个实习生的原型数据就足以验证这个反转的方向。
参考链接：
- Cloudflare Blog：Cache Transcoding 原文
- Hacker News 讨论
