Azure Front Door 的緩存

下列文檔詳細說明了在具有已啟用緩存的路由規(guī)則時 Front Door 的行為。 Front Door 是一種具有動態(tài)站點加速和負載平衡功能的現(xiàn)代化內容交付網(wǎng)絡 (CDN)，就像其他任何 CDN 一樣，也支持緩存行為。

大型文件交付

Azure Front Door 服務可交付大型文件，不限制文件大小。 Front Door 使用一種被稱作對象區(qū)塊的技術。 請求大型文件時，F(xiàn)ront Door 會從后端檢索文件的較小部分。 收到完整或字節(jié)范圍的文件請求后，F(xiàn)ront Door 環(huán)境以 8 MB 的區(qū)塊為單位從后端請求文件。

區(qū)塊到達 Front Door 環(huán)境后，會將區(qū)塊緩存并立即提供給用戶。 然后，F(xiàn)ront Door 會并行預提取下一個區(qū)塊。 此預提取可確保內容始終先于用戶一個區(qū)塊，從而減少延遲。 該過程將一直持續(xù)到下載完整個文件（如果需要）或客戶端關閉連接為止。

有關字節(jié)范圍請求的詳細信息，請閱讀 RFC 7233。 Front Door 會在收到任何區(qū)塊后將區(qū)塊緩存，因此整個文件無需在 Front Door 緩存中進行緩存。 隨后從緩存中請求文件或字節(jié)范圍的請求。 如果區(qū)塊未全部緩存，將采用預提取從后端請求區(qū)塊。 這種優(yōu)化依賴于后端支持字節(jié)范圍請求的能力。 如果后端不支持字節(jié)范圍請求，則此優(yōu)化不會生效。

文件壓縮

Front Door 可動態(tài)壓縮邊緣內容，從而更快響應客戶端。 為了讓文件符合壓縮條件，必須啟用緩存，并且文件必須是 MIME 類型才能壓縮。 目前，F(xiàn)ront 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 壓縮優(yōu)先。
如果對資產(chǎn)的請求指定進行壓縮，但該請求導致緩存缺失，則 Front Door 將直接在 POP 服務器上壓縮資產(chǎn)。 此后，將從緩存提供壓縮的文件。 通過 transfer-encoding: chunked 返回所生成的項。

 備注

范圍請求可以壓縮成不同的大小。 Azure Front Door 要求任何 GET HTTP 請求的 content-length 值都相同。 如果客戶端發(fā)送帶有 accept-encoding 標頭的字節(jié)范圍請求導致源以不同的內容長度響應，則 Azure Front Door 將返回 503 錯誤。 可以在源/Azure Front Door 上禁用壓縮，也可以創(chuàng)建規(guī)則集規(guī)則以從字節(jié)范圍請求中刪除 accept-encoding。

查詢字符串行為

借助 Front Door，可控制如何對包含查詢字符串的 Web 請求緩存文件。 在包含查詢字符串的 Web 請求中，查詢字符串是問號 (?) 后出現(xiàn)的請求部分。 查詢字符串可以包含一個或多個鍵值對，其中字段名稱和其值由等號 (=) 分隔。 每個鍵值對由與號 (&) 分隔。 例如 http://www.contoso.com/content.mov?field1=value1&field2=value2。 如果請求的查詢字符串中有多個鍵值對，其順序并不重要。

• 忽略查詢字符串：在此模式下，F(xiàn)ront Door 將來自請求者的查詢字符串傳遞到第一個請求上的后端并緩存該資產(chǎn)。 由 Front Door 環(huán)境處理的資產(chǎn)的所有后續(xù)請求都將忽略查詢字符串，直到所緩存的資產(chǎn)過期。

• 緩存每個唯一的 URL：在此模式下，包含唯一 URL 的每個請求（包括查詢字符串）將視為具有其自己的緩存的唯一資產(chǎn)。 例如，后端對 www.example.ashx?q=test1 的請求做出的響應將緩存在 Front Door 環(huán)境中，并為具有同一查詢字符串的后續(xù)緩存返回該響應。 www.example.ashx?q=test2 的請求將作為具有其自己的生存時間設置的單獨資產(chǎn)來緩存。

緩存清除

直到資產(chǎn)的生存時間 (TTL) 到期之前，F(xiàn)ront Door 將一直對資產(chǎn)進行緩存。 每當客戶端請求的資產(chǎn)的 TTL 已過期時，F(xiàn)ront Door 環(huán)境會檢索新的更新后資產(chǎn)副本以提供請求，然后存儲已刷新的緩存。

確保用戶始終獲取資產(chǎn)的最新副本的最佳做法是針對每次更新將資產(chǎn)版本化，并將其發(fā)布為新 URL。 Front Door 將立即檢索用于下一個客戶端請求的新資產(chǎn)。 有時候可能希望從所有邊緣節(jié)點清除緩存的內容，并強制其全部檢索新的已更新資產(chǎn)。 原因可能是 Web 應用程序的更新，也可能是快速更新包含錯誤信息的資產(chǎn)。

選擇要從邊緣節(jié)點清除的資產(chǎn)。 要清除所有資產(chǎn)，請選擇“全部清除”。 否則，在“路徑”中，輸入要清除的每個資產(chǎn)的路徑。

要清除的路徑列表中支持以下格式：

• 單一路徑清除：通過指定資產(chǎn)的完整路徑（不帶協(xié)議和域）并包含文件擴展名（例如 /pictures/strasbourg.png）來清除單個資產(chǎn)；

• 通配符清除：星號 (*) 可用作通配符。 清除路徑中帶有 /* 的終結點下的所有文件夾、子文件夾和文件，或者通過指定后跟 /* 的文件夾（例如 /pictures/*），清除特定文件夾下的所有子文件夾和文件。

• 根域清除：清除路徑中具有“/”的終結點的根。

 備注

清除通配符域：按照本部分中所述指定用于清除的緩存路徑并不適用于與 Front Door 關聯(lián)的任何通配符域。 目前，我們不支持直接清除通配符域。 可以通過指定特定子域和清除路徑來清除特定子域中的路徑。 例如，如果我的 Front Door 有 *.contoso.com，我可以輸入 foo.contoso.com/path/* 來清除子域 foo.contoso.com 的資產(chǎn)。 目前，要在清除內容路徑中指定主機名，則僅限于通配符域的子域（如果適用）。

Front Door 的緩存清除不區(qū)分大小寫。 此外，它們不區(qū)分查詢字符串，這表示清除 URL 時將一并清除其查詢字符串的所有變體。

緩存到期

按下列標題順序來確定項目在緩存中的存儲時間：

1. Cache-Control: s-maxage=<seconds>

2. Cache-Control: max-age=<seconds>

3. Expires: <http-date>

優(yōu)選可指示不緩存響應的 Cache-Control 響應標頭，例如 Cache-Control: private，Cache-Control: no-cache 和 Cache-Control: no-store。 如果沒有 Cache-Control，則默認行為是 Front Door 緩存資源的時間長度為 X，其中 X 隨機選取時間為 1 到 3 天。

請求標頭

使用緩存時，以下請求標頭將不會被轉發(fā)到后端。

• Content-Length

• Transfer-Encoding

緩存行為和持續(xù)時間

可以在 Front Door 設計器傳遞規(guī)則和規(guī)則引擎中配置緩存行為和持續(xù)時間。 規(guī)則引擎緩存配置將始終替代 Front Door 設計器傳遞規(guī)則配置。

• 禁用緩存后，無論源響應指令是什么，F(xiàn)ront Door 都不會緩存響應內容。

• 啟用緩存后，對于“使用緩存默認持續(xù)時間”的不同值，緩存行為會有所不同。

• 當“使用緩存默認持續(xù)時間”設置為“是”時，F(xiàn)ront Door 始終采用源響應標頭指令。 如果缺少源指令，F(xiàn)ront Door 將緩存 1 到 3 天內任何位置的內容。

• 當“使用緩存默認持續(xù)時間”設置為“否”時，F(xiàn)ront Door 將始終替代“緩存持續(xù)時間”（必填字段），這意味著它將緩存緩存持續(xù)時間的內容，而忽略源響應指令中的值。

 備注

• 在 Front Door 設計器傳遞規(guī)則中設置的“緩存持續(xù)時間”是“最小緩存持續(xù)時間”。 如果源的緩存控制標頭的 TTL 大于替代值，則此替代將不起作用。

• 如果緩存內容的請求頻率不高，可能會在它們過期之前將其從 Azure Front Door 中逐出，以便為更頻繁請求的內容騰出空間。