共用方式為

快取如何運作 \(機器翻譯\)

  • 發行項

重要

Azure CDN Standard from Microsoft (classic) 將於 2027 年 9 月 30 日淘汰。 為了避免任何服務中斷，請務必在 2027 年 9 月 30 日之前，將 Azure CDN 標準從 Microsoft （傳統） 配置文件 移轉至 Azure Front Door Standard 或進階層。 如需詳細資訊，請參閱 Azure CDN Standard from Microsoft (classic) 淘汰。

來自 Edgio 的 Azure CDN 於 2025 年 1 月 15 日淘汰。 如需詳細資訊，請參閱來自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。

快取指示詞標頭

Azure 內容傳遞網路支援下列 HTTP 快取指示詞標頭，這些標頭會定義快取持續時間和快取共用。

Cache-Control：

  • 在 HTTP 1.1 中導入，讓 web 發行者能更充分掌控其內容，並處理 Expires 標頭的限制。
  • 如果已同時定義 Expires 標頭和 Cache-Control，則覆寫前者。
  • 使用於來自用戶端對內容傳遞網路 POP 的 HTTP 要求時，依預設所有 Azure 內容傳遞網路設定檔都會忽略 Cache-Control。
  • 當用於從源伺服器到內容傳遞網路 POP 的 HTTP 回應時，Cache-Control預設會接受所有 Azure 內容傳遞網路 設定檔。 Azure CDN 也接受 RFC 7234 - 超文字傳輸通訊協定 （HTTP/1.1）： 快取 （ietf.org） 中的快取控制指示詞的快取行為。

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 快取驗證程式可用來比較檔案的快取版本與原始伺服器上的版本。 從 Microsoft 的 Azure CDN 標準僅 Last-Modified支援 。

注意

來自 Microsoft 的 Azure CDN 不支援 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 回應共同傳遞的資源。

條件 值
HTTP 狀態碼 200、203、206、300、301、410、416
HTTP 方法 GET、HEAD
檔案大小限制 300 GB

若要讓快取在資源上運作，源伺服器必須支援任何 HEAD 和 GET HTTP 要求，而且資產的任何 HEAD 和 GET HTTP 回應的內容長度值都必須相同。 在 HEAD 要求中，原始伺服器必須支援 HEAD 要求，而且必須以相同的標頭回應，如同它已接收 GET 要求。

注意

不會快取包含授權標頭的要求。

預設快取行為

Azure CDN 的預設快取行為是 接受來源 ，並快取內容兩天。

榮譽來源：此設定會指定是否要遵守來自源伺服器的 HTTP 回應中的快取指示詞標頭（Cache-Control 或 Expires）。

CDN 快取持續時間：此設定會指定 Azure CDN 上快取資源的持續時間。 如果 已啟用 Honor 來源 ，且來自源伺服器的 HTTP 回應包含 Cache-Control: max-age 或 Expires 標頭，Azure CDN 會使用這些標頭指定的持續時間，而不是預設的兩天期間。

注意

Azure CDN 不保證物件將儲存在快取中的最短時間量。 如果未經常要求內容，快取的內容可能會在內容傳遞網路快取到期之前從內容傳遞網路快取收回，以便為更頻繁要求的內容提供空間。

下一步