HTTP緩存機制

⭐HTTP緩存機制有兩種 強緩存，協商緩存。

第一次發起http請求

一、強緩存

是利用http的Header實現的：一、Expires 和一、Cache-Control

Expires和Cache-Control:max-age 都是用來判斷在瀏覽器端的緩存是否超過生命期限，緩存只有在生命期限之內纔算有效。

區別：

一、Expires指定一個絕對的過時時間(相似於 2019.10.19 08:00:00)，

客戶端和服務器時間不一樣步致使Expires的配置出現問題並且很容易在配置後忘記具體的過時時間，致使過時來臨出現浪涌現象；

二、max-age 指定的是從文檔被訪問後的存活時間，這個時間是個相對值(好比:3600s),相對的是文檔第一次被請求時服務器記錄的Request_time(請求時間)

若是沒過時的話直接取出緩存中的數據，過時的話從新向服務器發起請求。

補上cache-control頭的相關數據

二、協商緩存

利用http的Header實現的：一、Last-modified 二、Etag

經過last-modified （If-Modefied-Since）（比較時間）或者Etag(If-None-Match)（意思是Etag標識是否能夠匹配到）來判斷是否須要更新。

對比：

①強緩存優先於協商緩存。

②協商緩存的時候，Etag優先級比last-modefied高。

Etag的精確度比last-modefied高，不過在性能上Etag要遜色，畢竟last-modefied只須要記錄時間，而Etag須要服務器經過算法來計算出一個hash值。

③強制緩存的時候，Cache-Control優先級高於Expires。

前者是http1.1 後者是http1.0

強制緩存有個毛病是它不關心資源有沒有改變有沒有更新是否是最新的，它只關心有沒有過時。

關於Etag和last-modified的對比，本文在末尾將更詳細講解。

一、若是判斷後結論是不須要更新，協商緩存就算是生效了。 服務端直接返回狀態碼304（表示你說請求的內容不須要服務端傳送，直接使用本地緩存中的數據便可），使用緩存。

協商緩存生效

二、若是發現須要更新，協商緩存失效，服務端就會返回狀態碼200， 從新返回資源以及Etag緩存標識，再存入瀏覽器緩存中。

協商緩存失效

三、怎麼知道判斷瀏覽器默認是設置爲強緩存仍是協商緩存呢？

根據的是第一次請求時返回的響應頭來決定的。

四、若是什麼緩存策略都沒設置，那麼瀏覽器會怎麼處理？

對於這種狀況，瀏覽器會採用一個啓發式的算法，一般會取響應頭中的 Date 減去 Last-Modified 值的 10% 做爲緩存時間。

五、css，js，html文件適合強緩存仍是協商緩存？

css，js建議強緩存

html，圖片文件 協商緩存

六、Etag和Last-modified

①Last-Modified ：

一、若是本地打開緩存文件，即便沒有對文件進行修改，但仍是會形成 Last-Modified 被修改，服務端不能命中緩存致使發送相同的資源。

二、 Last-Modified 只能以秒計時，若是在不可感知的時間內修改完成文件，那麼服務端會認爲資源仍是命中了，不會返回正確的資源。

例子：（用0.5秒的時間修改文件，服務端認爲時間對比以前的last-modified是同樣的，不必從新請求）

---

②ETag和If-None-Match

正是由於根據文件修改時間來決定是否緩存存在缺陷，因此以在 HTTP / 1.1 出現了 ETag 和If-None-Match，能夠直接根據文件內容是否修改來決定緩存策略。

Etag是服務器響應請求時，返回當前資源文件的一個惟一標識(由服務器生成)，

只要資源有變化，Etag就會從新生成。瀏覽器在下一次加載資源向服務器發送請求時，會將上一次返回的Etag值放到request header裏的If-None-Match裏，

服務器只須要比較客戶端傳來的If-None-Match跟本身服務器上該資源的ETag是否一致，就能很好地判斷資源相對客戶端而言是否被修改過了。

若是服務器發現ETag匹配不上，那麼直接以常規GET 200回包形式將新的資源（固然也包括了新的ETag）發給客戶端；

若是ETag是一致的，則直接返回304知會客戶端直接使用本地緩存便可。

緩存機制圖解

⭐ 總結

瀏覽器緩存機制的關鍵在於：

瀏覽器每次發起請求，都會如今瀏覽器緩存裏面找一找有沒有與請求資源相對應的 緩存標識 和 資源。
  對於每次從服務端請求到的結果和緩存標識，都要存到瀏覽器緩存中。
複製代碼

想看更加詳細的內容，推薦這篇：www.jianshu.com/p/54cc04190…