作者：Nic Raboy
翻譯：瘋狂的技術宅
原文：https://www.thepolyglotdevelo...
未經允許嚴禁轉載
最近，我一直在玩Netlify，結果我對內容交付網絡（CDN）常見的緩存策略越來越熟悉。有一種將 ETag標識符用於 Web 資源的策略。
簡而言之，ETag 標識符是一個值，通常是一個散列，代表特定 Web 資源的版本。該資源與 ETag 值一起緩存在瀏覽器中，並且服務器會在確定特定的緩存資源是否已更改時使用該值。
我們將探索怎樣通過簡單的 cURL 請求用 ETag 標識符模擬瀏覽器發出的請求，而是。
首先，我們將請求資源：
$ curl -I https://www.thepolyglotdeveloper.com/css/custom.min.css
HTTP/2 200
accept-ranges: bytes
cache-control: public, max-age=0, must-revalidate
content-length: 7328
content-type: text/css; charset=UTF-8
date: Wed, 04 Sep 2019 00:41:04 GMT
strict-transport-security: max-age=31536000
etag: "018b8b0ecb632aab770af328f043b119-ssl"
age: 0
server: Netlify
x-nf-request-id: 65a8e1aa-03a0-4b6c-9f46-51aba795ad83-921013在上述請求中，我僅從響應中請求了標頭信息。對於本文，響應體回覆的內容對我們而言並不重要。
注意 cache-control 和 etag 標頭以及響應代碼。
在 Netlify 下，cache-control 標頭告訴瀏覽器緩存資源，但也不信任緩存。這樣做是爲了使客戶端始終嘗試獲取最新資源。 etag 標頭代表資源的版本，並隨將來的請求一起發送。如果服務器回覆說兩次請求之間的 etag 沒有改變，則響應將會帶有 304 代碼，從而將使用緩存的資源。
因此，讓我們用 cURL 檢查一下資源是否已進行了更改：
$ curl -I -H 'If-None-Match: "018b8b0ecb632aab770af328f043b119-ssl"' https://www.thepolyglotdeveloper.com/css/custom.min.css
HTTP/2 304
date: Wed, 04 Sep 2019 00:53:24 GMT
etag: "018b8b0ecb632aab770af328f043b119-ssl"
cache-control: public, max-age=0, must-revalidate
server: Netlify
x-nf-request-id: eca29310-c9bf-4742-87e1-3412e8852381-2165939對相同資源的新請求，將包含 If-None-Match 標頭，其值爲前一個請求的 etag 哈希。
注意，這次響應狀態代碼爲預期的 304。如果 etag 不同，則使用新的 etag 哈希產生 200 響應。
與壓縮的緩存資源進行交互
如果查看瀏覽器的網絡檢查器，您可能會注意到資源的 etag 哈希值附加了 -df 值。例如對於相同的資源，我的瀏覽器顯示以下內容：
018b8b0ecb632aab770af328f043b119-ssl-df雖然相似，但與之前的 cURL 請求返回的 etag 哈希值並不完全相同。嘗試使用上述 etag 值運行一個 cURL 請求：
$ curl -I -H 'If-None-Match: "018b8b0ecb632aab770af328f043b119-ssl-df"' https://www.thepolyglotdeveloper.com/css/custom.min.css
HTTP/2 200
accept-ranges: bytes
cache-control: public, max-age=0, must-revalidate
content-length: 7328
content-type: text/css; charset=UTF-8
date: Wed, 04 Sep 2019 01:03:13 GMT
strict-transport-security: max-age=31536000
etag: "018b8b0ecb632aab770af328f043b119-ssl"
age: 0
server: Netlify
x-nf-request-id: 2734ffab-c611-4fc9-841e-460f172aa3b4-1604468響應不是 304 代碼，因爲 -df 表示它是 URL 的壓縮版本。就目前而言，我們的 cURL 請求針對的是 URL 的未壓縮版本。
Netlify 的支持工程師在這個論壇帖子中向我指出了這種差異。
在大多數情況下，Web 瀏覽器將包含適當的標頭信息以使用壓縮資源，因此在 cURL中，我們必須做一些不同的事。
爲了使 cURL 超越此限制，以下請求將起作用：
$ curl --compressed -I -H 'If-None-Match: "018b8b0ecb632aab770af328f043b119-ssl-df"' https://www.thepolyglotdeveloper.com/css/custom.min.css
HTTP/2 304
date: Wed, 04 Sep 2019 01:07:36 GMT
etag: "018b8b0ecb632aab770af328f043b119-ssl-df"
cache-control: public, max-age=0, must-revalidate
server: Netlify
vary: Accept-Encoding
x-nf-request-id: 65a8e1aa-03a0-4b6c-9f46-51aba795ad83-1301670請注意，在上述請求中，我們在 cURL 中用了 --compressed 標誌。結果收到了 304 響應，指示資源沒有更改，我們應該使用本地緩存的副本。
或者，我們可以執行以下cURL請求：
$ curl -I -H 'If-None-Match: "018b8b0ecb632aab770af328f043b119-ssl-df"' -H 'Accept-Encoding: gzip, deflate, br' https://www.thepolyglotdeveloper.com/css/custom.min.css
HTTP/2 304
date: Wed, 04 Sep 2019 01:12:34 GMT
etag: "018b8b0ecb632aab770af328f043b119-ssl-df"
cache-control: public, max-age=0, must-revalidate
server: Netlify
vary: Accept-Encoding
x-nf-request-id: eca29310-c9bf-4742-87e1-3412e8852381-2432816而不是用 --compressed 標誌，我們包含了 accept-encoding 標頭。
同樣，Netlify 的 Luke Lawson 在這個論壇帖子中提供了有關壓縮版本的信息。
結論
您剛剛看到了如何用 cURL 模擬在 Web 瀏覽器中的相同緩存。由於我是使用內容交付網絡（CDN）處理緩存的新手，因此對於測試緩存如何與任何給定資源的 etag 哈希一起工作對我來說非常有用。 304 響應將始終比 200 響應更快地收到，並且有效負載更小，從而節省了帶寬和性能，同時又不犧牲內容的新鮮度。
從理論上講，CDN 會維護給定資源的版本信息，因此將能夠驗證 etag 值的新鮮度。由瀏覽器決定 etag 是否陳舊。
本文首發微信公衆號：前端先鋒
歡迎掃描二維碼關注公衆號，每天都給你推送新鮮的前端技術文章
歡迎繼續閱讀本專欄其它高贊文章：
- 深入理解Shadow DOM v1
- 一步步教你用 WebVR 實現虛擬現實遊戲
- 13個幫你提高開發效率的現代CSS框架
- 快速上手BootstrapVue
- JavaScript引擎是如何工作的？從調用棧到Promise你需要知道的一切
- WebSocket實戰：在 Node 和 React 之間進行實時通信
- 關於 Git 的 20 個面試題
- 深入解析 Node.js 的 console.log
- Node.js 究竟是什麼？
- 30分鐘用Node.js構建一個API服務器
- Javascript的對象拷貝
- 程序員30歲前月薪達不到30K，該何去何從
- 14個最好的 JavaScript 數據可視化庫
- 8 個給前端的頂級 VS Code 擴展插件
- Node.js 多線程完全指南
- 把HTML轉成PDF的4個方案及實現