Origin Range Requests：不需調整範圍請求即可高效傳輸大檔案

一個影片播放器在影片中間尋找位置時，會請求少量的 MB。使用我們舊的區段快取時，單一請求可能會導致 Cloudflare 從原始伺服器拉取 128 MiB，並在資料中心之間搬移，甚至在觀眾已離開後才完成。區段請求是大型檔案傳輸的方式，若簡單快取，往往會造成網路頻寬與磁碟操作的浪費，尤其在大型 CDN 運營時更為明顯。

因此我們重構了快取的處理方式。對於 R2（Cloudflare 的物件儲存），p99 首位元時間下降約一半，隨後的改進則將分層快取的流量對 R2 及類似工作負載減少約 6%。

今天，我們將這項新實作推出為 Origin Range Requests，一項所有方案皆可自助開啟的功能。無需調整區段大小，也不必聯絡客服。只需透過 Cache Rule 啟用，即可由 Cloudflare 處理其餘事宜。

請求檔案的一部分

HTTP 區段請求會要求資源的一部分，而非整個資源。客戶端會傳送一個正常的 GET，並附上一個 Range 標頭：

GET /movie.mp4 HTTP/1.1
Host: example.com
Range: bytes=1048576-2097151

若伺服器支援此請求，將回傳 206 Partial Content，並以 Content-Range 標頭標示回傳的位元組：

HTTP/1.1 206 Partial Content
Content-Range: bytes 1048576-2097151/524288000
Content-Length: 1048576

區段請求在大型物件中很常見。影片播放器可以只請求接近尋找位置的位元組，而非整檔。下載管理員可在中斷後繼續下載。套件管理員可抓取 artefact 的一部分。客戶端亦可在不下載前面所有內容的情況下檢視檔尾。

是否請求區段由客戶端決定，Cloudflare 不會改變此請求。相反地，Origin Range Requests 改變 Cloudflare 如何滿足此請求。

區段大小問題

Cloudflare 多年來已透過靜態區域設定支援區段請求快取。

先前的實作類似於 nginx 的部落格文章所描述的快取切片：每個客戶端請求都對應到固定大小的檔案區段，區段大小與檔案副檔名皆依區域設定。

每個區段的大小造成權衡：小區段會產生大量小型原始請求，並因在記憶體中合併所有請求而對 Cloudflare 造成記憶體壓力；而大區段則會使 Cloudflare 下載遠超客戶端所請求的資料。若更改區段大小，則會使快取項失效，因為區段大小是快取鍵的一部分。

此設計亦意味著透過我們網路請求內容的使用者可能會遇到不愉快的體驗。即使各客戶端請求的區段相距甚遠，若落在同一區段內的併發請求仍可能互相阻塞。我們基於 nginx 的快取亦無法將區段快取與併發串流結合，後者是我們設計來讓多個客戶端在檔案仍在寫入時從快取讀取。將兩者同時啟用會縮短回應時間，導致每個區段必須完全下載後才可供任何人閱讀，而熱門檔案則需要為每個區段進行單獨的原始抓取。

額外的位元組也可能跨越我們分散式快取的多個部分：從原始伺服器到某個資料中心、在快取層級之間，最後再傳送至客戶端。每一次跳遞都會放大浪費。沒有一個值能同時適用於小型尋找、順序下載、大型媒體檔案，以及所有原始與快取拓撲。

我們的內部快取限制直接暴露給客戶，客戶不應該需要深入瞭解我們的能力就能有效地提供檔案。

幸運的是，我們從 nginx 轉移到基於 Pingora 的快取伺服器，為解決曾迫使客戶使用難以操作設定的實作問題提供了機會。

固定尺寸的快取區塊

這個解決方案來自 Pingora 已經在做的事情。為了方便恢復中斷下載，它將每個快取檔案以固定尺寸的區塊儲存在磁碟上。若快取已經以區塊為思考單位，則範圍大小根本不需要成為設定，直接以區塊為單位即可！

對於範圍請求，Cloudflare 會檢查哪些請求的位元組已經被快取。它直接提供這些位元組。對於缺失的位元組，則會抓取與快取固定尺寸區塊邊界對齊的來源範圍，將結果存入同樣用於普通快取儲存的區塊，並僅回傳客戶端所請求的位元組。

例如，對位元組 150-250 的請求可能會導致 Cloudflare 抓取包含該位元組的對齊區塊。下游回應仍然只包含 150-250。

這並不會消除對於小於我們區塊大小的請求所帶來的額外工作——這樣的請求仍可能需要抓取整個包含它的區塊。我們也承擔了對非對齊範圍進行更多工作成本。不同之處在於，額外工作是有界且可預測的，且不再由客戶選擇的範圍大小決定，該大小可能對我們和來源造成不可預測的影響。

協調已快取與正在進行下載的資料

解析 Range 標頭相當直接。較困難的問題是當請求的位元組分散於已快取資料、來源回應以及已在進行中的下載時，產生一個正確的回應。

在高層面上，邊緣：

查詢資產標頭與範圍覆蓋度元資料。
從磁碟或記憶體串流中讀取它能讀到的任何部分。
使用對齊範圍從來源抓取缺失覆蓋。
寫入新位元組並在元資料中記錄已完成的範圍。
組合各部件並為客戶端回應設定 Content-Range 與 Content-Length。

這是一個協調器，而非單一快取查詢。一次請求可以使用已快取的字首、正在進行的下載，以及剛抓取的字尾。內部來源回應可能比下游回應更大，但下游狀態與標頭僅描述所請求的範圍。

若已有下載覆蓋另一個請求的位元組，第二個請求可以附加到該下載，而不是啟動另一個來源抓取。這在熱門大型檔案的突發流量時共享工作量。

此設計使用現有的快取資料模型。標頭識別資產版本，主體以受限區塊儲存，元資料記錄哪些範圍已成功寫入。

在組合前驗證

組合的範圍回應僅在所有位元組屬於同一表示時有效。協調器會檢查每個來源回應是否符合請求範圍、總資產大小是否穩定，以及實體標籤在子請求間是否保持一致。

If-Range 標頭允許客戶端僅在表示仍與已知驗證器相符時請求範圍。若不相符，Cloudflare 將返回完整表示，而不是合併不同版本的位元組。

Cloudflare 亦會避免為即將解壓縮的表示組合範圍，因為在壓縮位元組集合上的範圍將與解壓縮回應中所選範圍不同。在這些情況下，Cloudflare 會提供轉換後的完整回應，而非宣告無法正確支援的範圍。

其結果行為符合標準 HTTP：

一個可滿足的範圍會收到 206 Partial Content ，並附上準確的 Content-Range。
一個不可滿足的範圍會收到 416 Range Not Satisfiable。
無法安全範圍化的回應會以完整表示方式提供。

實際上發生了什麼變化

在將 Origin Range Requests 開放給所有人之前，我們先將舊版範圍快取功能的現有使用者遷移到新實作，從對我們影響最大的工作負載開始。

那些工作負載對極大檔案發出大量併發範圍請求，且流量往往非常尖峰。舊系統的範圍大小設定從數十 KB 到數十 GB。若範圍過大，雖然單筆請求可能不到一張軟碟大小，但仍會讓我們從源站下載相當於幾張 DVD 的資料，並跨多個資料中心傳輸，甚至在客戶已放棄並轉向其他服務之後才發生。若範圍過小，則一筆請求會拆分成長長的微小源站請求，每筆都佔用記憶體等待。這兩種模式都曾造成實際的營運事故。

R2 是最大的內部使用者，其設定的範圍大小為 64 MiB，因而一個跨範圍邊界的小讀取可能會造成 128 MiB 的資料中心間傳輸。將 R2 遷移到新實作後，我們觀察到：

回應更快。在 R2 的儲存區域中，p99 首位元組時間在快取命中與未命中時均下降約一半。
網路傳輸位元組更少。我們最新的變更教導協調器將已在磁碟上的位元組與從上游取得的位元組合併於單一回應中。之前，請求要麼完全從快取提供，要麼完全從上游提供。啟用此功能於 R2 後，R2 及類似工作負載的分層快取流量每週下降約 6%，每天減少數 PB 的資料在我們資料中心之間移動。

快速上手

當快取不再依賴客戶選擇的範圍大小時，產品設定已無法再簡化。客戶可透過 Cache Rules 選擇符合的流量。Cloudflare 負責分塊與快取協調。

Origin Range Requests 針對客戶端自然會請求大型可快取物件部分內容的流量：

可進度播放且可尋找的影片，例如 MP4
可恢復的大型下載
軟體發行與套件倉庫
磁碟映像、壓縮檔及其他多 GB 物件
AI 訓練與推論工作負載，轉移大型模型檔或抓取模型資產的選定區域
抓取元資料或大型檔案中小區域的客戶端

我們打算將此作為某些檔案型別在我們網路上預設的服務方式，可由快取規則修改。

此功能不會改變正常的快取資格。啟用它不會使原本不可快取的回應變為可快取。來源端亦須支援位元組範圍以便進行部分來源取用。

要啟用此功能，請建立一個 Cache Rule ，使其匹配您的大型檔案流量，並將 Origin Range Requests 設為 On。您可以在儀錶板的 Caching > Cache Rules 中執行此操作，或透過 API 進行 origin_range_requests: { "mode": "on" }。客戶選擇流量；邊緣節點負責快取協調與正確性需求。