HTTP緩存機制

HTTP緩存機制

HTTP緩存機制主要由如下三部分組成

緩存存儲策略

這個策略的做用只有一個，用於決定 Http 響應內容是否可緩存到客戶端。主要經過Cache-Control來控制。

• Cache-Control

  • max-age

  • public

  • private

  • no-cache

  • no-store

除了no-store其餘都會被緩存到客戶端。

緩存過時策略

這個策略的做用也只有一個，那就是決定客戶端是否可直接從本地緩存數據中加載數據並展現（不然就發請求到服務端獲取）

數據緩存到了本地後還須要通過判斷才能使用，那麼瀏覽器經過什麼條件來判斷呢？ 答案是：Expires，Expires 指名了緩存數據有效的絕對時間，告訴客戶端到了這個時間點（比照客戶端時間點）後本地緩存就做廢了，在這個時間點內客戶端能夠認爲緩存數據有效，可直接從緩存中加載展現。

緩存對比策略

將緩存在客戶端的數據標識發往服務端，服務端經過標識來判斷客戶端 緩存數據是否仍有效，進而決定是否要重發數據。

客戶端檢測到數據過時或瀏覽器刷新後，每每會從新發起一個 http 請求到服務器，服務器此時並不急於返回數據，而是看請求頭有沒有帶標識（ If-Modified-Since、If-None-Match）過來，若是判斷標識仍然有效，則返回304告訴客戶端取本地緩存數據來用便可（這裏要注意的是你必需要在首次響應時輸出相應的頭信息（Last-Modified、ETags）到客戶端）。若是判斷標識無效，則返回200，用新數據替換客戶端緩存。

ETags, If-None-Match

Etag是指根據實體內容生成一段hash字符串，標識資源的狀態，由服務端產生。瀏覽器會將這串字符串傳回服務器，驗證資源是否已經修改

Last-Modified, If-Modified-Since

這兩個是HTTP1.0中用來驗證資源是否過時的請求/響應頭，這兩個頭部都是日期，驗證過程與Etag相似。

總結

Http 緩存機制其實是 Http 緩存策略三個要素（緯度）相互做用的集合，因此在分析和設置 Http 報文緩存頭時，只要能從中精準的分解出緩存三要素，咱們就能很是準確的預判到緩存設置最終能達到的效果。

實踐

在html文件頭部加上以下標籤，能使該文件每次去服務端作對比，若不一樣則返回新文件，若相同則取客戶端緩存。

<meta http-equiv="pragma" content="no-cache"> 
<meta http-equiv="cache-control" content="no-cache">  
<meta http-equiv="expires" content="0">

或是在項目中添加NoCacheFilter.java文件，響應頭添加相關屬性

HttpServletResponse resp = (HttpServletResponse) response;
resp.setHeader("Cache-Control", "no-cache, must-revalidate, max-age=0, post-check=0, pre-check=0");
resp.setHeader("Pragma", "no-cache");

字段

HTTP1.0 緩存字段詳解

1. Pragma。 設置頁面是否緩存，爲Pragma則緩存，no-cache則不緩存。

2. Expires。有了Pragma來禁用緩存，天然也須要有個東西來啓用緩存和定義緩存時間。若是Pragma頭部和Expires頭部同時存在，則起做用的會是Pragma。，響應報文中Expires所定義的緩存時間是相對服務器上的時間而言的，其定義的是資源「失效時刻」，若是客戶端上的時間跟服務器上的時間不一致（特別是用戶修改了本身電腦的系統時間），那緩存時間可能就沒啥意義了。

HTTP1.1 緩存字段詳解

1. Cache-Control: 定義緩存過時時間。若報文中同時出現了 Expires 和 Cache-Control，則以 Cache-Control 爲準。

（1）max-age=600。 表示文件在本地應該緩存，且有效時長是600秒（從發出請求算起）。在接下來600秒內，若是有請求這個資源，瀏覽器不會發出 HTTP 請求，而是直接使用本地緩存的文件。

（2）no-cache。實際上她是會被緩存的，只不過每次在向客戶端（瀏覽器）提供響應數據時，==緩存都要向服務器評估緩存響應的有效性==

（3）no-store
響應不被緩存的意思。

1. Last-Modified / If-Modified-Since

（1）Last-Modified: 標示這個響應資源的最後修改時間。web服務器在響應請求時，告訴瀏覽器資源的最後修改時間。

（2）If-Modified-Since:
當資源過時時（使用Cache-Control標識的max-age），發現資源具備Last-Modified聲明，則再次向web服務器請求時帶上頭 If-Modified-Since，表示請求時間。若服務端請求資源的最後修改時間較新，則響應資源內容（HTTP 200）;若最後修改時間較舊，則響應HTTP 304，告知瀏覽器繼續使用所保存的cache。

1. Etag/If-None-Match: Etag/If-None-Match也要配合Cache-Control使用。

（1）Etag: web服務器響應請求時，告訴瀏覽器當前資源在服務器的惟一標識（生成規則由服務器以爲）

（2）If-None-Match: 當資源過時時（使用Cache-Control標識的max-age），發現資源具備Etage聲明，則再次向web服務器請求時帶上頭If-None-Match （Etag的值）。服務器與被請求資源的相應校驗串進行比對，決定返回200或304。

1. 既生Last-Modified何生Etag？

HTTP1.1中Etag的出現主要是爲了解決幾個Last-Modified比較難解決的問題：

(1) Last-Modified標註的最後修改只能精確到秒級，若是某些文件在1秒鐘之內，被修改屢次的話，它將不能準確標註文件的修改時間。

(2) 若是某些文件會被按期生成，當有時內容並無任何變化，但Last-Modified卻改變了，致使文件無法使用緩存。

(3) 有可能存在服務器沒有準確獲取文件修改時間，或者與代理服務器時間不一致等情形。

Last-Modified與ETag是能夠一塊兒使用的，服務器會優先驗證ETag，一致的狀況下，纔會繼續比對Last-Modified，最後才決定是否返回304。

小結

（1）瀏覽器第一次請求

（2） 瀏覽器第二次請求

緩存的做用

• 減小網絡帶寬消耗。

不管對於網站運營者或者用戶，帶寬都表明着金錢，過多的帶寬消耗，只會便宜了網絡運營商。當Web緩存副本被使用時，只會產生極小的網絡流量，能夠有效的下降運營成本。

• 下降服務器壓力

給網絡資源設定有效期以後，用戶能夠重複使用本地的緩存，減小對源服務器的請求，間接下降服務器的壓力。同時，搜索引擎的爬蟲機器人也能根據過時機制下降爬取的頻率，也能有- 效下降服務器的壓力。

• 減小網絡延遲，提高頁面渲染速度

帶寬對於我的網站運營者來講是十分重要，緩存的使用可以明顯加快頁面打開速度，達到更好的體驗。

參考連接

https://juejin.im/entry/59c8d...

https://segmentfault.com/a/11...

https://mp.weixin.qq.com/s/qO...

https://segmentfault.com/a/11...