速度、速度，還是速度，一個網站要想體驗好，就必須在第一時間以最快的速度顯示出來。mysql查詢慢，就加一層 redis 做緩存，網站資源加載慢，怎么做，使用 HTTP緩存。
HTTP緩存自 HTTP/1.0 就開始有，為的是減少服務器壓力，加快網頁響應速度。
緩存操作的目標HTTP 緩存只能存儲 GET 請求的響應，而對其他類型的請求無能為力。
緩存發展史HTTP/1.0 提出緩存概念，即強緩存 Expires 和協商緩存 Last-Modified。后 HTTP/1.1 又有了更好的方案，即強緩存 Cache-Control 和協商緩存 ETag。
為什么 Expires 和 Last-Modified 不適用呢?
Expires 即過期時間，但問題是這個時間點是服務器的時間，如果客戶端的時間和服務器時間有差，就不準確。所以用 Cache-Control 來代替，它表示過期時長，這就沒歧義了。
Last-Modified 即最后修改時間，而它能感知的單位時間是秒，也就是說如果在1秒內改變多次，內容文件雖然改變了，但展示還是之前的，存在不準確的場景，所以就有了 ETag，通過內容給資源打標識來判斷資源是否變化。
以下表格利于對比理解：
版本 強緩存 協商緩存 HTTP/1.0 Expires Last-Modified HTTP/1.1 Cache-Control ETag。
兩大緩存類型對比前文已介紹不同版本下的緩存類型。當時提了有一句強緩存和協商緩存，但沒具體介紹?，F在來講講這兩種緩存類型。
強緩存Cache-ControlHTTP/1.1。通過過期時長控制緩存，對應的字段有很多，例如 max-age 例如 Cache-Control: max-age=3600，表示緩存時間為3600秒，過期失效。緩存請求指令：Cache-Control: max-age= Cache-Control: max-stale[=] Cache-Control: min-fresh= Cache-control:no-cache Cache-control: no-store Cache-control: no-transform Cache-control: only-if-cached。緩存響應指令：Cache-control: must-revalidate Cache-control: no-cache Cache-control: no-store Cache-control: no-transform Cache-control: public Cache-control: private Cache-control: proxy-revalidate Cache-Control: max-age= Cache-control: s-maxage=。其中關鍵點：Cache-control: no-cache 跳過當前的強緩存，發送 HTTP 請求(如有協商緩存標識即直接進入協商緩存階段)no-cache 的含義和 max-age=0 一樣 ，即跳過強緩存，強制刷新 Cache-control: no-store 不使用緩存(包括協商緩存) Cache-Control: public, max-age=31536000 一般用于緩存靜態資源public：響應可以被中間代理、CDN 等緩存private：專用于個人的緩存，中間代理、CDN等能換緩存此響應max-age：單位是秒。更多指令參考指令大全。ExpiresHTTP/1.0。語法：Expires: 。即過期時間，存在于服務器返回的響應頭里 Expires: Mon, 11 Apr 2022 06:57:18 GMT表示資源在2022年4月11號6點57分過期，過期了就會往服務端發請求。如果在Cache-Control響應頭設置了 "max-age" 或者 "s-max-age" 指令，那么 Expires 頭會被忽略。缺點：服務器時間與瀏覽器時間可能不一致。更多指令參考指令大全。Cache-Control VS ExpiresCache-Control 較之 Expires 更為精準。同時存在時，Cache-Control 優先級大于 Expires。Expires 是 HTTP/1.0 提出，其瀏覽器兼容性更好，Cache-Control 是 HTTP/1.1 提出，可同時存在，當有不支持 Cache-Control 的瀏覽器時會以 Expires 為準。協商緩存協商緩存需要配合強緩存使用，使用協商緩存的前提是設置強緩存設置 Cache-Control: no-cache或者 pragma: no-cache或者 max-age=0 告訴瀏覽器不走強緩存。
pragma 是 HTTP/1.0 中禁止網頁緩存的字段，其取值為 no-cache 和 Cache-Control 的 no-cache 效果一樣。
ETag/If-None-MatchHTTP/1.1。即生成文件唯一標識來判斷是否過期。只要內容改變，這個值就會變。與 If-None-Match 配合，ETag是請求服務器后返回給每個資源文件的唯一標識，客戶端會將此標識存在客戶端(即瀏覽器)中，下次請求時會在請求頭的 If-Nono-Match 中將其值帶上，服務器判斷 If-None-Match 是否與自身服務器上的 ETag 一致，如果一致則返回 304，重定向跳轉使用本地緩存;不一致，則返回200，將最新資源返回給客戶端，并帶上 ETag。更多指令參考指令大全。Last-Modified/If-Modified-SinceHTTP/1.0。最后修改時間，即通過最后修改時間來判斷是否過期。在瀏覽器第一次給服務器發送請求后，服務器會在響應頭上加上這個字段。與 If-Modified-Since 配合，客戶端訪問服務器資源時，服務器端會將 Last-Modified 放入響應頭中，即這個資源在服務器上的最后修改時間，客戶端緩存這個值，等下次請求這個資源時，瀏覽器會檢測到請求頭中的 Last-Modified，于是乎添加 If-Modified-Since，如果 If-Modified-Since 的值與服務器中這個資源的最后修改時間一致，則返回 304，重定向跳轉使用本地緩存;不一致，則返回200，將最新資源返回給客戶端，并帶上 Last-Modified。缺點：文件雖然被修改，但最后的內容沒有變化，這樣文件修改時間還是會更新有些文件修改頻率在秒以內，這樣以秒粒度來記錄就不適用了有些服務器無法精準獲取文件的最后修改時間。更多指令參考指令大全。ETag VS Last-Modified精確度 ETag > Last-Modified。ETag 是通過內容給資源打標識來判斷資源是否變化，而 Last-Modified不一樣，在某些場景下準確度會失效。例如編輯文件，但是文件內容未變，緩存會失效;或者在1秒內改變多次，Last-Modified能感知的單位時間是秒。性能 Last-Modified > ETag。Last-Modified 僅僅記錄一個時間點，而 ETag需要根據文件的具體內容生成哈希值。如果兩個都支持的話，服務器會優先選擇ETag。協商緩存的條件請求前文說到協商緩存是在請求頭添加 If-None-Match 或 If-Modified-Since，這些請求頭是什么，添加有什么用?
強緩存是通過具體時間到期或過期時長來控制緩存，這就有個問題了，如果其中的一些文件修改了，因為強緩存，瀏覽器展示的還是原來的數據，所以對那種常變化的數據不能使用強緩存做緩存策略，于是乎，就有了協商緩存，通過文件變化告訴瀏覽器緩存失效，使用前需去服務器驗證是否是最新版?
這樣，瀏覽器就要連續發送兩個請求來驗證：
先是 HEAD 請求，獲取資源的修改時間、hash值等元信息，然后與緩存數據比較，如果沒有改動就使用緩存。否則就再發一個 GET 請求，獲取最新的版本。但這樣的兩個請求的網絡成本太高，所以 HTTP 協議就定義了一系列 If 開頭的條件請求字段，專門用來檢查驗證資源是否過期，把兩個請求合并在一個請求中做。而且驗證的責任也交給服務器。
If-Modified-Since：和 Last-modified 比較，是否已經修改了。If-None-Match：和 ETag 比較，唯一標識是否一致。If-Unmodified-Since：和 Last-modified 對比，是否修改。If-Match：和 ETag 比較是否匹配。If-Range。其中，最常見的當屬是 If-Modified-Since 和 If-None-Match。它們分別對應Last-Modified 和 ETag。需要第一次的響應報文預先提供 Last-Modified 和 ETag，然后第二次請求時就可以帶上緩存里的原址，驗證資源是否是最新的。
如果資源沒有變，服務器就回應一個 304 Not Modified ，表示緩存依然有效，瀏覽器就可以更新一個有效期，然后使用緩存了。
緩存流程
什么時候用強緩存，什么時候用協商緩存?首先強緩存的權重大于協商緩存，當強緩存存在時，協商緩存只能看著;其次 HTTP/1.1 中的緩存標識符大于 HTTP/1;所以當 Cache-Control 存在時，看它的，如果它不存在，則看 Expires，如果將強緩存設置為 Cache-Control：no-cache、Cache-Control：max-age=0、pragma: no-cache，即告訴瀏覽器不走強緩存，則進入協商緩存。
判斷上次響應中是否有ETag，如果有，則發起請求，請求頭中帶有條件請求 If-None-Match，如果沒有，則再判斷上次響應中是否有Last-Modified，如果有，則發起請求頭中帶If-Modified-Since 的條件請求，如果沒有，則說明沒有協商緩存，發起 HTTP 請求即可。無論是帶If-None-Match的請求還是 If-Modified-Since 的請求，都會返回狀態(由服務器端判讀資源是否變化)，如果是304，說明緩存資源未變，使用本地緩存;如果是200，則說明資源改變，發起 HTTP 請求，并記住響應頭中的 ETag/Last-Modified。
大致流程圖如下所示：
緩存判斷流程圖
那么哪些資源要采用強緩存，哪些資源采用協商緩存呢?
像靜態資源這類我們長期不會去變動的資源應該用強緩存，不難理解;而像我們常修改的文件應該采用協商緩存，如果資源沒變，那么當用戶第二次進去還是用該資源，如果資源修改，用戶進入發起 HTTP 請求獲取最新資源。
我們在訪問網站時，如果留心都能在 F12 中觀察到一二。如圖所示，我的五年前端三年面試放在 github 服務器上，F12進入 Network中，能看到返回頭中的信息。Cache-Control、Expires、ETag、Last-Modified都存在。
五年前端三年面試
緩存位置上文中常提到無論使用強緩存還是協商緩存，都會從瀏覽器本地中獲取，那么瀏覽器的本地存儲是存在哪里，他們又有什么分類呢?
按照緩存位置分類，分為四處，Memory Cache(內存緩存)、Disk Cache(硬盤緩存)、Service Worker、Push Cache。
Memory Cache因為內存有限，并不是所有的資源文件都會放在內存里緩存，它主要用來緩存有 preloader 相關指令的資源，比如。preloader 可以一邊解析 js/css 文件，一邊網絡請求下一個資源。
Disk Cache磁盤上的緩存。在所有瀏覽器緩存中，disk cache 覆蓋面最大，它會根據 HTTP Header 中的字段判斷哪些資源需要緩存，哪些資源已經過期需要重新從服務器端請求。
Service Worker獨立線程，借鑒了 Web Worker 的思路。即讓 JS 運行在主線程之外，由于它脫離瀏覽器窗口，因為無法直接訪問DOM，但是它還是能做很多事情，如
離線緩存，Service Worker Cache。消息推送。網絡代理。它是PWA的重要實現機制。Push Cache即推送緩存，瀏覽器中的最后一道防線，HTTP2中的內容。
優先級：Service Worker-->Memory Cache-->Disk Cache-->Push Cache。
實踐說了這么多理論知識，等實戰的時候卻一頭霧水，怎么破?
以上皆為口舌之辯，唯有實踐出真章(以上皆為面試之辯，唯有實踐出本事)。
目前前端項目都是以 webpack 或類 webpack 工具庫打包，在 webpack 中配置哈希，前端方面的緩存工作就完成了。
我們要實現的效果是：
HTML：協商緩存。CSS、JS、圖片等資源：強緩存，文件名帶上hash。webpack 中的哈希有三種：hash、chunkHash、contentHash。
Hash：和整個項目的構建相關，只要項目文件有改變，整個項目構建的 hash 值就會改變。chunkHash：和 webpack 打包的 chunk 有關，不同的入口會生成不同的 chunkHash值。contentHash：根據文件內容來定義hash，文件內容不變，則 contentHash 不變。這邊需要把 CSS 用 contentHash 處理，其他資源用 chunkHash 做處理。
非前端工程化項目即傳統的前端頁面，一般放在靜態服務器中，那么就要對修改的文件做版本控制，例如在入口文件 index.js 上加版本號(index-v2.min.js)或者加時間戳(time=1626226)，以此做緩存策略。
后端緩存實踐真正起到緩存作用的是在后端，后端來設置緩存策略，告訴瀏覽器能否做緩存。這里我們對強緩存和協商緩存做個demo來實驗下。
強緩存方案代碼如下：
const express = require("express");const app = express();var options = { etag: false, // 禁用協商緩存 lastModified: false, // 禁用協商緩存 setHeaders: (res, path, stat) => { res.set("Cache-Control", "max-age=10"); // 強緩存超時時間為10秒 },};app.use(express.static((__dirname + "/public"), options));app.listen(3008);
PS：代碼來源自：圖解 HTTP 緩存，在做測試時，需要注意，強緩存下，刷新頁面是測不出來，點擊后返回方能有效。
強緩存效果
協商緩存方案代碼如下：
const express = require("express");const app = express();var options = { etag: true, // 開啟協商緩存 lastModified: true, // 開啟協商緩存 setHeaders: (res, path, stat) => { res.set({ "Cache-Control": "max-age=00", // 瀏覽器不走強緩存 "Pragma": "no-cache", // 瀏覽器不走強緩存 }); },};app.use(express.static((__dirname + "/public"), options));app.listen(3001);
效果如下：
協商緩存效果
總結HTTP 為什么要緩存，為了分擔服務器壓力，也為了讓頁面加載更快。
有什么手段?HTTP 的強緩存和協商緩存，強緩存作用于那些不怎么變化的資源(如引入的庫，js，css等)，協商緩存適用常更新的文件(例如 html)。
強緩存是什么?在 HTTP/1.0 中以 Expires 為依據，但它不準確，HTTP 協議升級成1.1后，用新標識符 Cache-Control 來代替，但兩者可以同時存在，Cache-Control 的權重更大一些。
協商緩存是什么?在 HTTP/1.0 中以 Last-Modified 為依據，即最后過期修改時間，它也不準確，HTTP升級成1.1后，用新標識符 ETag 來代替，兩者可同時存在，后者的權重更大。
無論是 Expires ，還是 Last-Modified，都是以時間點來依據，理論上是不出問題，但卻出問題了，所以就有了新的方案。
其中強緩存存在時，瀏覽器會采用強緩存標識符來緩存，當將強緩存設置為失效時，瀏覽器則會采用協商緩存來做緩存策略。
以上，即使筆者所理解的 HTTP 緩存。
X 關閉
X 關閉