快取如何運作 \(機器翻譯\)
重要
Azure CDN Standard from Microsoft (classic) 將於 2027 年 9 月 30 日淘汰。 為了避免任何服務中斷,請務必在 2027 年 9 月 30 日之前,移轉您的 Azure CDN Standard from Microsoft (classic) 設定檔至 Azure Front Door Standard 或 Premium 層。 如需詳細資訊,請參閱 Azure CDN Standard from Microsoft (classic) 淘汰。
來自 Edgio 的 Azure CDN 將於 2025 年 11 月 4 日淘汰。 您必須在此 日期之前將工作負載 移轉至 Azure Front Door,以避免服務中斷。 如需詳細資訊,請參閱來自Edgio的 Azure CDN 淘汰常見問題。
本文提供一般快取概念,以及 Azure 內容傳遞網路如何使用快取來改善效能的總覽。 如果您需要了解如何在內容傳遞網路端點上自訂快取行為,請參閱使用快取規則控制 Azure 內容傳遞網路快取行為和使用查詢字串控制 Azure 內容傳遞網路快取行為。
快取簡介
快取是在本機儲存資料的程序,以便未來可以更快速地存取對該資料的要求。 在網頁瀏覽器快取這個最常見的快取類型中,網頁瀏覽器會在本機硬碟上本機儲存靜態資料的複本。 網頁瀏覽器可以使用快取來避免多次往返伺服器,並改為在本機存取相同的資料,因此能節省時間和資源。 快取非常適用於本機管理小型的靜態資料,例如靜態映像、CSS 檔案和 JavaScript 檔案。
同樣地,內容傳遞網路會在接近使用者的邊緣伺服器上使用快取,來避免要求移回原點及減少使用者延遲。 不同於僅用於單一使用者的網頁瀏覽器快取,內容傳遞網路具有共用快取。 在內容傳遞網路共用快取中,其他使用者可以使用使用者提出的檔案要求,這可大幅減少對原始伺服器的要求數目。
無法快取經常變更或個別使用者特有的動態資源。 不過,這些類型的資源,可以利用 Azure 內容傳遞網路上的動態站台加速 (DSA) 最佳化來改進效能。
原始伺服器與使用者之間的多個層級可能會發生快取:
- 網頁伺服器:使用共用快取 (適用於多個使用者)。
- 內容傳遞網路:使用共用快取 (適用於多個使用者)。
- 網際網路服務提供者 (ISP):使用共用快取 (適用於多個使用者)。
- 網頁瀏覽器:使用私人快取 (適用於一位使用者)。
每個快取通常會管理它自己的資源有效期限,並在檔案過期時執行驗證。 在 HTTP 快取規格 RFC 7234 中會定義此行為。
資源有效期限
因為快取的資源可能會過期或是過時 (相較於原始伺服器上的對應資源),任何快取機制都必須能夠控制內容重新整理的時間。 為了節省時間和頻寬耗用量,快取的資源並不會在每次存取時都比較原始伺服器上的版本。 相反地,只要快取的資源被視為是全新的,就會假設是最新版本,並直接傳送至用戶端。 當快取資源的存在時間小於快取設定所定義的存在時間或期間,就會視為全新的。 例如,當瀏覽器重新載入網頁時,它會驗證您硬碟機上的每個快取資源是最新的,並將其載入。 如果資源不是最新 (過時) 的,就會從伺服器載入最新的複本。
驗證
如果資源被視為過時,就會要求原始伺服器進行驗證,以判斷快取中的資料是否仍符合原始伺服器上的資料。 如果已在原始伺服器上修改檔案,快取就會更新其資源的版本。 否則,如果資源是新的,就會直接從快取傳遞資料,而無須事先驗證。
內容傳遞網路 (CDN) 快取
快取對於內容傳遞網路的運作方式是整數,可加速傳遞並減少靜態資產的來源載入,例如映像、字型及影片。 在內容傳遞網路快取中,靜態資源會選擇性地儲存在策略性放置的伺服器上,對於使用者較接近本機,並提供下列優點:
因為大部分的網路流量都是靜態的 (例如映像、字型和視訊),內容傳遞網路快取會降低網路延遲,方法是將內容移至更接近使用者,從而降低資料傳送的距離。
快取可以透過卸載內容傳遞網路的工作來減少網路流量,以及在原始伺服器上的負載。 這樣做可以降低應用程式的成本和資源需求,即使是有大量使用者時也一樣。
類似於快取在網頁瀏覽器中實作的方式,您可以傳送快取指示詞標頭來控制快取在內容傳遞網路中執行的方式。 快取指示詞標頭是 HTTP 標頭,通常是由原始伺服器所新增。 雖然這些標頭大部分都是原本就設計用於處理用戶端瀏覽器中的快取,現在有的中繼快取也會使用這些標頭,例如內容傳遞網路。
可以使用兩個標頭來定義快取有效期限:Cache-Control
和 Expires
。 Cache-Control
較新,且如果同時存在,會優先於 Expires
。 另外還有兩種類型的標頭會用於驗證 (稱為驗證程式):ETag
和 Last-Modified
。 ETag
較新,且如果同時定義,會優先於 Last-Modified
。
快取指示詞標頭
重要
根據預設,已針對 DSA 最佳化的 Azure 內容傳遞網路端點會忽略快取指示詞標頭並略過快取。 針對來自 Edgio 的標準 Azure 內容傳遞網路設定檔,您可以使用內容傳遞網路快取規則來啟用快取,以調整 Azure CDN 端點處理這些標頭的方式。 僅針對來自 Edgio 的進階 Azure CDN,您需使用規則引擎來啟用快取。
Azure 內容傳遞網路支援下列 HTTP 快取指示詞標頭,這些標頭會定義快取持續時間和快取共用。
Cache-Control:
- 在 HTTP 1.1 中導入,讓 web 發行者能更充分掌控其內容,並處理
Expires
標頭的限制。 - 如果已同時定義
Expires
標頭和Cache-Control
,則覆寫前者。 - 使用於來自用戶端對內容傳遞網路 POP 的 HTTP 要求時,依預設所有 Azure 內容傳遞網路設定檔都會忽略
Cache-Control
。 - 使用來自原始伺服器對內容傳遞網路 POP 的 HTTP 回應時:
- 來自 Edgio 的標準/進階 Azure CDN 和來自 Microsoft 的標準 Azure CDN 支援所有
Cache-Control
指示詞。 - 來自 Edgio 的標準/進階 Azure CDN 和來自 Microsoft 的標準 Azure CDN 會接受 RFC 7234 - 超文字傳輸通訊協定 (HTTP/1.1):快取 (ietf.org) 中 Cache-Control指示詞的快取行為。
- 來自 Edgio 的標準/進階 Azure CDN 和來自 Microsoft 的標準 Azure CDN 支援所有
Expires:
- 在 HTTP 1.0 中導入舊版的標頭;支援回溯相容性。
- 使用以日期作為基礎的到期時間,以秒為有效位數。
- 類似於
Cache-Control: max-age
。 - 使用時機是當
Cache-Control
不存在時。
Pragma:
- 依預設,Azure 內容傳遞網路不遵循。
- 在 HTTP 1.0 中導入舊版的標頭;支援回溯相容性。
- 用來作為用戶端要求標頭,並具有下列指示詞:
no-cache
。 這個指示詞會指示伺服器傳送全新版本的資源。 Pragma: no-cache
等於Cache-Control: no-cache
。
驗證程式
當快取過期時,HTTP 快取驗證程式可用來比較檔案的快取版本與原始伺服器上的版本。 來自 Edgio 的標準/進階 Azure CDN 預設同時支援 ETag
和 Last-Modified
驗證程式,而來自 Microsoft 的標準 Azure CDN 僅支援 Last-Modified
。
ETag:
- 來自 Edgio 的標準/進階 Azure CDN 預設支援
ETag
,而來自 Microsoft 的標準 Azure CDN 則不支援。 ETag
會定義對每個檔案和檔案版本是唯一的字串。 例如:ETag: "17f0ddd99ed5bbe4edffdd6496d7131f"
。- 在 HTTP 1.1 中導入,且較
Last-Modified
更新。 上次修改的日期難以判斷時會很有用。 - 支援強式驗證和弱式驗證;不過,Azure 內容傳遞網路僅支援強式驗證。 針對強式驗證,兩個資源表示法必須是位元組對位元組相同。
- 快取會驗證使用
ETag
的檔案,方法是傳送要求中具有一或多個ETag
驗證程式的If-None-Match
標頭。 例如:If-None-Match: "17f0ddd99ed5bbe4edffdd6496d7131f"
。 如果伺服器的版本符合清單上的ETag
驗證程式,其會在其回應中傳送狀態碼 304 (未修改)。 如果版本不同,伺服器會以狀態碼 200 (確定) 和更新的資源回應。
Last-Modified:
- 僅針對來自 Edgio 的標準/進階 Azure CDN 而言,如果 HTTP 回應中未包含
ETag
,就會使用Last-Modified
。 - 指定原始伺服器判斷上次修改資源的日期和時間。 例如:
Last-Modified: Thu, 19 Oct 2017 09:28:00 GMT
。 - 針對大於 8 MB 的內容,原始後端伺服器應為每個資產維護一致的
Last-Modified
時間戳記。 從後端伺服器傳回不一致的Last-Modified
時間將導致驗證程式不相符錯誤,並發生 HTTP 5XX 失敗。 Azure 儲存體可能不支援複本間一致的Last-Modified
時間戳記,因為這可能會導致相似的驗證程式不相符錯誤。 - 快取會使用
Last-Modified
來驗證檔案,方法是傳送要求中具有日期和時間If-Modified-Since
的標頭。 原始伺服器會比較該日期與最新資源的Last-Modified
標頭。 如果資源從指定時間起尚未修改,伺服器就會在其回應中傳回狀態碼 304 (未修改)。 如果資源已修改,伺服器會傳回狀態碼 200 (確定) 和更新的資源。
判斷哪些檔案可快取
並非所有的資源都可以快取。 下表以 HTTP 回應的類型作為基礎,顯示可以快取哪些資源。 無法快取與不符合所有條件之 HTTP 回應共同傳遞的資源。 僅針對來自 Edgio 的進階 Azure CDN 而言,您可以使用規則引擎來自訂這當中的某些條件。
Microsoft 的 Azure 內容傳遞網路 | Edgio 的 Azure 內容傳遞網路 | |
---|---|---|
HTTP 狀態碼 | 200、203、206、300、301、410、416 | 200 |
HTTP 方法 | GET、HEAD | GET |
檔案大小限制 | 300 GB | 300 GB |
若要讓來自 Microsoft 的標準 Azure CDN 快取在資源上運作,原始伺服器必須支援任何 HEAD 和 GET HTTP 要求,而且資產的所有 HEAD 和 GET HTTP 回應的內容長度值都必須相同。 在 HEAD 要求中,原始伺服器必須支援 HEAD 要求,而且必須以相同的標頭回應,如同它已接收 GET 要求。
注意
不會快取包含授權標頭的要求。
預設快取行為
下表描述 Azure 內容傳遞網路產品及其最佳化的預設快取行為。
Microsoft:一般 Web 傳遞 | Edgio:一般 Web 傳遞 | Edgio:DSA | |
---|---|---|---|
接受來源 | Yes | 是 | No |
內容傳遞網路快取組態 | 兩天天 | 七天 | 無 |
接受來源:指定如果支援的快取指示詞標頭存在於原始伺服器的 HTTP 回應中,是否要加以接受。
CDN 快取持續時間:指定資源會在 Azure 內容傳遞網路快取的時間量。 不過,如果 [接受來源] 為 [是],且來自原始伺服器的 HTTP 回應中包含快取指示詞標頭 Expires
或 Cache-Control: max-age
,Azure 內容傳遞網路就會改為使用標頭所指定的持續時間值。
注意
Azure 內容傳遞網路不保證物件將儲存在快取中的最短時間量。 如果未經常要求內容,快取的內容可能會在內容傳遞網路快取到期之前從內容傳遞網路快取收回,以便為更頻繁要求的內容提供空間。
下一步
- 若要了解如何透過快取規則自訂及覆寫內容傳遞網路上的預設快取行為,請參閱使用快取規則控制 Azure 內容傳遞網路快取行為。
- 若要了解如何使用查詢字串來控制快取行為,請參閱使用查詢字串控制 Azure 內容傳遞網路快取行為。