本頁面提供透過 Cloud CDN 最佳化和加速內容傳遞的最佳做法。這些章節分為幾個主要領域。
Cloud CDN 會使用外部應用程式負載平衡器做為可快取內容的來源，外部應用程式負載平衡器可透過一個公網 IP 位址，將混合靜態和動態內容的資料從下列類型的後端傳遞給使用者：
- 執行個體群組
- 區域網路端點群組 (NEG)
- 無伺服器 NEG：一或多個 App Engine、Cloud Run 或 Cloud Run 函式服務
- 外部後端的網際網路 NEG
- Cloud Storage 中的值區
由於與 Google Cloud完美整合，您可透過多種方式部署 Cloud CDN 及管理內容。請參考下列最佳做法，規劃及調整部署作業。詳情請參閱「設定 Cloud CDN」。
提升快取命中率
建議採用下列做法，進一步提升快取命中率。
快取靜態內容
為提升效能，啟用 Cloud CDN 時，最佳做法是為應用程式選擇合適的快取模式。
管理快取規則最彈性且一般偏好的方法是使用快取控制項標頭。如果您不熟悉如何使用原始伺服器快取控制標頭，建議允許 Cloud CDN 自動快取靜態內容。
如要自動快取來源的靜態回應，可以使用 --cache-mode=CACHE_ALL_STATIC 設定 (預設)。如果來源未在回應標頭中指定任何快取指令，這項設定可讓 Cloud CDN 快取常見的靜態內容類型。請確認內容符合上述類別，否則系統不會快取內容。
不要快取使用者專屬內容
在某些情況下，瀏覽器可能會快取使用者專屬內容。請勿使用 Cloud CDN 快取使用者專屬內容。
使用自訂快取金鑰，提升快取命中率
為了提升效能和擴充性，設法提升快取命中率是很重要的一件事。根據預設，Cloud CDN 會使用完整的要求網址來建構快取金鑰。請使用自訂快取金鑰，進一步改善快取命中率，避免 Cloud CDN 不必要地將快取分片。
自訂快取金鑰可讓您加入或省略任何通訊協定、主機和查詢字串的組合。以下列舉幾個可能使用自訂快取鍵的情況：
您有兩個主機解析為相同的 IP 位址，並前往相同的服務。在本例中，兩個主機上的整個網站都相同。根據預設，由於 HTTP 要求中的
Host:標頭不同，Cloud CDN 會快取兩個副本。使用自訂快取金鑰，您可以讓 Cloud CDN 忽略要求的主機部分，並共用快取項目。舉例來說，您可能在不同網域有兩個網站，但使用相同的標誌。網站內容不同，但兩個網域都使用相同的公司標誌，且您有專屬的後端服務，可存放共用內容。啟用 Cloud CDN 並自訂含有標誌的後端服務快取金鑰時，請清除「Host」核取方塊，讓快取忽略網域，但快取標誌。
無論標誌是透過 HTTP 或 HTTPS 顯示，都必須經過快取。當您在含有該標誌的後端服務中自訂快取金鑰時，請取消選取「Protocol」(通訊協定) 核取方塊，這樣透過 HTTP 和 HTTPS 的要求都會視為符合該標誌的快取項目。
如要瞭解如何自訂快取金鑰，請參閱「使用快取金鑰」。
發揮最大效能
建議您採用下列做法，盡量提升成效。
確認已啟用 HTTP/3 和 QUIC 通訊協定支援
HTTP/3 是新一代的網際網路通訊協定。這項通訊協定是以 QUIC 為基礎建構而成，而 QUIC 則是從原始的 Google QUIC (gQUIC) 通訊協定開發而來。外部 HTTP(S) 負載平衡器、Cloud CDN 和用戶端之間支援 HTTP/3。
如要透過 Cloud CDN 提升效能，請確保已啟用 HTTP/3。
使用負面快取
負面快取可精細控管一般錯誤或重新導向的快取功能。當 Cloud CDN 遇到特定回應代碼時，會將該回應保留在快取中一段時間 (TTL)。這麼做可以減少來源的負載量，並縮短回應延遲時間來改善使用者體驗。
啟用 TLS 早期資料
使用 TLS 早期資料可將連線續傳率提高 30 % 至 50%。如要啟用 TLS 早期資料，請使用 gcloud compute target-https-proxies update 指令搭配 tls-early-data 選項。詳情請參閱「設定 TLS 早期資料」。
您可以在 STRICT 或 PERMISSIVE 模式中啟用 TLS 早期資料。
STRICT：針對沒有其他查詢參數的冪等方法 (GET、HEAD、OPTIONS和TRACE) 啟用早期資料。這是較安全的方法，適用於大多數情況。PERMISSIVE：啟用冪等方法的早期資料，可包含查詢參數。使用這個模式時，請務必密切監控應用程式行為和安全狀態。
如果早期資料要求使用非冪等 HTTP 方法或含有查詢參數，系統會拒絕要求，並傳回 HTTP 425 狀態碼。
資安營運最佳化
建議您採取下列做法，盡可能提升安全性。
使用 Google Cloud Armor
Cloud Armor 與 Cloud CDN 整合，可保護快取和非快取或快取未命中的內容。建議盡可能搭配使用 Cloud Armor 和 Cloud CDN，以提高網路應用程式的安全性。
使用已簽署的網址
如果您使用已簽署的網址，請注意下列事項：
將公開和私人內容分別存放在不同的 Cloud Storage bucket。
遵循安全性最佳做法。
驗證私人來源
原始伺服器驗證可強力保證要求只來自您設定的後端服務。此外，這項服務還會保護傳輸中的要求資料，並防止重複使用要求的簽署部分。
建議使用 Amazon S3 儲存貯體或相容物件儲存庫的私有來源驗證。私有來源驗證可確保只有信任的連線能存取私有來源的內容，且使用者無法直接存取。
此外，如果原始防火牆會禁止存取原始伺服器，請使用 IP 許可清單，確保要求來自 Cloud CDN 或外部應用程式負載平衡器。不過，這無法阻止其他 Media CDN 客戶在設定中指定您的來源，藉此嘗試存取您的內容。
最佳化快取
建議採用下列做法，充分發揮快取功能。
最佳化快取存留時間
您可以設定或覆寫 TTL，微調 Cloud CDN 快取回應的時間長度，以及 Cloud CDN 重新驗證回應的時間。
您也可以定義面向用戶端的存留時間，充分利用瀏覽器快取。
詳情請參閱「使用存留時間設定和覆寫」。
設定時效性內容的到期時間
Cloud CDN 快取中的每項內容都有相關聯的到期時間，請務必根據您的用途設定適當的到期時間。由於原始伺服器必須重新傳送快取伺服器上到期的內容，所以請務必審慎選擇到期時間。
選擇有效期限的方法之一，是根據內容的更新頻率分類，例如：
- 近乎即時更新，例如：運動活動或交通運輸的即時動態饋給
- 頻繁更新，例如：每週、每日或每小時的天氣訊息或頭版新聞圖片
- 不常更新，例如：網站標誌或 CSS 或 JavaScript 檔案
接著，依內容類別選擇有效期限。例如：5 秒到期時間可能適合近乎即時的運動得分，而一小時到期時間則可能適用於天氣更新。對於儲存在 Cloud Storage 的內容，請使用Cache-Control 中繼資料設定到期時間。當內容經由 Compute Engine 提供時，您可以藉由設定網路伺服器軟體，來控制到期時間。
到期時間由 Cache-Control 標頭中的 max-age 和 s-maxage 值指定。這個標頭是由 HTTP 規格定義。舉例來說，下列 Cache-Control 標頭會將相關聯的內容設為公開可讀取，並可快取，快取到期時間為 72 小時 (259200 秒)：
Cache-Control: public, max-age=259200
如要將快取最大化，請依照快取總覽一文的指示來進行設定。請注意，您可以一併設定 Cache-Control 中繼資料欄位中的 max-age 值和 s-maxage 值，作用方式如下所述：
max-age和s-maxage值以秒為單位。- 「
s-maxage」值僅適用於共用快取，不適用於瀏覽器快取。 - 除非
s-maxage覆寫，否則max-age值會套用至所有快取。
對於不常變更的內容或必須與相關內容一起變更的內容，通常適合使用長到期時間與版本化網址的組合。
使用版本管理網址更新內容
內容版本控制功能會提供相同內容的不同版本，在快取項目到期前向使用者顯示新內容，有效移除舊內容。版本管理功能免費提供，因此建議您將這項功能做為更新可快取內容的預設方法。
如要為內容加上版本，請在網址中加入參數，例如版本號碼。 在網址中加入參數的方法有很多，例如：
新增查詢字串：
file.ext?v=100。如果是後端 bucket，用於版本管理的任何查詢字串都必須在後端 bucket 的設定中指定。詳情請參閱「Cloud Storage 快取鍵的查詢字串納入清單」。
變更檔案名稱：
file.1.0.0.ext或file_v100.ext。變更路徑：
/v100/file.ext。
新增參數時，請變更檔案名稱及網址。這項變更會強制快取忽略任何現有的快取項目。
請謹慎使用失效功能移除內容
使用撤銷功能，即可從 Cloud CDN 分散式快取伺服器中，移除快取項目到期前的內容。撤銷作業完成後即無法復原。
建議您盡量不要使用失效功能，只有在其他方法皆不可行時才使用。 例如您因法律因素或意外上傳而必須移除內容時，撤銷功能非常有用。否則，建議您盡可能使用版本管理功能，或是等待該內容自然到期。Cloud CDN 快取伺服器會定期移除不常存取的內容，以挪出空間存放新內容。30 天未存取的內容將無條件移除。
快取撤銷有頻率限制。
如要進一步瞭解撤銷作業，請參閱快取撤銷總覽。
最佳化上傳檔案一致性
建議採用下列做法，盡量確保檔案上傳作業的一致性。
避免更新現有檔案
請上傳新版本，不要更新現有檔案。
如果是新檔案，請使用不重複的名稱，可包含版本號碼或日期。在檔名中附加版本號碼 (例如 file_v2.css) 或日期 (例如 file_20230806.js)，有助於確保 Cloud CDN 擷取正確的更新版本。不建議在檔案網址中附加參數 (例如 file.css?v=2)，強制擷取新版本，因為這種做法無法解決快取非原子來源檔案更新的風險，也就是說，系統仍可能快取部分或不完整的檔案。
請務必先上傳新版依附元件，再上傳參照這些元件的檔案。這項做法可確保所有參照的檔案都是完整且最新的版本，降低提供部分更新或截斷檔案的風險。
對檔案進行原子更新
如需更新現有檔案，請以原子方式進行。
如果檔案在上傳完成前遭到存取並快取，可能會快取為不完整或截斷的檔案。舉例來說，/index.html 等檔案無法擁有專屬名稱，但可以指向其他擁有專屬名稱的檔案。
如果上傳檔案時使用目標名稱，系統可能會在檔案上傳期間快取不完整的檔案，導致檔案無法正常存取。請改為以暫時名稱上傳檔案，並在上傳完成後再重新命名為目標名稱。這麼做可確保在參照檔案時，檔案能立即完整提供。
更新現有檔案時，位元組範圍快取可能會導致 Cloud CDN 在上傳新檔案後，仍保留舊檔案的範圍。如果 Cloud CDN 已快取先前檔案的範圍，要求遺失的區塊可能會導致部分回應。發生這種情況的原因是 Cloud CDN 偵測到原始檔案已變更 (因為 etag 或 last-modified 變更)，因此刪除所有過時內容、中斷所有進行中的下載作業，並產生錯誤，提示用戶端重試。如要解決這個問題，請針對正在更新的位元組範圍快取檔案發出失效要求。
最佳化監控與記錄
建議採用下列做法，盡量提升 Monitoring 和 Logging 的效能。
確保已啟用 Cloud CDN 的記錄功能
管理 Cloud CDN 的最佳做法是確保所有已啟用 Cloud CDN 的後端都已啟用記錄功能。
使用 Cloud CDN 的自訂監控資訊主頁
為確保更高的可靠性和效能，最佳做法是定期查看與 Cloud CDN 相關的監控指標。建議您先從 Cloud CDN 自訂監控資訊主頁著手。
查看第三方效能測試
查看第三方供應商的報告，例如 Citrix Radar 提供的可用性、延遲時間和總處理量報告。