啟用動態壓縮

動態壓縮功能會自動壓縮 Media CDN 所提供的回應。透過網路傳送的資料大小會減少 60% 至 85% (一般情況)。

縮減大小可加快下載重要素材資源的速度，例如樣式表 (CSS)、指令碼 (JavaScript) 和影片資訊清單 (HLS/DASH)，進而大幅縮短網頁載入和影片開始播放的時間。

大型直播影片播放清單 (資訊清單) 會產生大量重複資料和擷取作業，包括每個區隔的主機和路徑前置字串，以及 HLS 或 DASH 播放清單中繼資料。播放清單載入或下載播放清單更新的速度越快，用戶端需要等待解析並開始下載參照的影片片段所需的時間就越短。HLS 和 DASH 播放清單通常會經歷總大小縮減 90% 以上的過程。

如要進一步瞭解壓縮回應的好處，請參閱網站基礎知識指南。

動態壓縮的運作方式

啟用動態壓縮功能後，如果用戶端接受其中一個支援的壓縮演算法 (br 或 gzip)，則從來源提供的可壓縮內容可在傳送前先行壓縮。

Media CDN 會在所有可壓縮的回應中加入 Vary: Accept-Encoding 標頭。如需相關資訊，請參閱「無法壓縮的內容」。

此外，如果要求的 Accept-Encoding 標頭透過指定 br 或 gzip (並視需要納入非零值 q 參數) 表示偏好壓縮內容，Media CDN 會執行以下操作：

• 從回應中移除 Content-Length 標頭。這是必要的，因為在整個回應經過壓縮後，才能得知完整內容長度，因此必須盡快提供回應。針對 HTTP/1.1 和更早版本，Media CDN 會在回應中使用 Transfer-Encoding: chunked (如果不使用 Content-Length)。

  回應經過壓縮及快取後，Media CDN 可以在後續回應中加入 Content-Length 標頭，並將值設為壓縮內文內容的長度。

• 將 Accept-Ranges 設為 none。這會通知用戶端，系統會忽略這項資源的範圍要求。

• 根據 RFC 9110 的第 8.8.3 節規定，弱化任何強式 ETag 回應標頭。例如，ETag: "xyzzy" 會替換成 ETag: W/"xyzzy"。

• 將 Content-Encoding 標頭設為 br 或 gzip，代表所選的壓縮演算法。

  Media CDN 會根據回應的預期壓縮比率和壓縮速度或處理量，選擇最佳的壓縮演算法。

  • 如果用戶端支援 Brotli 壓縮，系統就會使用 Brotli 壓縮，即使其他壓縮演算法在 Accept-Encoding 標頭中具有較高的 q 值也是如此。

  • HLS 資訊清單僅使用 gzip 進行壓縮。

  Media CDN 會判斷壓縮等級，以平衡用戶端的總下載大小和 CPU 成本。較高的壓縮等級不一定能提升效能，尤其是在效能較低的行動裝置上。

設定動態壓縮

您可以在提供要求的路徑上啟用動態壓縮功能。

事前準備

請執行下列步驟：

• 找出或建立 Media CDN 來源，並使用可供服務的可壓縮內容。

• 找出或建立 Media CDN 服務，並至少設定一項路徑規則。

為路由規則啟用動態壓縮

根據預設，路由規則的壓縮模式會停用。

將模式設為自動，即可為所有符合資格的回應啟用動態壓縮功能。此外，它會指示 Media CDN 自動選擇最佳壓縮演算法。

如要啟用動態壓縮，請按照下列步驟操作：

route_rule {
  description = "a route rule with dynamic compression, priority=2 (high)"
  priority    = 2
  match_rule {
    path_template_match = "/**.m3u8" # HLS playlists
  }
  match_rule {
    path_template_match = "/**.mpd" # DASH manifests
  }
  origin = google_network_services_edge_cache_origin.default.name
  route_action {
    cdn_policy {
      cache_mode = "FORCE_CACHE_ALL"
      client_ttl = "300s"
    }
    compression_mode = "AUTOMATIC"
  }
  header_action {
    response_header_to_add {
      header_name  = "x-cache-status"
      header_value = "{cdn_cache_status}"
    }
  }
}

設定很快就會套用至所有邊緣位置。

為路由啟用動態壓縮功能，並讓新設定在實際機器上生效後，Media CDN 就會開始壓縮符合資格的回應，即使已快取未壓縮的版本也一樣。當媒體 CDN 擷取及壓縮新內容時，原始來源的流量可能會暫時出現高峰。

停用路由規則的動態壓縮功能

如要停用動態壓縮，請執行下列步驟：

如果您在特定路徑上遇到動態壓縮問題 (例如某些用戶端 (例如智慧型電視或串流裝置) 的相容性問題)，為避免 Media CDN 在該路徑上提供壓縮內容，請停用動態壓縮功能。

為路徑停用動態壓縮功能後，Media CDN 就會停止從快取中提供壓縮內容。所有先前快取的壓縮回應都會失效，CDN 會從來源擷取未壓縮的版本。

可壓縮的內容類型

動態壓縮會根據 Content-Type HTTP 回應標頭，套用至下列 MIME 類型。不含 Content-Type 標頭的回應不會壓縮。

常見的內容類型及其 MIME 類型包括：

• HTML 內容：text/html
• 樣式表：text/css
• JavaScript：application/javascript
• JSON：application/json
• HLS 播放清單：application/x-mpegURL 或 application/vnd.apple.mpegURL
• DASH 資訊清單：application/dash+xml

下表概要說明 MIME 類型對壓縮率的影響。

圖片和影片格式 (例如 image/jpeg、image/png 和 video/mpeg4) 幾乎都已壓縮過。因此，Media CDN 不會壓縮這些檔案。重新壓縮已壓縮的回應，很少能縮減檔案大小，而且在收到這類回應時，用戶端可能會出現非預期行為。

無法壓縮的回應

Media CDN 不會壓縮具有下列一或多項特性的回應：

• 回應中沒有與可壓縮內容類型相符的 Content-Type 標頭。
• 回應沒有 Content-Length 標頭。
• 回應包含 Content-Encoding 標頭。這表示來源已壓縮回應。因此，Media CDN 不得進行任何額外的動態壓縮。

• 回應大小小於 1 KiB。

  壓縮和解壓縮所需的時間通常會抵銷任何好處。壓縮的內容也較少，因此壓縮效率會降低，壓縮比也會隨之下降。

• 回應大小超過 1 MiB。

  Media CDN 會將回應壓縮至快取物件允許的大小，但不包含位元組範圍快取。

• 回應包含 Cache-Control: no-transform 標頭。

• 回應包含 Vary: Accept-Encoding 標頭，表示來源可以壓縮回應，因此不需要動態壓縮。

記錄和監控

啟用壓縮功能後，edgecache.googleapis.com/EdgeCacheRouteRule 下方的現有 https/response_bytes_count 指標會回報壓縮的回應大小。對於可壓縮的內容，回應位元組總數和傳出資料傳輸吞吐量可能會下降。

Media CDN 記錄會在 jsonPayload 中加入 compressionAlgorithmApplied 欄位，指出回應是否已由負載平衡器壓縮，以及壓縮類型。

{
  insertId: "1c02hw9g3gjay67"
  jsonPayload: {
    @type: "type.googleapis.com/google.cloud.edgecache.v1.EdgeCacheLogEntry",
    cacheId: "IAD-862d661f",
    cacheStatus": "hit,stale",
    compressionAlgorithmApplied: "br"
  },
}

帳單

當 Media CDN 壓縮回應時，相關的傳出快取或網際網路資料移轉費用會根據傳送至用戶端的最終壓縮位元組計算。

如果您提供大量可壓縮的回應，這可能會降低每月傳出資料傳輸費用，並提升使用者效能。

後續步驟

• 設定服務路徑
• 設定要求記錄