HTTP 協議 -- 瀏覽器緩存機制

瀏覽器緩存機制

瀏覽器緩存機制主要是 HTTP 協議定義的緩存機制。

HTTP 協議中有關緩存的緩存信息頭的關鍵字有 Cache-Control，Pragma，Expires，Last-Modified/ETag 等。

 

瀏覽器請求流程

瀏覽器第一請求流程：

 

 

 

瀏覽器再次請求流程：

 

ETag/If-None-Match

當資源過時時（Cache-Control 中 max-age 設置），發現資源有 ETag 聲明，則再次向服務器請求帶上 If-None-Match （ETag 值）。服務器收到請求後發現頭 If-None-Match，則與被請求資源相應校驗串進行對比，返回 200 或 304 。

 

Last-Modified/If-Modified-Since

當資源過時時（Cache-Control 中 max-age 設置），發現資源有 Last-Modified 聲明，則再次向服務器請求時帶上 If-Modified-Since，表示請求時間。服務器收到請求後發現頭有 If-Modified-Since ，則與被請求的資源進行最後修改時間進行對比。若最後修改時間較新，說明資源又被改動過，則響應整片資源內容（200）；若最後修改時間較舊，說明資源沒有修改，會響應 304，告知瀏覽器繼續使用保存的 cache 。

 

Last-Modified 和 ETag 區別？

ETag 出現是爲了解決 Last-Modified 幾個難解決的問題：

Last-Modified 標註的資源最後修改時間只能精確到秒級；

若某些文件被按期生成，有時它們內容沒有變化，可是 Last-Modified 卻改變了，這樣致使文件沒法使用緩存；

有可能存在服務器沒有準確獲取文件的最後時間，或者與代理服務器時間不一致。

 

ETag 由服務器自動生成，能根據準確的控制緩存。當 Last-Modified 與 ETag 一塊兒使用時，服務器會優先驗證 ETag。

 

 

瀏覽器檢查緩存機制流程

 

在用戶端，瀏覽器有一系列機制經過緩存來提高頁面加載速度。例如 IE/Chrome 都會緩存 GET 類型的 AJAX 請求，IE 甚至還會緩存 POST 類型的請求，能夠經過增長時間戳參數的方式來強制清除緩存。對於全部的靜態資源文件，最佳實踐是爲它們增長一個永不過時的長緩存。

Cache-Control 是瀏覽器緩存機制中最重要的一個配置，下面是瀏覽器加載靜態資源文件時緩存檢查機制流程：

 

 

從上能夠看出，靜態資源優化的最佳狀態是：從本地緩存資源讀取 > 304 狀態 > 200 狀態。

 

參考文章：

瀏覽器 HTTP 協議緩存機制詳解： http://www.open-open.com/lib/view/open1421744212609.html

瀏覽器緩存機制詳解： http://mangguo.org/browser-cache-mechanism-detailed/

http://www.cnblogs.com/kaiye/p/5030893.html