來源總覽

無論內容是託管於 Google Cloud、其他雲端或地端，Media CDN 都能從原始基礎架構擷取內容。

每項設定可關聯一或多個來源。來源設定會告知 Media CDN 如何連線至基礎架構、何時及如何容錯移轉、重試和逾時，以及連線時要使用的通訊協定。

來源具有下列功能：

• 來源可依主機和路徑定義，因此單一 EdgeCacheService 資源可對應至多個來源，例如包含資訊清單、影片片段和其他靜態內容。
• 來源可透過 HTTP/2、HTTPS 和未加密的 HTTP/1.1 存取。
• 重試和容錯移轉行為是依來源設定，可讓服務在發生嚴重錯誤 (例如連線失敗) 時容錯移轉，或根據 HTTP 404 Not Found 或 HTTP 429 Too Many Requests 回應重試。
• 如要存取 Google Cloud 或內部部署的私人資源，請在 Media CDN 後方將外部應用程式負載平衡器設定為來源。
• 系統會針對每個來源設定重新導向追蹤行為。您可以啟用 Media CDN，讓系統將重新導向至其他原始伺服器。

來源規定

如要允許 Media CDN 快取大於 1 MiB 的原始伺服器回應，原始伺服器必須在 HEAD 和 GET 要求的相關回應標頭中加入下列項目 (除非另有規定)：

• Last-Modified 或 ETag HTTP 回應標頭 (驗證器)。
• 有效的 HTTP Date 標頭。
• 有效的 Content-Length 標頭。
• Content-Range 回應標頭，用來回應 Range GET 要求。Content-Range 標頭必須有 bytes x-y/z 格式的有效值 (其中 z 是物件大小)。

預設來源通訊協定為 HTTP/2。如果來源僅支援 HTTP/1.1，您可以為每個來源明確設定通訊協定欄位。

來源防護

Media CDN 提供多層式邊緣基礎架構，目的是盡可能主動減少快取填充作業。

快取基礎架構主要有三層：

1. 深層邊緣快取，可處理大部分流量，並在服務供應商網路中卸載。
2. Google 的對等互連邊緣，與數千個網際網路服務供應商 (ISP) 連線，可做為邊緣快取的中層快取，如果特定 ISP 內沒有這些快取，則可做為面向使用者的快取。
3. Google 網路中的長尾快取，其他下游快取會從來源之前填補。這些快取支援大量扇入，具有充足的快取儲存容量，並做為原始伺服器防護。

這個拓撲的總覽如下所示：

Media CDN 預設會使用一組有限的全球主要位置，提供來源防護機制。預設來源遮蔽功能會根據使用者的位置運作，而非來源位置。如果使用者與來源伺服器位於相同區域，且全域來源伺服器位於多個區域，這種做法可發揮良好效果，並提供強大的卸載優勢。

彈性防護

如果來源集中在一個地區，但使用者分布在全球各地，根據使用者位置資訊的預設來源遮蔽行為可能無法發揮最佳效果，原因如下：

• 如果預設防護罩位置與集中式來源在地理位置上相距遙遠，快取未命中時的延遲時間會增加
• 將快取填入要求分散到多個全球預設防護位置，而非集中處理，藉此減少來源卸載

彈性遮蔽功能可讓您為來源遮蔽設定單一特定地理區域，通常會選取靠近集中式來源的區域，藉此克服這些限制。彈性防護功能會將所有快取填入要求，透過位於或鄰近設定區域的防護快取轉送。這會透過這些以區域為主的快取，將負載整合至來源。

在與集中式來源相同的地理區域中設定彈性防護區域，即可提升下列項目的效能：

• 防護層的快取命中率
• 來源卸載
• 快取失敗和無法快取內容的延遲時間
• 效能穩定性

彈性防護功能與 Media CDN 中設定的任何來源類型都相容。

要求摺疊

要求摺疊功能會主動將每個邊緣節點中，針對相同快取金鑰的多個使用者導向快取填補要求，摺疊成單一原始要求。

所有快取層都支援要求摺疊 (或合併)，進一步減少原始負載。根據大規模觀察到的實際工作負載：

• 超過 95% 的快取填補作業會使用區域內的專屬長尾快取節點，以減少快取填補成本和延遲時間。
• 來源與 Google 邊緣基礎架構之間的快取填補作業，完全透過 Google 全球私人骨幹網路進行，可減少快取填補延遲時間並提升可靠性，這兩項優勢對即時串流工作負載來說都非常實用。
• 快取會視情況互相填補，進一步降低快取填補率。
• Media CDN 的快取儲存容量相當大，即使是較不熱門的長尾內容，也能盡量減少逐出率。

視快取設定、使用者負載、工作負載 (例如直播與隨選)、使用者分布情形，以及向各區域使用者放送的長尾內容量 (總語料庫大小) 而定，客戶可能會看到不同的卸載率。

搭配來源防護功能，要求摺疊可進一步減少來源負載和輸出頻寬需求，也是 Media CDN 的預設行為。

如果要求已收合，系統會記錄面向用戶端的要求，以及 (收合) 快取填入要求。系統會使用已收合工作階段的領導者發出原始填滿要求，這表示原始檔只會看到該用戶端的標頭 (包括 User-Agent)。

如果要求未共用相同的快取金鑰，就無法摺疊。

起源連線

以下各節說明 Media CDN 如何連線至來源、如何發出 HTTP 要求，以及如何驗證要求。

支援的來源和通訊協定

Media CDN 直接支援任何可公開存取的 HTTP 端點做為來源，包括：

• Cloud Storage 值區，包括透過 Identity and Access Management 服務帳戶存取的私人值區
• 外部應用程式負載平衡器
• 與 Amazon S3 相容的值區，包括使用 AWS Signature 第 4 版的私有值區
• 其他公開可用的物件儲存空間，例如 Azure Blob 儲存體
• 公開可用的網路伺服器，例如公開 VM 或地端主機

連線至來源時，會透過安全通道和 Google 的全球骨幹網路。

下表詳細列出支援的來源通訊協定。

通訊協定	支援	必須符合 SSL (TLS) 規定
HTTP/2	是 (預設)	是
HTTPS (透過 TLS 的 HTTP/1.1)	是	是
HTTP/1.1	是	否

Media CDN 預設會使用 HTTP/2 (h2) 連線至來源。HTTP/2 和 HTTPS 都需要有效的公開信任 TLS (SSL) 憑證。有效憑證是指未過期、由公開憑證授權單位簽署，且主體別名與傳送至來源的主機名稱相符的憑證。

注意：

• 如果來源不支援 HTTP/2，您可以明確將通訊協定 (以來源為單位) 設為 HTTP (HTTP/1.1) 或 HTTPS (透過 TLS 的 HTTP/1.1)。
• 將來源通訊協定設為 HTTPS 或 HTTP/1.1 時，Media CDN 不會交涉替代通訊協定 (例如 HTTP/2)。同樣地，設定 HTTP/2 時，連線不會改回 HTTP/1.1，以明確指出來源連線行為。
• Media CDN 會根據通訊協定自動使用正確的通訊埠：HTTP 使用通訊埠 80，HTTPS 和 HTTP/2 使用通訊埠 443。

來源要求標頭

連線至來源時，Media CDN 預設會使用用戶端要求的 Host 標頭。

下表記錄在不同設定情境下，來源在傳入要求中看到的內容：

用戶端要求	EdgeCacheService.hostRewrite	EdgeCacheOrigin.hostRewrite	originAddress	主機標頭 / 來源的 TLS SNI
media.example.com	無	無	backend.example.com	media.example.com
media.example.com	service.example.com	無	backend.example.com	service.example.com
media.example.com	無	origin.example.com	backend.example.com	origin.example.com
media.example.com	service.example.com	origin.example.com	backend.example.com	origin.example.com
media.example.com	service.example.com	origin.example.com	gs://vod-content-bucket	根據 bucket 名稱自動設定

如果主要來源和任何容錯移轉來源共用相同的 routeRule 或 hostRewrite 設定，就會看到相同的主機標頭。

使用 Cloud Storage 值區做為來源時，系統會忽略所有 hostRewrite 設定，因為 Cloud Storage 值區不支援替代主機標頭值。系統會根據 bucket 名稱自動設定主機標頭。

要求中的 TLS SNI (伺服器名稱指標) 值 (適用於 HTTP/3、HTTP/2 和 HTTPS 要求) 會設為與傳送至來源的主機標頭相同的值。

如要瞭解如何為每個路徑設定重寫主機標頭，請參閱「設定服務路徑」。如要瞭解如何設定每個來源的覆寫動作，請參閱不重新導向的來源容錯移轉。

容錯移轉和逾時

以下各節會說明這些設定選項：

• 逾時：決定 Media CDN 等待連線至來源或回應要求的時間長度。
• 重試：判斷 Media CDN 是否會重試對來源的來源 HTTP 要求，以及重試的條件。
• 容錯移轉：判斷 Media CDN 是否會在第一個來源無法使用或傳回特定狀態碼時，嘗試連線至容錯移轉來源。

來源逾時

您可以透過逾時設定，設定觸發來源重試和容錯移轉行為的時間，以及觸發後續用戶端容錯移轉的時間。

以下說明 Media CDN 支援的可設定逾時：

• connectTimeout 和 maxAttemptsTimeout 會限制 Media CDN 尋找可用回應的時間。

  這兩種逾時都包含來源傳回標頭的時間，以及判斷是否要使用容錯移轉或重新導向的時間。connectTimeout 會針對每次嘗試連線至來源的作業獨立套用，而 maxAttemptsTimeout 則包含所有嘗試連線至來源的作業所需時間，包括容錯移轉和重新導向。系統會將重新導向視為額外嘗試連線至來源，並計入已設定來源的 maxAttempts。

  如果 Media CDN 遇到非重新導向的回應 (例如來自重新導向或容錯移轉來源)，系統會套用 readTimeout 和 responseTimeout 值。重新導向的來源會使用為 EdgeCacheOrigin 設定的 connectTimeout、readTimeout 和 responseTimeout 值，而 EdgeCacheOrigin 遇到重新導向。

• responseTimeout 和 readTimeout 可控制串流回覆的耗時長度。Media CDN 決定要使用上游回應後，connectTimeout 和 maxAttemptsTimeout 就不重要了。此時，readTimeout 和 responseTimeout 會生效。

無論各個 EdgeCacheOrigin 設定的 maxAttempts 為何，Media CDN 最多會嘗試連線至所有來源四次。Media CDN 會使用主要 EdgeCacheOrigin 中的 maxAttemptsTimeout 值。系統會為每次嘗試設定每次嘗試的逾時值 (connectTimeout、readTimeout 和 responseTimeout)。EdgeCacheOrigin

下表說明逾時欄位：

欄位	預設	說明
connectTimeout	5 秒	從開始向來源發出要求，到 Media CDN 判斷回應是否可用為止，Media CDN 最多可花費的時間。實際上，connectTimeout 涵蓋的時間範圍，從建立要求開始，然後進行 DNS 查詢、TLS 握手、建立 TCP/QUIC 連線，一直到取得包含 HTTP 狀態碼的回應標頭為止。 逾時時間值必須介於 1 秒至 15 秒。
maxAttemptsTimeout	15 秒	所有來源 (包含容錯移轉來源) 連線嘗試的最長持續時間，超過此時間系統即會將錯誤傳回用戶端。如果未在逾時前收到回應，系統會傳回 HTTP 504。 逾時時間值必須介於 1 秒至 30 秒。 這項設定會定義所有來源 (包括容錯移轉來源) 連線嘗試的總時間長度，以限制用戶端等待內容開始串流的總時間。系統只會使用第一個 maxAttemptsTimeout 值，其中「第一個」是由指定路徑設定的來源所定義。
readTimeout	15 秒	單一 HTTP 回應讀取作業之間的等待時間上限。readTimeout 的上限為 responseTimeout。 所有 HTTP 回應的讀取作業都必須在 responseTimeout 設定的期限內完成。逾時時間必須介於 1 秒至 30 秒。如果回應未在逾時前完成，系統會截斷回應並記錄。
responseTimeout	30 秒	允許完成回覆的時間上限。 逾時時間值必須介於 1 秒至 120 秒之間。 這段時間的起算點為收到第一個主體位元組的時間。如果回應未在逾時前完成，系統會截斷回應並記錄。

請見以下範例：

• Origin A 會比對對「/segments/」的請求，且 maxAttemptsTimeout 值為 5s、maxAttempts 值為 1，以及 failover_origin 值為 Origin B。connectTimeout 值為預設值 5s。如果您嘗試連線至 Origin A，但因 TLS 憑證無效而在一秒內連線失敗，您還有約 4 秒的時間可成功連線至 Origin B。

• Origin C 會將要求比對至「/manifests/*」，且 maxAttemptsTimeout 值為 10s、maxAttempts 值為 3，且 failover_origin 未設定。connectTimeout 值為預設值 5s。Media CDN 最多會嘗試連線至 Origin C 三次，最多允許 10 秒 (maxAttemptsTimeout 限制) 建立連線。

重試來源要求

Media CDN 支援來源重試，可重試傳送至來源的失敗要求。您可以指定在嘗試容錯移轉來源 (如有設定) 前，目前來源可重試的次數。

• Media CDN 會嘗試連線至主要來源，最多可達設定的 maxAttempts 值，預設為 1。
• Media CDN 最多會重試來源連線三次，如果仍失敗，就會傳回 HTTP 502 Bad Gateway 錯誤給使用者。這包括任何容錯移轉來源連線，這些連線會計入三項限制。
• 設定來源資源時，您可以使用 originAddress 欄位設定主要來源，然後設定選用的 failoverOrigin。 failoverOrigin 指向另一個來源資源。

每個來源的 retryConditions 都會指定哪些類型的失敗會觸發重試：

條件	預設	說明
CONNECT_FAILURE	✔️	失敗時重試，包括轉送、DNS、傳輸層安全標準 (TLS) 握手錯誤和 TCP/UDP 逾時。
HTTP_5XX		在任何 HTTP 5xx 狀態碼上重試。
GATEWAY_ERROR		與 5xx 類似，但僅適用於狀態碼 502、503 或 504。
RETRIABLE_4XX		針對可重試的 4xx 狀態碼 (包括 409 和 429) 進行重試。
NOT_FOUND		在 HTTP 404 狀態碼上重試。
FORBIDDEN		在 HTTP 403 狀態碼上重試。

如果需要跨來源進行主動健康狀態檢查、循環式或負載感知式導向，可以將外部應用程式負載平衡器設定為主要來源。

容錯移轉行為

下表說明容錯移轉的運作方式，以及用戶端會觀察到的回應：

情境	已設定容錯移轉	向使用者顯示的狀態
Media CDN 嘗試連線至來源，但兩次嘗試後 (預設) 均未收到 HTTP 回應。	否	HTTP 502 Bad Gateway
Media CDN 嘗試連線至主要來源，但連線失敗 (TLS 交握錯誤)。系統會嘗試連線至您設定的容錯移轉來源，但該來源傳回 HTTP 404 錯誤。	是	HTTP 404 Not Found
Media CDN 嘗試連線至主要和容錯移轉來源，但未收到 HTTP 狀態碼。	是	HTTP 502 Bad Gateway

如果 Media CDN 收到與任何已設定 retryConditions 相符的狀態碼 (例如 HTTP 404 Not Found 或 HTTP 429 Too Many Requests 錯誤)，且後續的重試和容錯移轉來源要求持續失敗，系統會在來源嘗試次數用盡後，將 HTTP 502 Bad Gateway 錯誤傳回給用戶端。

來源容錯移轉的最佳做法

為容錯移轉或負載平衡設定多個來源時，請確認媒體內容和 Vary、ETag 和 Last-Modified 標頭行為在來源之間保持一致。

最佳做法是只為您信任及控管的來源設定來源重新導向。請務必信任重新導向鏈結中的每個來源，因為每個來源都會產生由 EdgeCacheService 放送的內容。

後續步驟

• 設定來源
• 使用私人的 Amazon S3 相容儲存空間做為來源
• 設定服務路徑