使用 Azure Front Door 進行快取

重要

Azure Front Door (傳統) 將於 2027 年 3 月 31 日遭到淘汰。 為了避免任何服務中斷，請務必在 2027 年 3 月之前，將 Azure Front Door (傳統) 設定檔移轉至 Azure Front Door 標準或進階層。 如需詳細資訊，請參閱 Azure Front Door (傳統版) 淘汰。

Azure Front Door 是一種新式內容傳遞網路 (CDN)，提供動態網站加速和負載平衡功能。 在路由上設定快取時，接收每個要求的邊緣網站會檢查其快取是否有有效的回應。 快取有助於減少傳送至原始伺服器的流量。 如果沒有可用的快取回應，則會將要求轉送至原始伺服器。

每個 Front Door 邊緣網站都會管理自己的快取，而要求可能會由不同的邊緣網站提供。 因此，即使您提供了快取回應，仍可能會看到一些流量送達原始伺服器。

快取可大幅降低延遲，並減少原始伺服器上的負載。 不過，並非所有類型的流量都能受益於快取。 映像、CSS 和 JavaScript 檔案等靜態資產非常適合用於快取。 雖然是動態資產，例如已驗證的 API 端點，不應該快取以防止個人資訊外洩。 建議針對靜態和動態資產有個別的路由，並停用對於後者的快取。

警告

啟用快取之前，請先徹底檢閱公開文件，並在啟用快取之前先測試所有可能的案例。 如先前所述，設定錯誤時，您可能會意外快取多個使用者產生的隱私權事件所共用的使用者特定資料。

要求方法

只有使用 GET 要求方法的要求可以快取。 所有其他要求方法則一律透過網路進行 Proxy 處理。

傳遞大型檔案

Azure Front Door 可傳遞大型檔案且檔案大小沒有上限。 如果啟用快取，Front Door 會使用稱為物件區塊化的技術。 要求大型檔案時，Front Door 會從原點擷取較小的檔案片段。 Front Door 收到完整檔案要求或位元組範圍檔案要求後，Front Door 環境就會向原始伺服器要求檔案 (以 8 MB 的區塊為單位)。

當區塊抵達 Azure Front Door 環境之後，就會被快取並立即提供給使用者。 然後 Front Door 會以平行方式預先擷取下一個區塊。 此預先擷取可確保內容領先使用者一個區塊，以降低延遲。 此程序會繼續進行，直到整個檔案完成下載 (若需要) 或用戶端關閉連線為止。 如需位元組範圍要求的詳細資訊，請參閱 RFC 7233。

Front Door 會在接收到任何區塊之後進行快取，因此不需要在 Front Door 快取上快取整個檔案。 快取會提供後續的檔案或位元組範圍要求。 如果不快取所有區塊，就會使用預先擷取向原始伺服器要求區塊。

此最佳化依賴原點的功能，支援位元組範圍的要求。 如果原始伺服器不支援位元組範圍要求，或未正確處理範圍要求，則此最佳化無效。

當您的原始伺服器回應含有 Range 標頭的要求時，必須以下列其中一種方式回應：

• 傳回範圍回應。 回應必須使用 HTTP 狀態碼 206。 此外，Content-Range 回應標頭必須存在，而且必須符合原始伺服器傳回內容的實際長度。 如果您的原始伺服器未傳送含有有效值的回應標頭，Azure Front Door 不會快取回應，且您可能會看到不一致的行為。

  提示

  如果您的原始伺服器壓縮回應，請確定 Content-Range 標頭值符合壓縮回應的實際長度。

• 傳回非範圍回應。 如果您的原始伺服器無法處理範圍要求，則會忽略 Range 標頭並傳回非範圍回應。 請確定原始伺服器傳回 206 以外的回應狀態碼。 例如，原始伺服器可能會傳回「200 確定」回應。

如果原始伺服器使用區塊傳輸編碼 (CTE)，將資料傳送至 Azure Front Door POP，則不支援大於 8 MB 的回應大小。

檔案壓縮

請參閱在 Azure Front Door 中壓縮檔案以改善效能。

Azure Front Door (傳統) 可在邊緣動態壓縮內容，因而對用戶端產生較小且更快速的回應時間。 為了讓檔案符合資格可進行壓縮，必須啟用快取，而且檔案必須是 MIME 類型，才符合資格可進行壓縮。 目前，Front Door (傳統) 不允許變更此清單。 目前的清單為：

• "application/eot"
• "application/font"
• "application/font-sfnt"
• "application/javascript"
• "application/json"
• "application/opentype"
• "application/otf"
• "application/pkcs7-mime"
• "application/truetype"
• "application/ttf"，
• "application/vnd.ms-fontobject"
• "application/xhtml+xml"
• "application/xml"
• "application/xml+rss"
• "application/x-font-opentype"
• "application/x-font-truetype"
• "application/x-font-ttf"
• "application/x-httpd-cgi"
• "application/x-mpegurl"
• "application/x-opentype"
• "application/x-otf"
• "application/x-perl"
• "application/x-ttf"
• "application/x-javascript"
• "font/eot"
• "font/ttf"
• "font/otf"
• "font/opentype"
• "image/svg+xml"
• "text/css"
• "text/csv"
• "text/html"
• "text/javascript"
• "text/js"、"text/plain"
• "text/richtext"
• "text/tab-separated-values"
• "text/xml"
• "text/x-script"
• "text/x-component"
• "text/x-java-source"

此外，檔案大小也必須介於 1 KB 到 8 MB (含) 之間。

這些設定檔支援下列壓縮編碼：

• Gzip (GNU zip)
• Brotli

如果要求支援 gzip 和 Brotli 壓縮，Brotli 壓縮的優先順序最高。

當資產的要求指定壓縮且快取中的要求結果遺失時，Azure Front Door (傳統) 會在 POP 伺服器上直接對資產進行壓縮。 之後會從快取提供壓縮的檔案。 產生的項目會與 Transfer-Encoding: chunked 回應標頭一起傳回。

如果原點使用區塊傳輸編碼 (CTE) 將資料傳送至 Azure Front Door POP，則不支援壓縮。

注意

範圍要求可能會壓縮成不同的大小。 Azure Front Door 會要求任何 GET HTTP 要求的內容長度值都相同。 如果用戶端所傳送位元組範圍要求的標頭為 Accept-Encoding，而該造成標頭以不同內容長度的來源回應，則 Azure Front Door 會傳回 503 錯誤。 您可以在原始伺服器上停用壓縮，或建立規則引擎規則，以從位元組範圍要求的要求中移除 Accept-Encoding 標頭。

查詢字串行為

您可以使用 Azure Front Door 來控制 Web 要求內含查詢字串時的檔案快取方式。

在含有查詢字串的 Web 要求中，查詢字串是要求中問號 (?) 之後的部分。 查詢字串可以包含一或多個索引鍵/值組，其中的欄位名稱與其值是以等號 (=) 分隔。 每個索引鍵/值組是以 & 符號分隔。

例如，URL http://www.contoso.com/content.mov?field1=value1&field2=value2 包含兩個查詢字串：

• field1，含有 value1 值。
• field2，含有 value2 值。

如果要求的查詢字串中有不止一個索引鍵/值組，則其順序並不重要。

當您設定快取時，會指定快取應如何處理查詢字串。 支援的行為如下：

• 忽略查詢字串：在此模式中，Azure Front Door 會將用戶端發出的查詢字串傳遞至第一個要求的原始伺服器並快取資產。 針對該資產從 Azure Front Door 環境發出的後續要求都會忽略查詢字串，直到所快取的資產到期為止。

• 使用查詢字串：在此模式中，每個要求都有一個唯一 URL (包含查詢字串)，會被視為具有專屬快取的唯一資產。 例如，系統會將原點對 www.example.ashx?q=test1 要求做出的回應快取於 Front Door 環境中，然後針對具有相同查詢字串的後續快取傳回此回應。 系統快取針對 www.example.ashx?q=test2 的要求，會將其視為具有專屬存留時間設定的個別資產。

  查詢字串參數的順序並不重要。 例如，如果 Azure Front Door 環境包含 URL www.example.ashx?q=test1&r=test2 的快取回應，則也會從快取提供 www.example.ashx?r=test2&q=test1 的要求。

• 忽略指定的查詢字串和包含指定的查詢字串：在此模式中，您可以設定 Azure Front Door 在產生金鑰快取時包含或排除指定的參數。

  例如，假設預設快取金鑰為 /foo/image/asset.html，而且要求是對 URL https://contoso.com/foo/image/asset.html?language=EN&userid=100&sessionid=200 發出。 如果有規則引擎規則可排除 userid 查詢字串參數，則查詢字串快取金鑰會是 /foo/image/asset.html?language=EN&sessionid=200。

在 Front Door 路由上設定查詢字串行為。

快取清除

請參閱 Azure Front Door 中的快取清除，以了解如何設定快取清除。

Azure Front Door 將會快取資產，直到資產的存留時間 (TTL) 到期為止。 每當用戶端要求已過期 TTL 的資產時，Front Door 環境就會擷取資產的新更新複本來提供要求，然後儲存重新整理的快取。

若要確定使用者一律會取得最新的資產複本，最佳作法是為每個更新設定資產版本，然後將它們發佈為新的 URL。 Front Door 將立即為下一個用戶端要求擷取新的資產。 有時您可能想要清除所有邊緣節點的快取內容，並強制它們全部擷取新的更新的資產。 原因可能是由於您的 Web 應用程式更新，或快速更新包含不正確資訊的資產。

選取您要從邊緣節點清除的資產。 若要清除所有資產，請選取 [全部清除]。 否則，在 [路徑] 中，輸入每個您所要清除資產的路徑。

在要清除的路徑清單中支援這些格式：

• 單一路徑清除：藉由指定資產 (沒有通訊協定和網域) 的完整路徑 (包含含副檔名，例如 /pictures/strasbourg.png) 來清除個別資產；
• 萬用字元清除︰星號 (*) 可做為萬用字元。 清除路徑中端點包含 /* 的所有資料夾、子資料夾與檔案，或指定後接 /* 的資料夾，來清除特定資料夾下的所有子資料夾與檔案，例如 /pictures/*。
• 根網域清除︰清除路徑中有 "/" 之端點的根目錄。

注意

清除萬用字元網域：如本節中所述，指定清除的快取路徑不適用於與 Front Door 相關聯的任何萬用字元網域。 目前，我們不支援直接清除萬用字元網域。 您可以指定特定子網域和清除路徑，以清除特定子網域的路徑。 例如，如果我的 Front Door 有 *.contoso.com，則我可以輸入 foo.contoso.com/path/* 來清除子網域 foo.contoso.com 的資產。 目前，在清除內容路徑中指定主機名稱僅限於萬用字元網域的子網域 (如果適用)。

Front Door 上的快取清除是不區分大小寫的。 此外，其為無從驗證的查詢字串，這表示清除 URL 會清除其所有查詢字串變化。

快取到期

下列標頭的順序可用來判斷項目儲存在快取中的時間長度：

1. Cache-Control: s-maxage=<seconds>
2. Cache-Control: max-age=<seconds>
3. Expires: <http-date>

某些 Cache-Control 回應標頭值表示無法快取回應。 這些值包括 private、no-cache 和 no-store。 Front Door 會接受這些標頭值，而且不會快取回應，即使您使用規則引擎覆寫快取行為也一樣。

如果原始伺服器發出的回應沒有 Cache-Control 標頭，Front Door 預設會隨機決定一到三天範圍內的快取持續時間。

注意

快取到期不能大於 366 天。

您可以在 Cache-Control 回應標頭中看到 REVALIDATED_HIT。 這表示 Azure Front Door 中快取的內容在提供給用戶端之前，已經過原始伺服器重新驗證。 當快取的內容過期，但原始伺服器指出內容尚未變更時，就會發生這種情況。 在此情況下，快取的內容會提供給用戶端，並重設快取到期日。

要求標頭

啟用快取時，下列要求標頭不會轉送至原始伺服器：

• Content-Length
• Transfer-Encoding
• Accept
• Accept-Charset
• Accept-Language

注意

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

回應標頭

如果原始伺服器回應可以快取，則會先移除 Set-Cookie 標頭，再將回應傳送至用戶端。 如果原始伺服器回應無法快取，則 Front Door 不會移除標頭。 例如，如果原始伺服器回應包含具有 max-age 值的 Cache-Control 標頭，則表示告知 Front Door 可以快取回應並移除 Set-Cookie 標頭。

此外，Front Door 會將 X-Cache 標頭附加至所有回應。 X-Cache 回應標頭包含下列其中一個值：

• TCP_HIT 或 TCP_REMOTE_HIT：回應的前 8 MB 區塊是快取命中，且內容會從 Front Door 快取提供。
• TCP_MISS：回應的前 8 MB 區塊是快取遺漏，且內容是從原始伺服器擷取。
• PRIVATE_NOSTORE：無法快取要求，因為 Cache-Control 回應標頭設定為 private 或 no-store。
• CONFIG_NOCACHE：在 Front Door 設定檔中，已設定不快取要求。

記錄和報告

存取記錄包含每個要求的快取狀態。 此外，報告也包含如何在應用程式中使用 Azure Front Door 快取的相關資訊。

存取記錄包含每個要求的快取狀態。

快取行為和持續時間

您可以在規則引擎中設定快取行為和持續時間。 規則引擎快取設定一律會覆寫路由設定。

• 停用快取時，不論原始伺服器回應指示詞為何，Azure Front Door 都不會快取回應內容。

• 啟用快取時，快取行為會根據規則引擎所套用的快取行為值而有所不同：

  • 接受原始伺服器：Azure Front Door 一律會接受原始伺服器回應標頭指示詞。 如果遺漏原始伺服器指示詞，Azure Front Door 會快取一到三天之間的內容。
  • 一律覆寫：Azure Front Door 一律會以快取持續時間進行覆寫，這表示其會快取在快取持續時間內的內容，並忽略來自原始伺服器回應指示詞的值。 只有在可快取回應時，才會套用此行為。
  • 如果原始伺服器遺失，請覆寫：如果原始伺服器未傳回快取 TTL 值，Azure Front Door 會使用指定的快取持續時間。 只有在可快取回應時，才會套用此行為。

注意

• Azure Front Door 不保證內容儲存在快取中的時間量。 如果內容不常使用，則可能會從邊緣快取中移除快取的內容。 即使快取資料已過期，Front Door 仍可處理來自快取的資料。 當您的原點離線時，這個行為可協助使您的網站保持部分可用。
• Origin 可能指定不要使用值為 no-cache、private 或 no-store 的 Cache-Control 標頭來快取特定回應。 在從原始伺服器到 Azure Front Door POP 的 HTTP 回應中使用時，Azure Front Door 支援快取控制指導方針，並遵守 RFC 7234 - 超文字傳輸通訊協定 (HTTP/1.1)：快取 (ietf.org) 中快取控制指導方針的快取行為。

您可以在 Front Door 設計工具路由規則和規則引擎中設定快取行為和持續時間。 規則引擎快取設定一律會覆寫 Front Door 設計工具路由規則設定。

• 停用快取時，不論原始伺服器回應指示詞為何，Azure Front Door (傳統) 都不會快取回應內容。

• 啟用快取時，快取行為依 [使用快取預設持續時間] 的不同值而有所不同。

  • 當 [使用快取預設持續時間] 設定為 [是] 時，Azure Front Door (傳統) 一律會接受原始伺服器回應標頭指示詞。 如果遺漏原始伺服器指示詞，則 Front Door 會快取一到三天之間的內容。
  • 當 [使用快取預設持續時間] 設定為 [否] 時，Azure Front Door (傳統) 一律會覆寫 [快取持續時間] (必要欄位)，這表示其會快取快取持續時間的內容，而忽略原始伺服器回應指示詞中的值。

注意

• Azure Front Door (傳統) 不保證內容儲存在快取中的時間量。 如果內容不常使用，則可能會從邊緣快取中移除快取的內容。 即使快取資料已過期，Azure Front Door (傳統) 仍可處理來自快取的資料。 當您的原點離線時，這個行為可協助使您的網站保持部分可用。
• Front Door 設計工具路由規則中設定的快取持續時間是 [最小快取持續時間]。 如果原點快取控制標頭的 TTL 大於覆寫值，則此覆寫將無法運作。

下一步

• 了解如何建立 Azure Front Door (傳統)。
• 了解 Azure Front Door (傳統) 的運作方式。

• 深入了解規則集比對條件
• 深入了解規則集動作