簡述 HTTP 緩存首部及其行爲

使用緩存的優勢

• 緩存減小了亢餘數據的傳輸，節省了你的網絡費用
• 緩存緩解了網絡瓶頸的問題，不須要更多的帶寬就可能更快的加載頁面
• 緩存下降了對原始服務器的要求。服務器能夠更快的響應，避免過載的出現
• 緩存下降了距離時延，由於從較遠的地方加載頁面會更慢一些

緩存的拓撲結構

私有緩存

私有緩存一般指的就是本地的緩存，不僅僅指瀏覽器緩存，npm、yarn、brew 等等，這些包管理器的緩存也屬於此列。

公用緩存

通常代理服務器可能會容許緩存資源，當用戶發送請求的時候，會先通過代理，若是代理上邊緩存的資源足夠新鮮，就能夠直接返回而不須要向原始服務器進行請求。

緩存的處理步驟（摘自 HTTP 權威指南）

1. 接收 ---- 緩存從網絡中讀取抵達的請求報文
2. 解析 ---- 緩存對報文進行解析，提取 URL 和各類首部
3. 查詢 ---- 緩存查看是否有本地副本可用，若是沒有，就獲取一份副本（並保存在本地）
4. 新鮮度檢測 ---- 緩存查看已緩存副本是否足夠新鮮，若是不是，就詢問服務器是否有任何更新。
5. 建立響應 ---- 緩存會用新的首部和已緩存的主體來構建一條響應報文。
6. 發送 ---- 緩存經過網絡將響應發回給客戶端
7. 日誌 ---- 緩存可選地建立一個日誌文件條目來描述這個事務

其中 新鮮度檢測 是重中之重，接下來大部份內容主要說這個問題。

緩存如何處理

在接收到請求報文並解析以後，瀏覽器首先在緩存中進行查找，判斷其是否命中緩存。若是命中緩存且資源足夠新鮮，則直接從瀏覽器本身的緩存中讀取對應的資源，不會向服務器發請求。建立響應，並設置響應爲 200，並進行響應頭的改造等等。若是資源不夠新鮮，就須要進行服務器再驗證，再對資源進行一系列的操做。上面的過程看似很合理，可是在開發中咱們還會遇到一些因爲緩存致使的問題。有一個很常見的場景：通常狀況下，開發者都會選擇使用 CDN 服務器來託管靜態資源，來加速靜態資源的請求速度。對於這些資源，CDN 通常的設置是容許資源進行緩存。因爲緩存命中以後，瀏覽器會直接從緩存中加載，那麼即便線上的靜態資源發生了變化，仍然沒什麼卵用。因此通常的解決辦法是在靜態資源上加一個哈希值，用來標識靜態資源的版本，同時在 html 文件中實時更新資源的版本。這樣的解決辦法則要求開發者設置不容許瀏覽器每次加載 html 頁面時候都要向服務器驗證。固然也不推薦把 html 文檔也放到 CDN 上「加速」。

緩存的新鮮度檢測

當某個請求命中緩存的時候，響應狀態值爲 200。在 Chrome 中的開發工具 network 卡中其 size 值會爲 from cache，判斷是否 from cache 是經過其餘的方法進行實現的，並非根據響應的狀態值進行判斷。緩存能夠經過 Expires 或者 Cache-Control: max-age 這兩個響應頭來配置，都用來表示資源在客戶端容許被緩存的時間。其中 Expires 是 HTTP/1.0+ 提出的一個用來表資源過時時間的響應頭，Cache-Control: max-age 則是 HTTP/1.1 推薦使用的。他們解決的問題是相同的，不過 Expires 設定的時間是基於服務器時間的絕對時間，也就是會設置一個過時時間，超過這個時間點以後認爲資源不夠新鮮，須要更新。同時須要注意，使用過時時間的時候，全部的 HTTP 日期和時間都會在格林尼治（GMT）過時。也就是 0 時區。若是用戶處在不一樣的時區內，就須要根據用戶所在的時區進行定製過時時間，這樣就會帶來一系列的玄學問題。好比指望一個資源在 2018 年 7 月 14 日凌晨 0 點過時，對於在東八區來講，格林尼治時間比東八區時間要晚 8 小時，那麼首部則須要設置以下：

Expires: Fri, 13 Jul 2018, 16:00:00 GMT
複製代碼

換算到東八區恰好是 14 日凌晨 0 點。而 Cache-Control: max-age 則是設置一個相對時間，max-age 的值是資源的最大的合法存活時間，以秒爲單位。這個時間不會由於時差問題而致使差別，因此比較推薦使用。當兩個首部同時出現且 HTTP 版本都支持的話，後者的優先級較高。前面的內容都是假設請求命中強緩存且資源並無過時，那麼若是命中了強緩存可是資源已通過期了呢？固然現實的場景是咱們通常會設置緩存時間爲一年，也就是 max-age 值爲 315360000。可是這種場景也不是不存在，須要考慮。這會涉及到一個稱爲 服務端再驗證 的狀況。當資源已通過期可是服務端的資源沒有任何的變化，那麼緩存只須要取得新的首部，包括一個新的過時日期，並對緩存中的首部進行更新。

服務端再驗證

Cache-Control 優先級高於 Expires 首部，通常經常使用的 Cache-Control 的取值有如下三種：

取值	含義
no-store	不容許緩存
no-cache	在回源驗證前不容許複用緩存
max-age	文檔最大合法存活時間

Cache-Control 可用取值有不少，其中響應能夠出現的值有 9 種，請求能夠出現的值有 7 種。支持自定義，只要服務端識別就 OK。

對於 Cache-Control: no-store，意味着徹底禁止緩存對響應複製，緩存一般像非緩存代理服務器同樣，向客戶端轉發一條 no-store 響應，而後刪除對象。對於 Cache-Control: no-cache，意味着響應其實是能夠存儲在本地緩存區中的。只是在與原始服務器進行新鮮度再驗證以前，緩存不能再提供給客戶端使用。其實這個首部使用 do-not-serve-from-cache-without-revalidation 更恰當一些，可是它太長了。HTTP/1.1 一樣提供了 Pragma: no-cache 首部，目的是爲了兼容於 HTTP/1.0+。可是因爲如今 HTTP/1.0+ 基本已經淘汰，故再也不深刻進行了解。只要是和 HTTP/1.1 或者 HTTP/2 應用進行交互時候，都應該使用 Cache-Control: no-cache 來進行交互。事實上 Pragma 的優先級最高，不過淘汰的東西就讓它安靜的消失就行了。對於 Cache-Control: max-age，用來標識文檔最大合法存活時間，對於共享緩存，還會有一個 s-maxage 行爲和 max-age 類似，其單位一樣爲秒。當 max-age 值爲 0 時候，每次訪問的時候都會進行資源的請求。對於 Expires 首部，則是 HTTP/1.0+ 提供用於控制緩存的首部，值爲一個絕對的 GMT 時間，這個時間須要根據時區再進行轉換。nginx 是一個很是輕量級的 http 服務器，一般被用做負載均衡器。在這個項目中，筆者經過使用 nginx 的 add_header 爲響應添加 Cache-Control 首部，並設置不一樣值，來觀察 Cache-Control 不一樣值的做用，以及不一樣狀況下緩存更新狀況。

用條件方法進行再驗證

HTTP 的條件方法能夠高效的實現再驗證。HTTP 容許緩存向原始服務器發送一個「條件 GET」，請求服務器只有緩存的對象和現有的副本不一樣時，纔回送對象主體。只有條件爲真時，Web 服務器纔會返回對象，不然返回一個 304。HTTP 定義了 5 個條件請求首部。對緩存在驗證來講最有用的 2 個首部是 If-Modified-Since 和 If-None-Match。全部條件首部都是之前綴 「If-」 開頭。下面是緩存再驗證中使用的條件請求首部。

If-Modifed-Since

If-Modified-Since 在驗證請求一般能夠叫作 IMS 請求。只有當這個首部的條件爲真（即文檔修改過），一般 GET 請求就會成功執行，攜帶新首部的新文檔替換原來的緩存，同時會更新過時時間。若是文檔沒有被修改過，那麼服務端返回一個小的 304 Not Modified 報文。這個報文不會包含文檔主體，只會返回須要更新的新首部，通常會是一個新的過時時間。If-Modified-Since 首部能夠和 Last-Modified 服務器響應首部配合工做。服務端使用 Last-Modifed 首部來將最後修改日期附加給所提供的文檔。當緩存要對已緩存的文檔進行驗證的時候，就會在 If-Modified-Since 帶上攜帶有最後修改已緩存副本的日期。

If-None-Match

僅僅只有 IMS 對最後修改日期進行驗證仍是不夠的，由於會有這樣的狀況：

• 有些文檔會被週期性的重寫，儘管內容沒有變化，可是最後修改時間會變化
• 有些文檔被修改了，可是並不重要，不須要從新緩存數據
• 有些服務器不能準確判斷資源的最後修改日期
• 最後修改日期通常是秒級的變化，可是某些文件會在一秒變化不少次

爲了解決這些問題，HTTP 容許用戶對被稱做 實體標籤（ETag） 的版本標識符進行比較。ETag 目前沒有一個明確的生成方法，各方能夠自定義。在 Nginx 上能夠經過 etag off 指令關閉。Nginx 官方採用的格式是 文件最後修改時間（hex）-文件長度（hex）因爲 Etag 沒有明確的生成方法，因此就有使用 Etag 來存儲用戶的 uid 的作法，來彌補使用 cookie 追蹤用戶的不足。固然如今也有使用瀏覽器指紋追蹤的技術，具體能夠參考這個庫。言歸正傳，當首部中帶有 INM 首部的時候，服務端會根據 INM 提供的 Etag 值和當前文件實際的 Etag 值進行對比，若是兩者相同的話，就會返回 304 Not Modified。

INM 和 IMS 首部都存在

當 INM 和 IMS 首部都存在的時候，客戶端向服務端回送了實體標籤和資源過時時間，那麼只有兩個驗證都經過的時候，緩存纔會被認爲有效，服務端返回 304 Modified。不然須要返回資源並更新緩存。

三種刷新方式

1. 打開新頁面，不會帶緩存相關字段，能夠命中本地緩存
2. 普通刷新，文檔會攜帶 Cache-Control: max-age=0，進行請求而不考慮是否過時，可是關聯資源能夠在不過時的狀況下直接讀取本地緩存
3. 強制刷新，文檔會攜帶 Cache-Control: max-age=0，和 Pragma: no-cache，關聯資源也會刷新
4. 打開開發工具，勾選 disable cache 以後的刷新，全部請求都走強制刷新。
   長按兩秒識別二維碼關注 ▼