Cloudflare 推出 Origin Range Requests 優化大型檔案快取

背景

HTTP 範圍請求（Range Request）允許客戶端僅要求資源的一部分而非整個檔案，常見於影片播放器跳轉、下載管理器斷點續傳或套件管理器擷取部分工件。傳統 CDN（內容分發網路）在快取這類請求時，若採用靜態區域設定，需預先定義固定的範圍大小。這種做法存在兩難：範圍過小會導致大量小型來源請求並增加記憶體壓力；範圍過大則會下載遠超客戶端需求的資料，造成頻寬與磁碟操作浪費。此外，舊有基於 nginx 的快取架構無法將範圍快取與並行串流結合，導致熱門檔案需為每個範圍單獨向來源抓取資料。 官方原文・Cloudflare Blog

發生什麼事

Cloudflare 於 2026 年 10 月 23 日宣布推出 Origin Range Requests，這是一項適用於所有方案的自助服務功能。該功能基於 Pingora 架構重建快取處理邏輯，使用者無需調整範圍大小或聯繫支援團隊，只需透過 Cache Rule（快取規則）即可啟用。Cloudflare 表示，此功能旨在解決過去因客戶端選擇的範圍大小不可預測而對來源伺服器及網路造成的負面影響。 官方原文・Cloudflare Blog

重點內容

新機制利用 Pingora 將快取檔案以固定大小區塊（chunks）存於磁碟的特性，將範圍請求對齊至這些區塊邊界。當收到範圍請求時，Cloudflare 檢查哪些位元組已快取並直接提供，對於缺失的部分，則向來源抓取對齊區塊邊界的範圍，僅將客戶端要求的位元組返回。這種方式消除了對客戶端設定範圍大小的依賴，使額外的工作量變得有界且可預測。協調器（Coordinator）會整合磁碟上的快取資料、記憶體中的串流資料以及新抓取的來源資料，並確保所有位元組屬於同一個表示版本（representation），透過檢查實體標籤（entity tag）與 If-Range 標頭來驗證一致性。 官方原文・Cloudflare Blog

在內部測試中，Cloudflare 將此新實作應用於 R2 物件儲存服務。R2 舊有的設定範圍大小為 64 MiB，跨範圍邊界的小讀取可能導致 128 MiB 的資料中心間傳輸。遷移至新實作後，R2 儲存區域的首位元組時間（p99 time to first byte）在快取命中與未命中情況下均下降約一半。此外，透過讓協調器在單一回應中結合磁碟上的位元組與上游抓取的位元組，R2 及類似工作負載的分層快取流量週對週下降約 6%，這意味著每日在資料中心之間移動的資料量減少了數 PB（petabytes）。 官方原文・Cloudflare Blog

對使用者的意義

Origin Range Requests 適用於客戶端自然請求大型可快取物件部分的流量，例如 MP4 漸進式影片、可斷點續傳的大型下載、軟體分發、磁碟映像檔，以及傳輸大型模型檔案的 AI 訓練與推論工作負載。使用者可在控制台（dashboard）的 Caching > Cache Rules 中建立規則，或透過 API 設定 origin_range_requests: { "mode": "on" } 來啟用。Cloudflare 表示，此功能不改變正常的快取資格，啟用它不會使原本不可快取的回應變為可快取，且來源伺服器仍需支援位元組範圍以發揮部分抓取的效果。 官方原文・Cloudflare Blog

限制與未定事項

對於小於區塊大小的請求，系統仍需抓取包含該請求的整個區塊，因此無法完全消除額外工作。此外，對於非對齊的範圍請求，系統需承擔更多的工作成本。Cloudflare 指出，對於即將解壓縮的表示形式，由於壓縮位元組的範圍與解壓縮後回應的範圍不同，系統不會組合範圍，而是提供完整的轉換後回應。Cloudflare 計畫將此作為某些檔案類型在網路上的預設服務方式，但可透過快取規則修改。 官方原文・Cloudflare Blog

接下來要看的事

• Cloudflare 是否會公布更多關於 Pingora 架構在處理非對齊範圍請求時的具體效能數據？
• 除了 R2，其他使用舊有範圍快取設定的客戶在遷移至 Origin Range Requests 後的效能改善情況如何？
• Cloudflare 計畫將此功能設為預設服務方式的具體時間表與適用檔案類型清單為何？