從前端的角度理解緩存

緩存的概念分不少種，本次討論的主要就是前端緩存中的Http緩存。

緩存是怎麼回事

前端發送請求主要經歷如下三個過程，請求->處理->響應。 若是有屢次請求就須要重複執行這個過程。

重複請求的過程

如下是一個重複請求的流程圖：

從以上的流程圖能夠看書，若是用戶重複請求同一資源的話，會對服務器資源形成浪費，服務器重複讀取資源，發送給瀏覽器後瀏覽器重複下載，形成沒必要要的等待與消耗。

緩存讀取的過程

緩存讀取就是瀏覽器在向服務器請求資源以前，先查詢一下本地緩存中是否存在須要的資源，若是存在，那便優先從緩存中讀取。當緩存不存在或者過時，再向服務器發送請求。

如和開啓Http緩存並對緩存進行設置，是本次討論的關鍵。

緩存的類型

瀏覽器有以下常見的幾個字段：

1. expires: 設置緩存過時的時間
2. private: 客戶端能夠緩存
3. public: 客戶端和代理服務器均可緩存
4. max-age=xxx: 緩存的內容將在 xxx 秒後失效
5. no-cache: 須要使用對比緩存來驗證緩存數據
6. no-store: 全部內容都不會緩存，強制緩存，對比緩存都不會觸發
7. last-modified: 內容上次被修改的時間
8. Etag: 文件的特殊標識

強制緩存和協商緩存

緩存方法能夠分爲強制緩存與協商緩存。

從字面理解，強制緩存的方式簡單粗暴，給cache設置了過時時間，超過這個時間以後cache過時須要從新請求。上述字段中的expires與cache-control中的max-age都屬於強制緩存。

協商緩存根據一系列條件來判斷是否可使用緩存。

強制緩存優先級高於協商緩存

強制緩存

expires

expires給瀏覽器設置了一個絕對時間，當瀏覽器時間超過這個絕對時間以後，從新向服務器發送請求。

Expires: Fri, 04 Jan 2019 12:00:00 GMT

這個方法簡單直接，直接設定一個絕對的時間 (當前時間+緩存時間)。可是也存在隱患，例如瀏覽器當前時間是能夠進行更改的，更改以後expires設置的絕對時間相對不許確，cache可能會出現長久不過時或者很快就過時的狀況。

cache-control: max-age

爲了解決expires存在的問題，Http1.1版本中提出了cache-control: max-age，該字段與expires的緩存思路相同，都是設置了一個過時時間，不一樣的是max-age設置的是相對緩存時間開始日後多久，所以不存在受日期不許確狀況的影響。

可是強制緩存存在一個問題，該緩存方式優先級高，若是在過時時間內緩存的資源在服務器上更新了，客服端不能及時獲取最新的資源。

協商緩存

協商緩存解決了沒法及時獲取更新資源的問題。如下兩組字段，均可以對資源作標識，由服務器作分析，若是未進行更新，那返回304狀態碼，從緩存中讀取資源，不然從新請求資源。

last-modify

last-modify告知了客戶端上次修改該資源的時間，

Last-Modified: Wed, 02 Jan 2019 03:06:03 GMT

瀏覽器將這個值記錄在if-modify-since中(瀏覽器自動記錄了該字段信息)，下一次請求相同資源時，與服務器返回的last-modify進行比對，若是相等，則表示未修改，響應 304；反之，則表示修改了，響應 200 狀態碼，並返回數據。

last-modify以秒爲單位進行更新，若是小於該單位高頻進行更新的話，不適合採用該方法。

ETag

ETag是對資源的特殊標識

Etag: W/"e563df87b65299122770e0a84ada084f"

請求該資源成功以後，將返回的ETag存入if-none-match字段中(瀏覽器自動記錄了該字段信息)，一樣在請求資源時傳遞給服務器，服務器查詢該編碼對應的資源有無更新，無更新返回304狀態，更新返回200並從新請求。

如下有個小例子，查詢書籍更新：

當書籍信息查詢以後，再次查詢，服務器根據資源的ETag查詢得知該資源沒有進行更新，返回304狀態碼。

更新返回的數據信息，再次查詢，返回200狀態碼，從新進行請求：

從返回的Request Headers能夠看出，再次請求時，瀏覽器自動發送了If-Modified-Since與If-None-Match兩個字段，瀏覽器根據這兩個字段中（If-None-Match 優先級大於 If-Modified-Since）來判斷是否修改了資源。

ETag如何計算

ETag是針對某個文件的特殊標識，服務器默認採用SHA256算法生成。也能夠採用其餘方式，保證編碼的惟一性便可。

緩存的優先級

根據上文優缺點的比對，能夠得出如下的優先級順序：

Cache-Control > Expires > ETag > Last-Modified

若是資源須要用到強制緩存，Cache-Control相對更加安全，協商緩存中利用ETag查詢更新更加全面。

圖片來源:瀏覽器緩存機制詳解

緩存存儲在哪

disk cache

disk cache爲存儲在硬盤中的緩存，存儲在硬盤中的資源相對穩定，不會隨着tab或瀏覽器的關閉而消失，能夠用來存儲大型的，需長久使用的資源。

當硬盤中的資源被加載時，內存中也存儲了該資源，當下次改資源被調用時，會優先從memory cache中讀取，加快資源的獲取。

memory cache

memory cache即存儲在內存中的緩存，內存中的內容會隨着tab的關閉而釋放。

當接口狀態返回304時，資源默認存儲在memory cache中，當頁面關閉後，從新打開須要再次請求。

這兩種存儲方式的區別能夠參考該回答

When you visit a URL in Chrome, the HTML and the other assets(like images) on the page are stored locally in a memory and a disk cache. Chrome will use the memory cache first because it is much faster, but it will also store the page in a disk cache in case you quit your browser or it crashes, because the disk cache is persistent.

當您訪問chrome中的URL時，頁面上的HTML和其餘資產（如圖像）將本地存儲在內存和磁盤緩存中。Chrome將首先使用內存緩存，由於它的速度快得多，但它也會將頁面存儲在磁盤緩存中，以防您退出瀏覽器或它崩潰，由於磁盤緩存是持久的。

爲何有的資源一會from disk cache，一會from memory cache

三級緩存原理

1. 先去內存看，若是有，直接加載
2. 若是內存沒有，擇取硬盤獲取，若是有直接加載
3. 若是硬盤也沒有，那麼就進行網絡請求
4. 加載到的資源緩存到硬盤和內存，下次請求能夠快速從內存中獲取到

爲何有的請求狀態碼返回200，有的返回304

200 from memory cache

不訪問服務器，直接讀緩存，從內存中讀取緩存。此時的數據時緩存到內存中的，當關閉進程後，也就是瀏覽器關閉之後，數據將不存在。

可是這種方式只能緩存派生資源。

200 from disk cache

不訪問服務器，直接讀緩存，從磁盤中讀取緩存，當關閉進程時，數據仍是存在。

這種方式也只能緩存派生資源

304 Not Modified

訪問服務器，發現數據沒有 更新，服務器返回此狀態碼。而後從緩存中讀取數據。

薄荷應用

舉一個簡單的小栗子，以薄荷的減肥羣頁面爲討論對象，查看一下資源加載的狀況：

這些圖片都是從硬盤中讀取，由於沒有在內存中獲取到響應的資源，當咱們刷新頁面時，這個資源由於從硬盤中讀取時，也存儲到了內存中，再次獲取就是從內存中獲取了：

當咱們沒有關閉頁面時，內存中的資源始終存在，從新打開則內存釋放。

CDN緩存

CDN邊緣節點緩存策略因服務商不一樣而不一樣，但通常都會遵循http標準協議，經過http響應頭中的Cache-control: max-age的字段來設置CDN邊緣節點數據緩存時間。

當客戶端向CDN節點請求數據時，CDN節點會判斷緩存數據是否過時，若緩存數據並無過時，則直接將緩存數據返回給客戶端；不然，CDN節點就會向源站發出回源請求，從源站拉取最新數據，更新本地緩存，並將最新數據返回給客戶端。

如何合理應用緩存

強制緩存優先級最高，而且資源的改動在緩存有效期內都不會對緩存產生影響，所以該方法適用於大型且不易修改的的資源文件，例如第三方CSS、JS文件或圖片資源，文件後能夠加上hash進行版本的區分。建議將此類大型資源存入disk cache，由於存在硬盤中的文件資源不易丟失。

協商緩存靈活性高，適用於數據的緩存，根據上述方法的對比，採用Etag標識進行對比靈活度最高，並考慮將數據存入內存中，由於內存加載速最快，而且數據體積小，不會佔用大量內存資源。