在現代的內容傳遞網路（CDN）架構中，儲存空間與頻寬成本始終是影響效能與成本的核心因素。Cloudflare 近期公開了一項名為 Cache Transcoding 的原型技術，旨在透過對快取內容進行壓縮，大幅降低伺服器磁碟的儲存需求，並減少資料中心之間傳輸的流量。這項技術的核心在於將原本以未壓縮狀態儲存的文本內容，在寫入快取之前先進行壓縮，從而提升單一伺服器能承載的有效快取容量。
快取儲存的挑戰與背景
在 CDN 的運作流程中，伺服器會快取來自源站的回應內容，以便在下次請求時直接提供給使用者，減少回源壓力。然而，許多網站傳送的內容，如 HTML、JSON、CSS 以及 JavaScript 等文本格式，雖然在傳輸給客戶端時可能會被壓縮（例如使用 Gzip 或 Brotli），但在儲存於快取伺服器磁碟時，往往是以未壓縮的形式存在。這導致了大量的儲存空間被重複且冗餘的文字資訊佔用。
對於像 Cloudflare 這樣規模的雲端服務商而言，儲存空間的微小優化在海量數據面前會產生巨大的影響。如果能有效縮小快取檔案的體積，不僅能增加單機的快取命中率，還能降低 Tiered Cache（分層快取，一種讓邊緣節點在回源前先詢問上層快取伺服器的機制）在不同層級之間傳輸資料的頻寬消耗。
核心運作機制與技術實現
Cache Transcoding 的運作邏輯相對簡單且高效：當符合條件的內容進入快取時，系統會先將其壓縮，儲存於磁碟中；而當使用者請求該內容時，系統再將其解壓縮後送出。為了實現這一目標，Cloudflare 採用了 Zstandard 壓縮演算法。Zstandard 是由 Meta（原 Facebook）開發的一種無損壓縮演算法，其特點是在提供高壓縮比的同時，能保持極快的解壓縮速度，非常適合需要即時回應的網路環境。
在實作層面上，這項功能整合在 Cloudflare 的 Pingora 代理框架中。Pingora 是 Cloudflare 使用 Rust 語言重新開發的高效能代理伺服器框架，旨在取代舊有的 Nginx 架構，提供更高的記憶體安全與執行效率。透過 Pingora 的底層控制，Cloudflare 能在內容進入快取的瞬間完成一次性的編碼（Encoding）成本，而後續每次重複使用該快取時，都能持續享有儲存空間與頻寬的節省。
壓縮策略與篩選條件
為了避免不必要的 CPU 資源浪費，Cloudflare 並非對所有內容進行壓縮。根據其流量樣本分析，影像、影片和字體等媒體檔案雖然僅佔請求數的 21.4%，卻佔據了總位元組數的 63.3%。由於這些檔案本身已是壓縮格式，再次壓縮不僅無法縮小體積，反而會消耗大量 CPU 運算能力。
因此，Cache Transcoding 僅針對以下條件的內容進行處理：首先，內容必須是可壓縮的文本（如 HTML、JSON、CSS、JavaScript），這類內容約佔請求數的 67.3% 且佔位元組數的 22.3%；其次，回應狀態必須為成功，且內容大小必須至少達到 4 KiB。設定 4 KiB 的門檻是為了避免處理過多的小物件，因為小檔案的壓縮效益低，卻會增加管理開銷。根據測試，這項篩選僅會犧牲約 1% 的可壓縮數據，但能顯著降低 CPU 壓力。
實務影響、限制與未來方向
根據初步測試結果，這項技術能將符合條件的內容體積縮小約 2.8 倍。對於 Cloudflare 而言，這意味著在不增加硬體設備的情況下，能額外獲得數 PB（Petabytes，1 PB 等於 1,024 TB）的有效快取容量。這種儲存密度的提升，直接轉化為更高的快取命中率與更低的延遲。
然而，該技術目前仍處於原型階段，且存在一些技術爭議與限制。例如，社群討論中提到 Range Requests（範圍請求，允許客戶端僅請求檔案的一部分）的處理問題。在未壓縮的快取中，伺服器可以輕鬆地跳轉到檔案的特定偏移量讀取數據；但一旦內容被壓縮，伺服器可能需要解壓縮較大片段才能獲取所需部分，這可能會影響大檔案的部分讀取效能。此外，關於應該壓縮熱門內容（追求讀取速度）還是冷門內容（追求儲存空間）的策略權衡，仍是開發團隊持續測試的重點。
目前 Cloudflare 計劃進一步測試不同的壓縮等級、物件大小以及在不同分層快取場景下的表現，以找到 CPU 運算成本與儲存空間節省之間的最佳平衡點。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。