快取總覽

快取回應是 Cloud CDN 可儲存及快速擷取的 HTTP 回應，因此可加快載入時間。並非所有 HTTP 回應都可以快取。

快取模式

您可以透過快取模式控制決定 Cloud CDN 是否快取內容的因素。

Cloud CDN 提供三種快取模式，可定義回應的快取方式、Cloud CDN 是否會遵循來源傳送的快取指示，以及如何套用 快取 TTL。

可用的快取模式如下表所示：

即使沒有有效的快取指令，系統也可能快取錯誤回應。

將快取模式設為 FORCE_CACHE_ALL 前，請考量下列行為：

• 對於已簽署的網址或已簽署的 Cookie，FORCE_CACHE_ALL 會覆寫透過 Google Cloud 主控台或 gcloud --signed-url-cache-max-age 選項中的「Cache entry maximum age」設定指定的最大時間長度。

• FORCE_CACHE_ALL 會變更任何先前快取內容的存留時間 (TTL)。這項變更可能會導致先前視為新內容 (因為來自來源標頭的 TTL 較長) 的部分項目被視為舊內容，也可能會導致先前視為舊內容的部分項目被視為新內容。

• FORCE_CACHE_ALL 會覆寫快取指示 (Cache-Control 和 Expires)，但不會覆寫其他來源回應標頭。特別是，即使快取模式為 FORCE_CACHE_ALL，Vary 標頭也可能會抑制快取。詳情請參閱「變更標頭」一文。

如需設定操作說明，請參閱「設定快取模式」。

靜態內容

靜態內容是指即使由不同使用者存取，內容仍會保持不變的內容。您用來設定網站樣式的 CSS、提供互動功能的 JavaScript 以及圖片內容，通常不會因特定網址 (快取鍵) 而變更，因此可在 Cloud CDN 的全球邊緣網路中快取。

當您將快取模式設為 CACHE_ALL_STATIC，且回應在 Cache-Control 或 Expires 標頭中沒有明確的快取指示時，Cloud CDN 會自動快取該回應，以便執行以下操作：

• 網路素材資源，包括 CSS (text/css)、JavaScript (application/javascript) 和所有網路字型，包括 WOFF2 (font/woff2)
• 圖片，包括 JPEG (image/jpg) 和 PNG (image/png)
• 影片，包括 H.264、H.265 和 MP4 (video/mp4)
• 音訊檔案，包括 MP3 (audio/mpeg) 和 MP4 (audio/mp4)
• 已格式化的文件，包括 PDF (application/pdf)

下表提供摘要資訊。

Cloud CDN 會檢查 Content-Type HTTP 回應標頭，該標頭會反映所提供內容的 MIME 類型。

注意事項：

• 原始網站的網路伺服器軟體必須為每個回應設定 Content-Type。許多網路伺服器會自動設定 Content-Type 標頭，包括 NGINX、Varnish 和 Apache。

• 當您使用 Google Cloud 控制台或 Google Cloud CLI 上傳內容時，Cloud Storage 會自動設定 Content-Type 標頭。

• Cloud Storage 一律會向 Cloud CDN 提供 Cache-Control 標頭。如未明確選擇任何值，則會傳送預設值。因此，除非您明確調整 Cloud Storage 中物件的快取控制中繼資料，或使用 FORCE_CACHE_ALL 模式覆寫 Cloud Storage 傳送的值，否則所有成功的 Cloud Storage 回應都會根據 Cloud Storage 預設值快取。

• 如果您想快取 text/html 和 application/json 內容類型，必須在回應中設定明確的 Cache-Control 標頭，並小心不要誤將某位使用者的資料快取，並提供給所有使用者。

如果回應可根據其 MIME 類型進行快取，但 Cache-Control 回應標頭為 private 或 no-store，或是 Set-Cookie 標頭，則不會快取。詳情請參閱「快取可用性規則」。

系統預設不會為成功的回應快取其他內容類型，例如 HTML (text/html) 和 JSON (application/json)。這類回覆通常會根據使用者而變動。例如購物車、含有使用者個人化功能的產品頁面，以及已驗證的 API 回應。不過，如果啟用負面快取，仍可能會針對特定狀態碼快取這些資料。

Cloud CDN 不會使用網址路徑中的檔案副檔名，來判斷回應是否可快取，因為許多可快取的有效回應並未反映在網址中。

可快取的內容

Cloud CDN 會快取符合本節中所有條件的回應。其中有些條件是由 RFC 7234 指定，而其他則是 Cloud CDN 特有的條件。

Cloud CDN 可能會定期變更快取內容的確切條件組合。如果您想明確防止 Cloud CDN 快取內容，請按照 RFC 7234 中的指南，判斷如何指定保證無法快取的回應。另請參閱「根據來源標頭判斷是否可快取的內容」一節。

在下列所有條件都成立的情況下，Cloud CDN 會將回應儲存在快取中。

針對 Cloud Storage 後端值區，請遵循下列額外建議：

• 將 bucket 設為可公開讀取。這是我們建議用於公開內容的方法。設定這個權限後，網際網路上的任何使用者都能查看及列出您的物件和中繼資料，但不包括 ACL。建議做法是為公開物件專屬特定值區。

• 使用受管理的資料夾，將部分值區設為可公開讀取。

• 將個別物件設為可公開讀取。我們不建議採用這種做法，因為這會使用舊版 Cloud Storage 專屬的權限系統。

• 請勿將物件儲存在已啟用要求者付費的值區中，或位於虛擬私人雲端服務範圍內。

• 請勿使用客戶管理的加密金鑰或客戶提供的加密金鑰來加密物件。

根據預設，如果物件是公開且未指定 Cache-Control 中繼資料，Cloud Storage 會將 Cache-Control: public, max-age=3600 標頭指派給物件。您可以使用 Cache-Control 中繼資料設定不同的值。

如需設定外部應用程式負載平衡器 (含後端 bucket) 的範例，請參閱「使用後端 bucket 設定 Cloud CDN」一文。

大小上限

Cloud CDN 會強制執行每個回應的大小上限。任何回應內文大小超過上限的回應都不會快取，但仍會傳送至用戶端。

大小上限會根據原始伺服器是否支援位元組範圍要求而有所差異。

幾乎所有新型網路伺服器 (包括 NGINX、Apache 和 Varnish) 都支援位元組範圍要求。

根據來源標頭無法快取的內容

另有一些檢查會封鎖回應的快取。Cloud CDN 可能會定期變更快取內容的確切條件組合，因此如果您想明確防止 Cloud CDN 快取內容，請按照標準 (RFC 7234) 中的指南，判斷如何指定保證無法快取的回應。

如果回應不符合「可快取的內容」要求，或是滿足下列任一條件，Cloud CDN 就不會快取該回應：

如果存在 Cache-Control: no-store 或 private，但系統仍對內容進行快取，可能是因為下列原因之一：

• 已設定網址簽署功能。
• Cloud CDN 快取模式設為強制快取所有回應。

防止快取

如果不想讓系統將私人資訊快取至 Cloud CDN 快取內容中，請按照下列步驟操作：

1. 請確認 Cloud CDN 快取模式未設為 FORCE_CACHE_ALL 模式，否則系統會無條件快取所有成功的回應。
2. 為不應儲存在 Cloud CDN 快取內容或任何快取內容 (甚至是網頁瀏覽器的快取內容) 的回應加入 Cache-Control: private 標頭，或為不應儲存在任何快取內容 (包括網頁瀏覽器的快取內容) 的回應加入 Cache-Control: no-store 標頭。
3. 網址若提供私人資訊的存取權，則請勿簽署網址。如果可使用已簽署的網址存取內容，無論回應中是否有任何 Cache-Control 指令，系統都有可能快取這類內容。
4. 針對包含 Authorization 要求標頭的原始 (快取填補) 要求，Cloud CDN 只會在快取模式設為 USE_ORIGIN_HEADERS 或 CACHE_ALL_STATIC 時，快取包含 public、must-revalidate 或 s-maxage 快取控制指示的回應。這可避免意外快取個別使用者內容和需要驗證的內容。FORCE_CACHE_ALL 快取模式則沒有這項限制。

自訂回應標頭

您可以使用自訂回應標頭，指定傳統應用程式負載平衡器在經 Proxy 處理的回應中新增的標頭。您可以使用自訂回應標頭，向用戶端反映快取狀態、用戶端地理資料和您自己的靜態回應標頭。

如需操作說明，請參閱「設定自訂回應標頭」。

快取金鑰

Cloud CDN 快取中的每個快取項目是按「快取金鑰」識別。當要求進入快取時，快取會將要求的 URI 轉換為快取金鑰，然後將其與快取項目的金鑰進行比對。如果發現相符項，快取就會傳回與該金鑰相關聯的物件。

對於後端服務，Cloud CDN 會依預設使用完整的要求 URI 做為快取金鑰。例如 https://example.com/images/cat.jpg 是 cat.jpg 物件特定要求的完整 URI。此字串會做為預設快取鍵。只有與這個字串完全相符的要求。http://example.com/images/cat.jpg 或 https://example.com/images/cat.jpg?user=user1 的要求不相符。

對於後端值區，快取金鑰預設由 URI 組成，不含通訊協定或主機。根據預設，只有 Cloud Storage 已知的查詢參數會列入快取金鑰 (例如「代別」)。

因此，對於特定後端值區，下列 URI 會解析為相同的快取物件：

• http://example.com/images/cat.jpg
• https://example.com/images/cat.jpg
• https://example.com/images/cat.jpg?user=user1
• http://example.com/images/cat.jpg?user=user1
• https://example.com/images/cat.jpg?user=user2
• https://media.example.com/images/cat.jpg
• https://www.example.com/images/cat.jpg

您可以變更要在快取金鑰中使用哪些部分的 URI。雖然檔案名稱和路徑一律必須是金鑰的一部分，但在自訂快取金鑰時，可以加入或省略任何通訊協定、主機或查詢字串的組合。使用快取金鑰一文說明如何自訂快取金鑰。

除了加入或省略整個查詢字串外，您還可以使用納入清單和排除清單，使用查詢字串的部分內容。

查詢字串包含清單

您可以選擇控制 Cloud CDN 要納入快取金鑰的查詢字串參數。舉例來說，如果您建立 user 的納入清單，https://example.com/images/cat.jpg?user=user1&color=blue 就會建立 https://example.com/images/cat.jpg?user=user1 的快取金鑰，而該金鑰也與 https://example.com/images/cat.jpg?user=user1&color=red 相符。

如要使用這個選項，您必須加入查詢字串、指定非空的包含清單，且「不得」指定排除清單。

Cloud Storage 快取金鑰的查詢字串包含清單

在 Cloud Storage 值區的快取金鑰中加入網址查詢參數，有助於支援快取破壞。快取破壞可讓使用者擷取已上傳檔案的新版本，即使先前版本仍根據 TTL 設定有效快取也一樣。

您可以在用於提供後端值區回應的快取金鑰中，使用包含查詢字串參數的納入清單。雖然 Cloud Storage 不會根據查詢參數提供不同內容或路由，但您可以選擇加入參數，讓您能夠針對儲存在 Cloud Storage 值區中的靜態內容進行快取破壞。

舉例來說，您可以附加以基礎內容為依據的 ?version=VERSION 或 ?hash=HASH 查詢參數。這可減少主動讓內容失效的需求，並與新式網路開發工作流程保持一致，因為網路架構和網址會使用內容的雜湊，避免在部署期間提供過時的物件。

由於在快取金鑰中加入查詢參數是屬於選擇性加入的功能，Cloud CDN 不支援從快取金鑰中排除查詢參數至後端值區。

查詢字串排除清單

您可以使用排除清單，選擇性控制 Cloud CDN 要忽略的查詢字串參數。舉例來說，如果您建立 user 的排除清單，則會在快取金鑰中使用所有查詢字串參數，但 user 除外。

在排除清單設定完成並輸入 https://example.com/images/cat.jpg?user=user1&color=blue 後，Cloud CDN 會建立 https://example.com/images/cat.jpg?color=blue 的快取索引鍵，該索引鍵也與 https://example.com/images/cat.jpg?user=user2&color=blue 相符，但不與 https://example.com/images/cat.jpg?user=user1&color=red 相符。

如要使用這個選項，您必須加入查詢字串、指定非空的排除清單，且「不得」指定包含清單。

查詢參數順序

系統產生的快取金鑰不依賴查詢參數的順序。

舉例來說，下列查詢參數會產生相同的快取鍵：

• info=123&variant=13e&geography=US
• geography=US&variant=13e&info=123

HTTP 標頭和 HTTP Cookie 設定

您可以使用下列快取鍵設定，改善快取命中率和來源卸載：

• 後端服務和資料夾：在快取金鑰設定中加入命名標頭，以便使用 HTTP 標頭做為快取金鑰的一部分。
• 僅限後端服務：使用命名的 HTTP Cookie 做為快取金鑰，例如 A/B (多變量) 測試、實驗版測試和類似情境。

在要求中加入其他 HTTP 標頭或 HTTP cookie 的快取要求，會在第三次要求時，在該快取金鑰的快取位置中快取。這可降低高基數標頭或 Cookie 值對快取淘汰率的影響。在一般情況和使用者流量條件下，這項功能應該不會造成明顯影響，且有助於確保熱門內容仍會快取。

加入要求標頭

如要快取回應的其他變化版本，您可以在快取金鑰中加入其他要求標頭。

某些標頭通常具有非常高的基數，因此不允許用於快取索引鍵。在大多數情況下，這些標頭的值要麼是每位使用者專屬 (Cookie、Authorization)，要麼是可能有數千個值 (Referer、User-Agent、Accept)。舉例來說，由於瀏覽器、使用者裝置和作業系統的種類繁多，User-Agent 標頭可能會有超過 5,000 個不重複的值。這類標頭會對快取命中率造成嚴重負面影響。

根據 RFC 7230 的規定，系統只會接受有效的 HTTP 標頭欄位名稱。標頭欄位名稱不區分大小寫，且不允許重複。

您可以選擇設定原始伺服器，在 Vary 回應中加入已設定的快取鍵要求標頭。這並非 Cloud CDN 的必要條件，但對下游快取來說可能很有幫助。詳情請參閱「變異標頭」。

Cloud CDN 不允許在標頭清單中加入下列標頭：

• Accept
• Accept-Encoding
• Authority，因為這項設定是由設定 (cdnPolicy.includeHost) 控制
• Authorization，通常是 OAuth Bearer 權杖中的使用者
• CDN-Loop
• Connection
• Content-MD5
• Content-Type
• Cookie
• Date
• Forwarded，通常是每個用戶端或每個 Proxy
• From
• Host，因為這項設定是由設定 (cdnPolicy.includeHost) 控制
• If-Match、If-Modified-Since 或 If-None-Match
• Origin
• Proxy-Authorization
• Range
• Referer (或是Referrer)
• User-Agent
• Want-Digest
• X-CSRFToken 和 X-CSRF-Token (Django 和 Ruby on Rails 使用)
• X-Forwarded-For，通常是每個用戶端或每個 Proxy
• X-User-IP
• 任何以以下標頭開頭：
  • Access-Control-，例如 Access-Control-Request-Headers 和 Access-Control-Request-Method
  • Sec-Fetch-
  • Sec-GFE-
  • Sec-Google-
  • X-Amz-
  • X-GFE-
  • X-Goog-
  • X-Google-

使用自訂變數和要求標頭

如果您需要根據每位使用者的裝置和位置，提供不同的內容，快取鍵就會派上用場。舉例來說，您可以啟用回應式網站，讓系統根據使用者的裝置類型，為他們顯示適當的圖片，或是根據使用者的所在位置，設定有用的預設語言。您可以使用自訂要求標頭和自訂變數來定義快取索引鍵。

如要使用含有要求標頭的自訂變數，請按照下列步驟操作：

1. 為後端服務定義自訂要求標頭。為自訂要求標頭值加入一或多個變數。
2. 更新快取金鑰，以便使用自訂要求標頭。

針對 Cloud CDN，您只能在定義同時具備自訂要求標頭和快取金鑰標頭的標頭時，使用下列變數：

• device_request_type
• user_agent_family
• client_region
• client_region_subdivision

Cloud CDN 會限制變數，以協助維持快取效能。這與可用做快取鍵的標頭的限制類似。

舉例來說，如果您可以將 X-Lat-Long:{client_city_lat_long} 指定為自訂要求標頭，然後將 X-Lat-Long 新增至快取金鑰標頭組合，Cloud CDN 就會嘗試為 client_city_lat_long 的每個值快取一個回應副本。這最終會導致快取過度使用、不必要的內容沖洗，以及減少快取命中返回的機會。

基於這些原因，具有高卡氏度的變數不會列入用於定義自訂要求標頭和後續快取鍵的變數清單中。

相同的標頭，但值不同

假設使用者傳送多個名稱相同的標頭，但標頭值不同，例如：

My-Header: Value1
My-Header: Value2

在這種情況下，Cloud CDN 會假設標頭必須遵循標準慣例，允許部分標頭具有多個值，進而修改要求。Cloud CDN 會將這些項目折疊成以半形逗號分隔的清單，然後傳送至後端，因此客戶端傳送的內容會像這樣：

My-Header: Value1, Value2

納入已命名的 Cookie

HTTP Cookie 是 name=value 配對，且要求可包含多個 HTTP Cookie，這些 Cookie 可在同一行中以分號分隔，或以個別的 Cookie 要求標頭表示，每個標頭對應一個 Cookie。

您最多可以提供五個 Cookie 名稱清單。

使用者代理程式 (例如網頁瀏覽器) 通常會將每個網域儲存的 Cookie 數量限制在 4 KB；請務必不要傳送太多 (或太大) 的 Cookie，因為使用者代理程式可能不會在要求中傳送所有 Cookie。這可能會影響使用者是否會收到特定快取回應。

如果您要從發出 Cookie 的不同主機名稱提供靜態內容，請確認 Cookie 的 Domain 屬性 (以及 Path) 屬性允許 Cookie 隨靜態內容要求一併傳送。

如果請求包含相同 Cookie 名稱的多個例項，系統只會採用第一個例項。

快取控制指令

HTTP 快取控制指示會影響 Cloud CDN 的行為，如下表所述。

N/A 表示指令不適用於要求或回應。

在可行情況下，Cloud CDN 會盡力遵循 RFC (HTTP RFC 7234)，但會優先針對快取卸載進行最佳化，並盡量減少用戶端對命中率和整體來源負載的影響。

如採用 HTTP/1.1 Expires 標頭的回應：

• Expires 標頭的值必須是有效的 HTTP 日期，如RFC 7231 所定義。
• 過去的日期值、無效日期或 0 值表示內容已過期，需要重新驗證。
• 如果回應中包含 Cache-Control 標頭，Cloud CDN 會略過 Expires 標頭。

如果回應中含有有效的未來 Expires 標頭，回應就會快取，且不需要指定其他快取指令。

如果回應中包含 HTTP/1.0 Pragma 標頭，系統會忽略該標頭，並將其原樣傳遞給用戶端。含有此標頭的用戶端要求會傳遞至原始來源，且不會影響 Cloud CDN 提供回應的方式。

Vary 標頭

Vary 標頭代表回應會根據用戶端的要求標頭而改變。除了要求 URI 外，Cloud CDN 還會遵循原始伺服器在回應中加入的任何 Vary 標頭。舉例來說，如果回應指定 Vary: Accept，Cloud CDN 會為指定 Accept: image/webp,image/*,*/*;q=0.8 的要求使用一個快取項目，並為指定 Accept: */* 的要求使用另一個快取項目。

「無法快取的內容」部分的表格列出可讓內容快取的 Vary 標頭。其他 Vary 標頭值會防止內容快取。

FORCE_CACHE_ALL 快取模式「不會」覆寫這項行為。Vary 標頭非常重要，可避免在多個可能的原始伺服器回應之間發生快取中毒。FORCE_CACHE_ALL 會導致這些回應遭到快取，這十分危險。

有時在放送壓縮內容時，系統會使用 Vary 標頭。Cloud CDN 本身不會壓縮或解壓縮回應 (除非啟用動態壓縮)，但可以提供原始伺服器壓縮的回應。如果原始伺服器依據 Accept-Encoding 要求標頭的值來選擇是否提供壓縮或解壓縮的內容，請確保回應指定了 Vary: Accept-Encoding。

使用快取索引鍵中的 HTTP 標頭時，Cloud CDN 會根據指定要求標頭的值快取多個回應副本，類似於 Vary 支援，但原始伺服器不需要明確指定任何 Vary 回應標頭。如果來源在 Vary 回應中指定快取鍵標頭，Cloud CDN 會正確處理回應，就像 Vary 回應中未提及標頭一樣。

到期時間與驗證要求

快取項目的到期時間會定義快取項目的有效時間。s-maxage (或 max-age 或 expires) 提供的值可讓系統自動重新驗證過時的使用者產生快取內容。

當 Cloud CDN 收到要求時，會查詢對應的快取項目並檢查其存在時間。如果快取項目存在且足夠新鮮，回應可以從快取中提供。如果已過期，Cloud CDN 會嘗試透過聯絡其中一個後端來重新驗證快取項目。除非您啟用 serve-while-stale，否則這項作業會在傳送回應前執行，在這種情況下，系統會以非同步方式執行重新驗證作業。

您可以為部分快取模式設定 TTL 值。詳情請參閱「使用存留時間設定和覆寫值」。

快取模式會影響系統判斷新鮮度的方式。

如果有多個，Cache-Control: s-maxage 優先於 Cache-Control: max-age，Cache-Control: max-age 優先於 Expires。

根據預設，如果到期時間值超過 30 天 (2,592,000 秒)，Cloud CDN 會將到期時間值視為 2,592,000 秒。即使超過 30 天，下游用戶仍會看到 max-age 和 s-maxage 的正確值。

驅逐

我們無法保證快取項目會一直保留在快取中，直到到期為止，因為不受歡迎的項目可能會在到期前隨時遭到淘汰，以便騰出空間給新內容。系統會自動淘汰 30 天內未存取的快取項目，做為上限。

詳情請參閱移除及到期時間。

使用條件式要求進行驗證

Cloud CDN 會嘗試使用快取回應標頭中的資訊，透過後端驗證快取項目。發生這種情況時，必須同時符合下列兩個條件：

• 先前快取的回應含有 Last-Modified 或 ETag 標頭。
• 用戶端要求是 GET 要求，不含 If-Modified-Since 或 If-None-Match 標頭。

Cloud CDN 執行這項驗證的方式會因回應是否使用位元組範圍要求快取而略有不同：

• 如果回應是使用位元組範圍要求快取，Cloud CDN 會發出獨立的驗證要求，其中包含 If-Modified-Since 和 If-None-Match 標頭。
• 否則，Cloud CDN 會在用戶端要求中加入 If-Modified-Since 和 If-None-Match 標頭，並將修改後的要求轉送至後端。

如果快取副本仍為最新版本，後端可以傳送 304 Not Modified 回應，驗證現有的快取項目。在這種情況下，後端只會傳送回應標頭，而不會傳送回應內容。Cloud CDN 會在快取中插入新的回應標頭，接著更新到期時間，並將新的回應標頭和快取的回應內容提供給用戶端。

如果先前快取的回應沒有 Last-Modified 或 ETag 標頭，Cloud CDN 會忽略過期快取項目，並將用戶端要求轉送至未經修改的後端。

支援位元組範圍要求

符合下列條件的回應表示來原始伺服器支援位元組範圍要求：

• 狀態碼：200 OK 或 206 Partial Content
• 標題：Accept-Ranges: bytes
• 標頭：Content-Length，如果是 206 Partial Content 回應，則為 Content-Range 值，表示原始物件的完整長度。舉例來說，Content-length: 0-100/999 可供快取，但 Content-length: 0-100/* 則不行。
• 標頭：Last-Modified 和 ETag，搭配強大驗證工具。

Cloud Storage 支援大部分物件的位元組範圍要求。不過，除非用戶端要求包含 Accept- Encoding: gzip 標頭，否則 Cloud Storage 不支援含有 Content-Encoding: gzip 中繼資料的物件位元組範圍要求。如果您有超過 10 MB 的 Cloud Storage 物件，請確認這些物件沒有 Content-Encoding: gzip 中繼資料。如要瞭解如何編輯物件中繼資料，請參閱「查看及編輯物件中繼資料」一文。

常見的網路伺服器軟體也支援位元組範圍要求。如要進一步瞭解如何啟用支援功能，請參閱網頁伺服器的說明文件。如要進一步瞭解位元組範圍要求，請參閱 HTTP 規格。

原始伺服器支援位元組範圍要求時，如果滿足以下任一條件，Cloud CDN 快取會在第一次收到要求時拒絕儲存可快取的回應：

• 回應主體不完整，因為用戶端只要求部分內容。
• 回應主體大小超過 1 MB (1,048,576 位元組)。

如果發生這種情況而且回應其實符合一般快取需求條件時，快取會記錄原始伺服器支援該快取金鑰的位元組範圍要求，並將原始伺服器的回應轉送至用戶端。

在快取中找不到所需資料時，快取機制會檢查原始伺服器是否支援位元組範圍要求。如果已知快取金鑰支援位元組範圍要求，快取機制就不會將用戶端要求轉送至外部應用程式負載平衡器。相反地，快取會針對內容缺少的部分，啟動自己的位元組範圍快取填補要求。

Cloud CDN 發出自己的位元組範圍快取填補要求時，原始伺服器會傳回 206 Partial Content 回應。206 Partial Content 回應必須包含 Content-Range 標頭，且 complete-length 指令不得包含星號，例如 0-100/999，才能在快取時納入考量。接著，Cloud CDN 會快取已傳回的 206 Partial Content 回應，並用於回應日後用於該內容的用戶端要求。

只有在快取收到快取啟動的位元組範圍要求回應時，才會儲存 206 Partial Content 回應。除非快取之前曾記錄過原始伺服器支援該快取金鑰的位元組範圍要求，否則快取不會發出位元組範圍要求，因此在大小超過 1 MB 的內容發生第二次存取之前，指定的快取並不會儲存該內容。

由於 Cloud CDN 的特性是分散式，因此有時可能會在每個位置從來源擷取最終區塊多次。這項設定只會影響每個快取索引鍵的前幾個要求。

要求折疊 (合併)

要求摺疊 (也稱為「合併」) 會主動將針對相同快取鍵的多個使用者驅動快取填補要求，摺疊為每個邊緣節點的單一原始要求。這麼做可以主動減少來源的負載量，並適用於項目要求 (直接擷取的回應) 和區塊要求，Cloud CDN 會使用 Range 要求來更有效率地擷取較大的物件。

根據預設，系統會啟用要求摺疊功能。

折疊要求的運作方式如下：

• 已摺疊的要求會記錄面向用戶端的要求和 (已摺疊的) 快取填充要求。
• 系統會使用已摺疊工作階段的領導者提出來源填入要求。
• 不在快取鍵中的要求屬性 (例如 User-Agent 或 Accept-Encoding 標頭) 只會反映已折疊工作階段的領導者。
• 無法摺疊不含相同快取鍵的要求。

下圖顯示要求如何合併：

相較之下，如果要求摺疊功能已停用，或是要求無法合併，原始要求和回應的數量可能會等於嘗試擷取未快取的物件的用戶端數量。

根據預設，系統會為所有類型的要求啟用摺疊功能。針對項目要求類型，您可以停用摺疊功能。建議您在對延遲時間極為敏感的情況下 (例如廣告放送)，停用項目要求的摺疊功能，因為在這種情況下，不必考量來源載入作業。

下表概略說明不同要求類型的預設行為和可設定性。

如要使用 Google Cloud CLI 為參照 Cloud Storage 值區的後端值區停用項目要求摺疊功能，請按照下列步驟操作：

gcloud compute backend-services update BACKEND_SERVICE_NAME \
    --no-request-coalescing

如要使用 Google Cloud CLI 在後端值區中啟用項目要求摺疊功能，請按照下列步驟操作：

gcloud compute backend-buckets update BACKEND_BUCKET_NAME \
    --request-coalescing

如要使用 Google Cloud CLI 為後端服務 (包括 VM 群組和外部後端) 啟用項目要求摺疊功能，請按照下列步驟操作：

gcloud compute backend-services update BACKEND_SERVICE_NAME \
    --request-coalescing

Cloud CDN 發出的要求

如果原始伺服器支援位元組範圍要求，Cloud CDN 可以傳送多個要求到原始伺服器，以回應單一用戶端要求。Cloud CDN 可以發出兩種類型的要求：驗證要求和位元組範圍要求。

如果回應指出原始伺服器支援特定快取金鑰的位元組範圍要求，且該回應已經到期，Cloud CDN 就會發出驗證要求，確認內容是否不曾變更，以及確認原始伺服器是否仍支援該內容的範圍要求。如果原始伺服器的回應是 304 Not Modified，Cloud CDN 就會繼續使用位元組範圍提供內容。否則，Cloud CDN 就會將原始伺服器的回應轉送給用戶端。您可以使用 Cache-Control 和 Expires 回應標頭控管到期時間。

在快取未命中時，Cloud CDN 會針對與用戶端要求重疊的位元組範圍組合，發出快取填補要求。如果快取中包含用戶端要求的部分內容範圍，Cloud CDN 會從快取中提供所有可用的內容，並只針對缺少的範圍向原始伺服器傳送位元組範圍要求。

由 Cloud CDN 發出的每個位元組範圍要求均會指定一個範圍，該範圍會從 2,097,136 位元組倍數的偏移位置開始。除了最終範圍之外，每個範圍也都是 2,097,136 個位元組。如果內容不是該大小的倍數，最終範圍會縮小。位元組範圍要求中使用的大小和偏移日後可能會變更。

舉例來說，假設用戶端要求的內容位元組落在 1,000,000 到 3,999,999 之間，但快取中並未包含這段內容。在此範例中，Cloud CDN 會發出兩個 GET 要求，一個要求取得第一個 2,097,136 位元組的內容，另一個要求取得第二個 2,097,136 位元組的內容。這會產生 4,194,272 位元組的快取填補，即使用戶端只要求了 3,000,000 位元組。

當您使用 Cloud Storage 值區做為來源時，系統會將每個 GET 要求視為個別的 B 級作業來計費。系統會針對 Cloud Storage 處理的所有 GET 要求收費，包括 Cloud CDN 發起的任何要求。如果回應完全由 Cloud CDN 快取提供，就不會傳送 GET 要求至 Cloud Storage，也不會向您收取任何 Cloud Storage 作業費用。

當 Cloud CDN 發出驗證要求或位元組範圍要求時，不會納入用戶端專用標頭，例如 Cookie 或 User-Agent。

在 Cloud Logging 的 httpRequest.userAgent 欄位中，Cloud-CDN-Google 表示 Cloud CDN 發出要求。

略過快取

快取略過功能可讓包含特定要求標頭的要求略過快取，即使內容先前已快取也一樣。

本節提供有關使用 HTTP 標頭 (例如 Pragma 和 Authorization) 略過快取的資訊。如要確保使用者或客戶隨時都能從原始伺服器取得最新內容，這項功能就很實用。您可能需要進行測試、設定暫存目錄或指令碼。

如果指定的標頭相符，系統會略過所有快取模式設定的快取，包括 FORCE_CACHE_ALL。如果指定的標頭適用於多項要求，快取略過功能就會導致大量快取遺漏。

事前準備

• 請確認已啟用 Cloud CDN。如需操作說明，請參閱「使用 Cloud CDN」。

• 視需要更新至最新版 Google Cloud CLI：

  gcloud components update
  

設定快取略過功能

您最多可以指定五個 HTTP 標頭名稱。值不區分大小寫。標頭名稱必須是有效的 HTTP 標頭欄位符記。標頭名稱在新增標頭清單中不可出現超過一次。如要瞭解有效標頭名稱的規則，請參閱「自訂標頭的運作方式」。

gcloud compute backend-buckets (create | update) BACKEND_BUCKET_NAME
    --bypass-cache-on-request-headers=BYPASS_REQUEST_HEADER

gcloud compute backend-services (create | update) BACKEND_SERVICE_NAME
    --bypass-cache-on-request-headers=BYPASS_REQUEST_HEADER

gcloud compute backend-services update my-backend-service
    --bypass-cache-on-request-headers=Pragma
    --bypass-cache-on-request-headers=Authorization

PATCH https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendBuckets

"cdnPolicy": {
  "bypassCacheOnRequestHeaders": [
    {
      "headerName": string
    }
  ]
}

停用快取略過功能

gcloud compute backend-services (create | update) (BACKEND_SERVICE_NAME | BACKEND_BUCKET_NAME)
    --no-bypass-cache-on-request-headers

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendBuckets
PUT https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendBuckets/BACKEND_BUCKET
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices
PUT https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE

"cdnPolicy": {
  "fields": "bypassCacheOnRequestHeaders"
}

後續步驟

• 如要瞭解快取模式如何讓快取內容更輕鬆，請參閱「使用快取模式」。
• 如要為 HTTP(S) 負載平衡執行個體和儲存空間值區啟用 Cloud CDN，請參閱「使用 Cloud CDN」一文。
• 如要瞭解如何撤銷快取，請參閱「快取撤銷總覽」。
• 如要查看 GFE 點播點，請參閱「快取位置」。