HTTP緩存機制與原理

緩存前言

Web緩存大體能夠分爲：數據庫緩存、瀏覽器緩存、服務器緩存（CDN、代理服務器緩存）

而瀏覽器緩存也有不少方式，好比：HTTP緩存、localstrong、cookie等，下面將側重於描述討論一下HTTP緩存的相關話題。

緩存相對於瀏覽器來講，我理解的意思讓第二次請求一樣的數據加載的更快，頁面顯示更快，減少二次請求給服務器帶來的帶寬等壓力。

瀏覽器與服務器之間通訊是經過HTTP報文發送及響應數據

• 瀏覽器--------->服務器，發送請求(request)報文
• 服務器--------->瀏覽器，返回響應(response)報文

報文主要分爲：

• 頭部（header）：定義緩存的規則明細
• 主體（body）: HTTP請求輸送的數據

緩存規則解析

兩種方式：強制緩存 與 協商緩存

區別解析： 強制緩存若是命中緩存不須要與服務器發生交互，而協商緩存不論是否命中都要和服務器發生交互，並且強制緩存的優先級高於協商緩存

1.強制緩存

在強制緩存數據未失效的狀況下，瀏覽器能夠直接使用緩存的數據，那麼瀏覽器是怎麼判斷強制緩存的數據失效了沒有呢？



瀏覽器向服務器請求數據時，服務器會將數據和緩存規則一併返回，緩存規則信息包含在響應header中，

對於強制緩存來講，響應header中會有兩個字段來標明失效規則（Expires/Cache-Control）

expires

Expires 指緩存過時的時間，超過了這個時間點就表明資源過時。

有一個問題是因爲使用具體時間，若是時間表示出錯或者沒有轉換到正確的時區均可能形成緩存生命週期出錯。而且 Expires 是 HTTP/1.0 的標準，如今更傾向於用 HTTP/1.1 中定義的 Cache-Control。兩個同時存在時也是 Cache-Control 的優先級更高。

Cache-Control

Cache-Control 主要有如下屬性：

• max-age ：指定一個時間長度，在這個時間段內緩存是有效的，單位是s。
• private : 代表響應只能被單個用戶（多是操做系統用戶、瀏覽器用戶）緩存，是非共享的，不能被代理服務器緩存
• public ：代表響應能夠被任何對象（發送請求的客戶端、代理服務器等等）緩存
• no-store ： 禁止緩存，每次請求都要向服務器從新獲取數據。
• no-cache : 須要使用協商緩存來驗證緩存數據

2.協商緩存

須要進行比較判斷是否可使用緩存，瀏覽器和服務器端經過某種驗證機制驗證當前請求資源是否可使用緩存。

瀏覽器第一次請求數據以後會將數據和響應頭部的緩存標識存儲起來。再次請求時會帶上存儲的頭部字段，服務器端驗證是否可用。若是返回 304 Not Modified，表明資源沒有發生改變可使用緩存的數據，獲取新的過時時間。反之返回 200 就至關於從新請求了一遍資源並替換舊資源

Last-modified / If-Modified-Since

Last-modified: 服務器端資源的最後修改時間，響應頭部會帶上這個標識。第一次請求以後，瀏覽器記錄這個時間，再次請求時，請求頭部帶上 If-Modified-Since 即爲以前記錄下的時間。服務器端收到帶 If-Modified-Since 的請求後會去和資源的最後修改時間對比。若修改過就返回最新資源，狀態碼 200，若沒有修改過則返回 304。

Etag/If-None-Match

優先級高於Last-Modified / If-Modified-Since

由服務器端上生成的一段 hash 字符串，第一次請求時響應頭帶上 ETag: abcd，以後的請求中帶上 If-None-Match: abcd，服務器檢查 ETag，返回 304 或 200。

關於 last-modified 和 Etag 區別：

• 某些服務器不能精確獲得資源的最後修改時間，這樣就沒法經過最後修改時間判斷資源是否更新。
• Last-modified 只能精確到秒。
• 一些資源的最後修改時間改變了，可是內容沒改變，使用 Last-modified 看不出內容沒有改變。
• Etag 的精度比 Last-modified 高，屬於強驗證，要求資源字節級別的一致，優先級高。若是服務器端有提供 ETag 的話，必須先對 ETag 進行 Conditional Request。

應用場景；

能夠考慮緩存的內容：不常常發生內容變更

• css樣式文件
• js文件
• logo、圖標
• html文件
• 能夠下載的內容

不該該被緩存的：

數據常常發生變更，敏感的一些請求（GET）

結語：

這裏參考線上的一些相關文章作了個總結，實際使用 HTTP 緩存須要後端配合配置，具體狀況具體對待。

參考文章：https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching?hl=zh-cn#etag

http://www.alloyteam.com/2016/03/discussion-on-web-caching/#prettyPhoto

https://zhuanlan.zhihu.com/p/29750583