全部的緩存都是基於一套規則來幫助他們決定何時使用緩存中的副本提供服務(假設有副本可用的狀況下,未被銷燬回收或者未被刪除修改)。這些規則有的在協議中有定義(如HTTP協議1.0和1.1),有的則是由緩存的管理員設置(如DBA、瀏覽器的用戶、代理服務器管理員或者應用開發者)。php
對於瀏覽器端的緩存來說,這些規則是在HTTP協議頭和HTML頁面的Meta標籤中定義的。他們分別從新鮮度和校驗值兩個維度來規定瀏覽器是否能夠直接使用緩存中的副本,仍是須要去源服務器獲取更新的版本。html
新鮮度(過時機制):也就是緩存副本有效期。一個緩存副本必須知足如下條件,瀏覽器會認爲它是有效的,足夠新的:瀏覽器
知足以上兩個狀況的一種,瀏覽器會直接從緩存中獲取副本並渲染。緩存
校驗值(驗證機制):服務器返回資源的時候有時在控制頭信息帶上這個資源的實體標籤Etag(Entity Tag),它能夠用來做爲瀏覽器再次請求過程的校驗標識。如過發現校驗標識不匹配,說明資源已經被修改或過時,瀏覽器需求從新獲取資源內容。安全
Web開發者能夠在HTML頁面的<head>節點中加入<meta>標籤,代碼以下:服務器
<META HTTP-EQUIV="Pragma" CONTENT="no-cache">測試
上述代碼的做用是告訴瀏覽器當前頁面不被緩存,每次訪問都須要去服務器拉取。使用上很簡單,但只有部分瀏覽器能夠支持,並且全部緩存代理服務器都不支持,由於代理不解析HTML內容自己加密
能夠經過這個頁面測試你的瀏覽器是否支持:Pragma No-Cache Test 。spa
一個URI的完整HTTP協議交互過程是由HTTP請求和HTTP響應組成的。有關HTTP詳細內容可參考《Hypertext Transfer Protocol — HTTP/1.1》、《HTTP協議詳解》等。firefox
Cache-Control與Expires的做用一致,都是指明當前資源的有效期,控制瀏覽器是否直接從瀏覽器緩存取數據仍是從新發請求到服務器取數據。只不過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(實體標識)呢?HTTP1.1中Etag的出現主要是爲了解決幾個Last-Modified比較難解決的問題:
Etag是服務器自動生成或者由開發者生成的對應資源在服務器端的惟一標識符,可以更加準確的控制緩存。Last-Modified與ETag是能夠一塊兒使用的,服務器會優先驗證ETag,一致的狀況下,纔會繼續比對Last-Modified,最後才決定是否返回304。Etag的服務器生成規則和強弱Etag的相關內容能夠參考,《互動百科-Etag》和《HTTP Header definition》,這裏再也不深刻。
經過上表咱們能夠看到,當用戶在按F5進行刷新的時候,會忽略Expires/Cache-Control的設置,會再次發送請求去服務器請求,而Last-Modified/Etag仍是有效的,服務器會根據狀況判斷返回304仍是200;而當用戶使用Ctrl+F5進行強制刷新的時候,只是全部的緩存機制都將失效,從新從服務器拉去資源。