【Web緩存機制系列】2 – Web瀏覽器的緩存機制-(新鮮度 校驗值)
Web緩存的工作原理
所有的緩存都是基於一套規則來幫助他們決定什麽時候使用緩存中的副本提供服務（假設有副本可用的情況下，未被銷毀回收或者未被刪除修改）。這些規則有的在協議中有定義（如HTTP協議1.0和1.1），有的則是由緩存的管理員設置（如DBA、瀏覽器的用戶、代理服務器管理員或者應用開發者）。
瀏覽器端的緩存規則
對於瀏覽器端的緩存來講，這些規則是在HTTP協議頭和HTML頁面的Meta標簽中定義的。他們分別從新鮮度和校驗值兩個維度來規定瀏覽器是否可以直接使用緩存中的副本，還是需要去源服務器獲取更新的版本。
新鮮度（過期機制）：也就是緩存副本有效期。一個緩存副本必須滿足以下條件，瀏覽器會認為它是有效的，足夠新的：
- 含有完整的過期時間控制頭信息（HTTP協議報頭），並且仍在有效期內；
- 瀏覽器已經使用過這個緩存副本，並且在一個會話中已經檢查過新鮮度；
滿足以上兩個情況的一種，瀏覽器會直接從緩存中獲取副本並渲染。
校驗值（驗證機制）：服務器返回資源的時候有時在控制頭信息帶上這個資源的實體標簽Etag（Entity Tag），它可以用來作為瀏覽器再次請求過程的校驗標識。如過發現校驗標識不匹配，說明資源已經被修改或過期，瀏覽器需求重新獲取資源內容。
瀏覽器緩存的控制
使用HTML Meta 標簽
Web開發者可以在HTML頁面的<head>節點中加入<meta>標簽，代碼如下：
| 1 | <META HTTP-EQUIV="Pragma" CONTENT="no-cache"> |
上述代碼的作用是告訴瀏覽器當前頁面不被緩存，每次訪問都需要去服務器拉取。使用上很簡單，但只有部分瀏覽器可以支持，而且所有緩存代理服務器都不支持，因為代理不解析HTML內容本身。
可以通過這個頁面測試你的瀏覽器是否支持：Pragma No-Cache Test 。
使用緩存有關的HTTP消息報頭
一個URI的完整HTTP協議交互過程是由HTTP請求和HTTP響應組成的。有關HTTP詳細內容可參考《Hypertext Transfer Protocol — HTTP/1.1》、《HTTP協議詳解》等。
在HTTP請求和響應的消息報頭中，常見的與緩存有關的消息報頭有：
Cache-Control與Expires
Cache-Control與Expires的作用一致，都是指明當前資源的有效期，控制瀏覽器是否直接從瀏覽器緩存取數據還是重新發請求到服務器取數據。只不過Cache-Control的選擇更多，設置更細致，如果同時設置的話，其優先級高於Expires。
Last-Modified/ETag與Cache-Control/Expires
配置Last-Modified/ETag的情況下，瀏覽器再次訪問統一URI的資源，還是會發送請求到服務器詢問文件是否已經修改，如果沒有，服務器會只發送一個304回給瀏覽器，告訴瀏覽器直接從自己本地的緩存取數據；如果修改過那就整個數據重新發給瀏覽器；
Cache-Control/Expires則不同，如果檢測到本地的緩存還是有效的時間範圍內，瀏覽器直接使用本地副本，不會發送任何請求。兩者一起使用時，Cache-Control/Expires的優先級要高於Last-Modified/ETag。即當本地副本根據Cache-Control/Expires發現還在有效期內時，則不會再次發送請求去服務器詢問修改時間（Last-Modified）或實體標識（Etag）了。
一般情況下，使用Cache-Control/Expires會配合Last-Modified/ETag一起使用，因為即使服務器設置緩存時間, 當用戶點擊“刷新”按鈕時，瀏覽器會忽略緩存繼續向服務器發送請求，這時Last-Modified/ETag將能夠很好利用304，從而減少響應開銷。
Last-Modified與ETag
你可能會覺得使用Last-Modified已經足以讓瀏覽器知道本地的緩存副本是否足夠新，為什麽還需要Etag（實體標識）呢？HTTP1.1中Etag的出現主要是為了解決幾個Last-Modified比較難解決的問題：
- Last-Modified標註的最後修改只能精確到秒級，如果某些文件在1秒鐘以內，被修改多次的話，它將不能準確標註文件的新鮮度
- 如果某些文件會被定期生成，當有時內容並沒有任何變化，但Last-Modified卻改變了，導致文件沒法使用緩存
- 有可能存在服務器沒有準確獲取文件修改時間，或者與代理服務器時間不一致等情形
Etag是服務器自動生成或者由開發者生成的對應資源在服務器端的唯一標識符，能夠更加準確的控制緩存。Last-Modified與ETag是可以一起使用的，服務器會優先驗證ETag，一致的情況下，才會繼續比對Last-Modified，最後才決定是否返回304。Etag的服務器生成規則和強弱Etag的相關內容可以參考，《互動百科-Etag》和《HTTP Header definition》，這裏不再深入。
用戶操作行為與緩存
用戶在使用瀏覽器的時候，會有各種操作，比如輸入地址後回車，按F5刷新等，這些行為會對緩存有什麽影響呢？
通過上表我們可以看到，當用戶在按F5進行刷新的時候，會忽略Expires/Cache-Control的設置，會再次發送請求去服務器請求，而Last-Modified/Etag還是有效的，服務器會根據情況判斷返回304還是200；而當用戶使用Ctrl+F5進行強制刷新的時候，只是所有的緩存機制都將失效，重新從服務器拉去資源。
相關有趣的分享：
《瀏覽器緩存機制》：不同瀏覽器對用戶操作行為處理比較
《HTTP 304客戶端緩存優化的神奇作用和用法》：強行在代碼層面比對文件的Last-Modified時間，保證用戶使用Ctrl+F5進行刷新的時候也能正常返回304
哪些請求不能被緩存？
無法被瀏覽器緩存的請求：
- HTTP信息頭中包含Cache-Control:no-cache，pragma:no-cache，或Cache-Control:max-age=0等告訴瀏覽器不用緩存的請求
- 需要根據Cookie，認證信息等決定輸入內容的動態請求是不能被緩存的
- 經過HTTPS安全加密的請求（有人也經過測試發現，ie其實在頭部加入Cache-Control：max-age信息，firefox在頭部加入Cache-Control:Public之後，能夠對HTTPS的資源進行緩存，參考《HTTPS的七個誤解》）
- POST請求無法被緩存
- HTTP響應頭中不包含Last-Modified/Etag，也不包含Cache-Control/Expires的請求無法被緩存
原創文章轉載請註明：
轉載自AlloyTeam：http://www.alloyteam.com/2012/03/web-cache-2-browser-cache/
【Web緩存機制系列】2 – Web瀏覽器的緩存機制-(新鮮度 校驗值)