Cloudflare 正在测试一种无需增加新硬件即可提高其缓存网络有效容量的方法，即在基于 Pingora 的架构中使用 Zstandard 算法压缩部分文本资源。该原型被公司称为 Cache Transcoding，旨在减少数据在磁盘上占用的空间，以及在缓存层与数据中心之间传输的数据量。
当符合条件的响应进入缓存时，其数据会在写入磁盘前使用 zstd 转换为压缩表示形式。这些资源在缓存中存储期间以及通过 Tiered Cache 传输期间都保持这种形式，随后在发送给客户端之前解压缩。因此，文件本身的内容不会发生变化；Zstandard 是一种无损压缩算法，解压缩后可将每个字节恢复到原始状态。
以有限的处理成本换取显著效果
在初步测试中，符合条件的资源在磁盘上的大小平均降至原始大小的约三分之一。在受控测试组中，压缩比达到 2.834 倍。编码成本为每字节 4.31 纳秒，即约每秒 232 MB，并且只在填充缓存时支付一次。相比之下，解码成本为每字节 1.56 纳秒，即约每秒 641 MB，并在每次提供内容时支付。
该实验使用 Zstandard 的第三级压缩级别，将其作为执行速度与输出大小之间的平衡点。根据 Cloudflare 的模型，在公司测试的流量和复用假设下，处理器消耗的增幅保持在几个百分点以内。与此同时，数据大小的缩减使每台服务器能够保留更多对象，并降低因内容占用过多空间而将有用内容逐出缓存的可能性。
Cloudflare 为什么不压缩所有内容？
该机制并不针对所有内容类型。图像、视频和字体通常已经经过压缩；在流量样本中，它们占请求数的 21.4%，但占总字节数的 63.3%。重新压缩这些数据可能会消耗处理器资源，却不会带来明显的节省。
相比之下，HTML、JSON、CSS 和 JavaScript 约占请求数的 67.3% 和字节数的 22.3%。这些文本响应中约有 71% 从源站返回时没有 Content-Encoding，因此成为压缩候选对象。该原型仅适用于 200 OK 响应、未指定 Content-Encoding、内容类型为可压缩文本且长度已知并不少于 4 KiB 的情况。
分片请求、源站已预先压缩的响应、范围请求、长度未知的正文以及二进制内容均保持不变。Cloudflare 发现，4 KiB 的阈值排除了大量小请求，但只排除了原本符合条件字节数的约 1%。
该机制如何跨缓存层工作？
当缓存完全未命中时，上层从源站获取未压缩数据，然后将其压缩一次并以 zstd 格式存储。该压缩格式会传递到下层；下层保留这种格式，并仅在面向客户端的请求路径上将其解压。如果对象只存在于上层，则可以将其传递到下层，而无需返回源站。
如果对象存在于下层，则无需进行网络传输或重新编码；系统从磁盘读取 zstd 数据，将其解压后传递到响应路径。系统会在元数据中记录该对象以压缩格式存储，从而防止对象在缓存层之间移动时被再次压缩。
certi.news 解读：这项实验究竟证明了什么？
这项实验表明，缩小数据在存储层本身所占的体积，其累积影响可能大于仅优化缓存填充过程。压缩成本在对象进入时支付，而每当对象被重复使用时，存储和带宽节省都会再次产生。对于大规模分发网络运营商而言，这一点尤其重要，因为本地容量决定了能够保留的内容量，而层间数据传输则与内部网络消耗相关。
不过，结果并不意味着 2.8 倍的比例代表整个互联网内容或 Cloudflare 的全部架构。性能测试基于通过十台缓存服务器发出的超过一百万个请求，但使用的是两个实验对象，大小约为 195 和 272 KiB，且二者都具有明显的可压缩性。公司承认，在认为该比例能够代表整个服务器群之前，还需要使用更广泛的内容类型和大小进行测试。
Cloudflare 计划测试更高的 zstd 级别，扩大内容类型和大小范围，调整资格条件，并研究范围请求和预先压缩的响应。因此，在当前材料中，Cache Transcoding 仍是在特定条件下取得成功的原型，而不是宣布将其最终推广到 Cloudflare 的全部流量。