內容傳遞最佳做法

本頁面提供透過 Cloud CDN 最佳化和加速內容傳遞的最佳做法。這些部分分為幾個重點領域。

Cloud CDN 會使用外部應用程式負載平衡器做為可快取內容的來源，外部應用程式負載平衡器可透過一個公網 IP 位址，將混合靜態和動態內容的資料從下列類型的後端傳遞給使用者：

由於與 Google Cloud完美整合，您可以透過多種方式部署 Cloud CDN 及管理內容。請參考下列最佳做法，規劃及調整部署作業。詳情請參閱「設定 Cloud CDN」。

改善快取命中率

下列最佳做法有助於改善快取命中率。

快取靜態內容

為改善效能，建議您在啟用 Cloud CDN 時，為應用程式選擇正確的快取模式。

管理快取規則最靈活且最常見的方法，就是使用快取控制標頭。如果您不熟悉如何使用來源快取控制標頭，最佳做法建議是允許 Cloud CDN 自動快取靜態內容。

如要自動快取來源的靜態回應，您可以使用 --cache-mode=CACHE_ALL_STATIC 設定 (預設)。當來源未在回應標頭中指定任何快取指示時，這項設定可讓 Cloud CDN 快取常見的靜態內容類型。請確認內容符合上述類別，否則系統不會快取內容。

不要快取使用者特定內容

在某些情況下，瀏覽器可以快取特定使用者的內容。請勿使用 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 早期資料，請搭配使用 tls-early-data 選項的 gcloud compute target-https-proxies update 指令。詳情請參閱「設定 TLS 早期資料」。

您可以在 STRICT 或 PERMISSIVE 模式中啟用 TLS 早期資料。

  • STRICT：啟用冪等方法 (GET、HEAD、OPTIONS 和 TRACE) 的早期資料，這些方法沒有其他查詢參數。這是較安全的方法，適用於大多數情況。
  • PERMISSIVE：啟用可包含查詢參數的冪等方法的早期資料。使用這個模式時，您必須密切監控應用程式行為和安全性狀態。

採用非冪等 HTTP 方法或含有查詢參數的早期資料要求會遭到拒絕，並傳回 HTTP 425 狀態碼。

提升安全性

下列最佳做法有助於提升安全性。

使用 Google Cloud Armor

Google Cloud Armor 可與 Cloud CDN 整合，處理快取和未快取或快取失敗的內容。最佳做法建議是盡可能搭配使用 Google Cloud Armor 和 Cloud CDN，以提高網路應用程式的安全性。

使用已簽署的網址

如果您使用的是已簽署網址，請注意下列事項：

驗證私人來源

原始來源驗證可提供強力保證，確保要求只來自您自行設定的後端服務。它還可為要求提供傳輸中資料保護功能，並防止要求的已簽署部分重複使用。

建議您為 Amazon S3 儲存貯體或相容物件儲存庫使用私人來源驗證。私人來源驗證可確保只有可信任的連線可存取私人來源的內容，而使用者無法直接存取這些內容。

此外，如果原始來源防火牆阻止存取原始來源，請使用 IP 許可清單，確保要求來自 Cloud CDN 或外部應用程式負載平衡器。不過，這不會阻止其他 Media CDN 客戶在其設定中指定您的來源，嘗試存取您的內容。

最佳化快取

下列最佳做法有助於最佳化快取。

最佳化快取存留時間

您可以設定或覆寫 TTL，以微調 Cloud CDN 快取回應的時間長度，以及 Cloud CDN 重新驗證回應的時間。

您也可以定義用戶端的 TTL，充分利用瀏覽器快取。

詳情請參閱「使用存留時間設定和覆寫值」。

設定時間敏感內容的到期日

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 變更)，因此會刪除任何過時的內容、中斷任何正在進行的下載作業，並產生錯誤，促使用戶端重試。為緩解這個問題，請針對正在更新的位元組範圍快取檔案發出無效化作業。

最佳化監控和記錄

下列最佳做法有助於提升監控和記錄功能的效能。

確保已啟用 Cloud CDN 的記錄功能

管理 Cloud CDN 的最佳做法是確保所有啟用 Cloud CDN 的後端都已啟用記錄功能。

使用 Cloud CDN 的自訂監控資訊主頁

為確保更高的可靠性和效能，最佳做法是定期查看與 Cloud CDN 相關的監控指標。建議您從 Cloud CDN 自訂監控資訊主頁著手。

查看第三方成效測試

查看第三方供應商的報告，例如 Citrix Radar 提供的可用性、延遲時間和總處理量報告。