http緩存詳解，http緩存推薦方案

前言

經過本文，你將瞭解到http緩存機制是怎樣的，no-cache到底有沒有緩存，地址欄回車，F5，ctrl+F5的區別，以及當下較爲推薦的緩存方案等。

自從和前端組的同事一塊兒整了個前端掃盲計劃，想着給他們講點什麼，花了一週時間整理了http緩存的知識，花了一個多小時也算幫同事們從新理了理這玩意。本文借用了部分優秀文章的思路，這裏就當一個整理分享了。

那麼咱們開始~

說明

閱讀前提：http緩存主要針如css，js，圖片等更新頻率不大的靜態文件。

首先得先明確這個概念，否則如下的概念以及例子，都會顯得不太有意義，或者不是那麼完美。

1、http緩存請求相應頭

閱讀本文，先大概瞭解這些緩存字段是必須的，後面也會細說，先留個印象。

1.Cache-Control
請求/響應頭，緩存控制字段，能夠說是控制http緩存的最高指令，要不要緩存也是它說了算。

它有如下經常使用值

　　1.1 no-store：全部內容都不緩存

　　1.2 no-cache：緩存，可是瀏覽器使用緩存前，都會請求服務器判斷緩存資源是不是最新，它是個比較高貴的存在，由於它只用不過時的緩存。

　　1.3  max-age=x(單位秒) 請求緩存後的X秒再也不發起請求，屬於http1.1屬性，與下方Expires(http1.0屬性)相似，但優先級要比Expires高。

　　1.4 s-maxage=x(單位秒) 代理服務器請求源站緩存後的X秒再也不發起請求，只對CDN緩存有效(這個在後面會細說)

　　1.5 public 客戶端和代理服務器(CDN)均可緩存

　　1.6 private 只有客戶端能夠緩存

2.Expires
響應頭，表明資源過時時間，由服務器返回提供，GMT格式日期，是http1.0的屬性，在與max-age(http1.1)共存的狀況下，優先級要低。
3.Last-Modified
響應頭，資源最新修改時間，由服務器告訴瀏覽器。
4.if-Modified-Since
請求頭，資源最新修改時間，由瀏覽器告訴服務器(其實就是上次服務器給的Last-Modified，請求又還給服務器對比)，和Last-Modified是一對，它兩會進行對比。
5.Etag
響應頭，資源標識，由服務器告訴瀏覽器。
6.if-None-Match
請求頭，緩存資源標識，由瀏覽器告訴服務器(其實就是上次服務器給的Etag)，和Etag是一對，它兩會進行對比。

2、爲何要使用HTTP緩存

假設咱們請求一次服務器，請求頭大小1kb，響應頭大小1kb，請求文件10kb。

1次請求流量：12kb

10次請求流量：120kb

N次請求：12*N....

這只是假想的一次請求，但事實上的請求不只是請求文件，請求客戶端也會更多，那麼問題就很明顯：

1.客戶端每次都要請求服務器，浪費流量(好比手機端？)。

2.服務器每次都得提供查找，下載，請求用戶基礎若是較大，服務器存在較大壓力。

3.客戶端每次請求完都要進行頁面渲染，用戶體驗較差。

那麼咱們是否能夠將請求的文件存放起來使用，好比使用http緩存。

3、使用http緩存

1.讓服務器與瀏覽器約定一個文件過時時間——Expires(GMT時間格式)。

平常請求對話

第一次請求

瀏覽器：服務器服務器，我如今須要一個a.js文件，幫我找找，而後給我。

服務器：次次找我要，煩不煩，文件給你能夠，咱們約定個時間(Expires)，時間沒到別來煩我了，返回了a.js以及過時時間Expires。

後續請求.....

瀏覽器會先對比當前時間是否已經大於Expires，也就是判斷文件是否超過了約定的過時時間。

時間沒過，不發起請求，直接使用本地緩存。

時間過時，發起請求，繼續上述的瀏覽器與服務器的談話平常。

問題：假設Expires已過時，瀏覽器再次請求服務器，但a.js相比上次並未作任何改變，那此次請求咱們是否經過某種方式加以免？

2.讓服務器與瀏覽器在約定文件過時時間的基礎上，再加一個文件最新修改時間的對比——Last-Modified與if-Modified-Since

平常請求對話

第一次請求

瀏覽器：服務器服務器，我如今須要一個a.js，你找到了給我，順便給我個過時時間，時間沒到我保證不煩你！

服務器：哈賣批，行，過時時間我給你，另外再給你一個文件最新修改時間Last-Modified，到時候文件過時了咱兩覈對文件修改時間，對得上你就別煩我，返回a.js+Expires+Last-Modified。

後續請求....

Expires未過時，瀏覽器機智的使用本地緩存，省得捱打。

Expires過時，服務器帶上了文件最新修改時間if-Modified-Since(也就是上次請求服務器返回的Last-Modified)，服務器將if-Modified-Since與Last-Modified作了個對比。

if-Modified-Since 與Last-Modified不相等，服務器查找了最新的a.js，同時再次返回Expires與全新的Last-Modified

if-Modified-Since 與Last-Modified相等，服務器返回了狀態碼304，文件沒修改過，你仍是用你的本地緩存。

以下圖，請求頭與響應頭文件修改時間相同，因此返回了304，使用本地緩存：

 

 問題：瀏覽器端能夠隨意修改Expires，Expires不穩定，Last-Modified只能精確到秒，假設文件是在1s內發生變更，Last-Modified沒法感知到變化，這種狀況下瀏覽器永遠拿不到最新的文件(假想極端狀況)。

3.讓服務器與瀏覽器在過時時間Expires+Last-Modified的基礎上，再增長一個文件內容惟一對比標記——Etag與If-None-Match。哦對了，咱們說Expires不穩定，這裏咱們再加入一個max-age來加以代替(cache-control其中一個值)。

平常對話

第一次請求

瀏覽器：服務器服務器，你懂得~~~~~~

服務器：我不懂！a.js我給你，過時時間我也給你，再給你一個max-age=60(單位秒)，Last-Modified你也給我收好，再加一個文件內容惟一標識符Etag。

後續請求....

60S內，不發起請求，直接使用本地緩存。（max-age=60表明請求成功緩存後的60S內再也不發起請求，與Expires類似，同時存在max-age優先級要比Expires高，區別後面具體說）

60S後，瀏覽器帶上了if-Modified-Since 與If-None-Match(上次服務器返回來的Etag)發起請求，服務器對比If-None-Match與Etag(不對比if-Modified-Since與Last-Modified了，Etag優先級比Last-Modified高，畢竟更精準)

If-None-Match與Etag不相等，說明a.js內容被修改過，服務器返回最新a.js與全新的Etag與max-age=60與Last-Modified與Expires

If-None-Match與Etag相等，說明a.js文件內容無任何改變，返回304，告訴瀏覽器繼續使用以前的本地緩存。

以下圖，服務器Etag與If-None-Match相同，因此返回了狀態碼304，因爲優先級問題，雖然也有if-Modified-Since與Last-Modified，但這裏不會對二者作對比。

問題：咱們已經能夠精確的對比服務器文件與本地緩存文件差別，但其實上面方案的演變都存在一個較大缺陷， max-age或Expires不過時，瀏覽器沒法主動感知服務器文件變化。

4、http緩存方案

1.md5/hash緩存

經過不緩存html，爲靜態文件添加MD5或者hash標識，解決瀏覽器沒法跳過緩存過時時間主動感知文件變化的問題。

爲何這麼作？實現原理是什麼？

咱們前面說的http緩存方案，服務器與瀏覽器的文件修改時間對比，文件內容標識對比，前提基礎都是創建在二者文件路徑徹底相同的狀況下。

module/js/a-hash1.js與module/js/a-hash2.js是兩個徹底不一樣的文件，假想瀏覽器第一次加載頁面，請求並緩存了module/js/a-hash1.js，第二次加載，文件指向變成了module/js/a-hash2.js，瀏覽器會直接從新請求a-hash2.js，由於這就是兩個徹底不一樣的文件，哪裏還有什麼http緩存文件對比，t經過這種作法，咱們就能夠從根本上解決過時時間沒到瀏覽器沒法主動請求服務器的問題。所以咱們只須要在項目每次發佈迭代將修改過的靜態文件添加不一樣的MD5或hash標識就好啦。

注意，這裏不推薦緩存html文件(或許有更好的作法，歡迎留言)，這樣每次html加載渲染均可以感知文件變化，反正文件沒變仍是使用本地緩存，文件名都變了說明修改過，從新請求緩存就行了。

怎麼改？一個個手動去修改？那不得累死。webpack提供了webpack-md5-hash插件，能夠幫助開發者在項目發佈時自動修改文件標識。

咱們公司由於用的是fis3打包工具，這裏使用的是fis3構建-文件指紋(搜文件指紋)，原理都差很少。

2.CDN緩存(做爲了解)

在文章開頭cache-control相關值介紹中，提到了例如s-maxage代理服務器的概念，本人在整理http緩存相關知識點時，從同窗口中瞭解到了也較爲推薦的http緩存方案——CDN緩存，這裏就做爲一個拓展吧，正常的緩存仍是推薦MD5緩存。

2.1什麼是CDN

瞭解CDN緩存，先得知道什麼是CDN，CDN是構建在網絡之上的內容分發網絡，依靠部署在各地的邊緣服務器，經過中心平臺的負載均衡、內容分發、調度等功能模塊，使用戶就近獲取所需內容，下降網絡擁塞，提升用戶訪問響應速度和命中率。CDN的關鍵技術主要有內容存儲和分發技術(較爲官方的說明)。

以前看到一個不錯的例子，這裏直接拿過來舉例說說CDN。

假設多年前咱們所在的城市只有一個火車站，每次春運，整個城市的人都得去這個火車站買票，人流量以及購票的需求可想而知有多大，爲了緩解這個問題，城市的不一樣區，都出現了火車票代售點，這樣每一個區的人均可以就近買票了，火車站總站的壓力就這樣大大減輕了。

咱們能夠把每一個區的售票點稱之爲CDN節點，也就是前面所說的代理服務器。簡而言之，咱們能夠把CDN理解成瀏覽器與服務器之間的臨時站點，它會替服務器處理一部分的瀏覽器請求，從而整理減輕總服務器的壓力。

咱們能夠把CDN的價值概括爲：

1.CDN經過分流的形式，大大減輕源站的訪問壓力。

2.就像住的區比較偏遠，每次買票要去城市中心，而這個區後來有了分站，火車票就能夠就近購買同樣。CDN也解決了跨地區訪問問題，根本上爲訪問提供了加速。

2.2什麼是CDN緩存

CDN邊緣節點緩存數據，當瀏覽器請求，CDN將代替源站判斷並處理此處請求。

平常請求對話

第一次請求

瀏覽器：服務器老哥，我須要a.js.

服務器：（惱羞成怒）文件我給我小弟CDN了，之後你要這個找CDN，別找我了。成功返回a.js給CDN，CDN進行緩存，同時CDN返回給瀏覽器，瀏覽器本身也進行了緩存(cache-control的值public就是用在這的)。

後續請求...

瀏覽器：服務器，我緩存時間到了，趕忙給我對比下文件，看看要不要從新返回給我。

CDN節點：打住打住，叫喚啥呢，我大哥比較忙，文件給我看看，請求被代理了。

狀況1：CDN節點本身緩存的文件未過時，因而返回了304給瀏覽器，打回了此次請求。

狀況2：CDN節點發現本身緩存的文件過時了，爲了保險起見，本身發起請求給了服務器(源站)，成功拿回了最新數據，而後再交給與了瀏覽器。

其實說到這，CDN緩存的問題也跟前面的http緩存同樣，CDN緩存時間不過時，瀏覽器始終被攔截，沒法拿到最新的文件。

可是咱們迴歸http緩存問題本質，緩存自己針對於更新頻率不高的靜態文件，其次，CDN緩存提供了分流以及訪問加速其它優點條件。這裏我問過同窗，獲得的信息是，CDN相似一個平臺，是能夠經過登陸，手動更新CDN緩存的，變相解決了瀏覽器緩存沒法手動控制的問題。

那麼兩種http緩存方案就說到這裏了，接下來談談http緩存其它的一些問題和概念。

5、瀏覽器地址欄回車，新開窗口，F5刷新，CTRL+F5刷新等瀏覽器操做對HTTP緩存的影響

在利用fiddler抓包看不一樣網站緩存時，發現了一個有趣的問題，大部分網站的cache-control都設置的爲no-cache。

我在前面說了，no-cache不是不緩存，要緩存，可是瀏覽器在協商性緩存狀況下，都會無條件像服務器發起請求，判斷本身的緩存是否是最新，若是是就接着用，不是就請求最新的文件，緩存起來用，以此循環。

那麼有必要設置過時時間Expires與max-age嗎？有！

當咱們第一次瀏覽一個頁面，關閉後，第二次再打開仍是屬於新開窗口行爲，若是設置了緩存時間，新開窗口會走強緩存，能夠避免反覆的文件下載，加快頁面渲染，提高用戶體驗性。

(其實一開始我是以爲Expires與max-age是不須要設置的，直到我使用pageSpeed對公司網站作了個性能評分，發現仍是推薦使用緩存時間，結合上面的話，實際上是有道理的)

 

對於上面的話不理解不要緊，這裏結合百度百科與其它博客的概念，咱們對瀏覽器的不一樣行爲對緩存的影響作一個總結。

1.瀏覽器地址欄回車，或者點擊跳轉按鈕，前進，後退，新開窗口，這些行爲，會讓Expires，max-age生效，也就是說，這幾種操做下，瀏覽器會判斷過時時間，再考慮要不要發起請求，固然Last-Modified和Etag也有效。

2.F5刷新瀏覽器，或者使用瀏覽器導航欄的刷新按鈕，這幾種，會忽略掉Expires，max-age的限制，強行發起請求，Last-Modified和Etag在這種狀況下也有效。

3.CTRL+F5是強制請求，全部緩存文件都不使用，所有從新請求下載，所以Expires，max-age，Last-Modified和Etag所有失效。

但事實上，咱們不多用到地址欄回車，地址欄跳轉，因此要觸發緩存時間的判斷，還須要特定的操做，站在個人理解，綜合考慮下，纔有了這麼多網站的cache-control設置爲no-cache，也就是使用緩存前都判斷文件是否爲最新，更爲合理。

6.強緩存與協商性緩存(弱緩存)

瞭解了上面不一樣瀏覽器行爲對http緩存的不一樣影響，理解強緩存與協商性緩存就很容易了。

強緩存：不發起http請求，直接使用本地緩存，好比瀏覽器地址欄回車，使用瀏覽器的刷新按鈕，在Expires或max-age生效的狀況下，觸發的都是強緩存。

協商性緩存(弱緩存)：在使用本地緩存前，先與服務器協商，覈對緩存文件是否爲最新。好比設置了cache-control=no-cache，無論你作任何操做，都會發起請求，這一類就是協商性緩存了。

7.max-age和Expires的區別

在用fiddler抓包的時候，發現很多網站同時設置了max-age和Expires，爲毛要設置兩個，功能不都差很少嗎，二者區別是啥？

1.max-age是http1.1的屬性，Expires是http1.0的屬性，爲了作到向下兼容，通常寫兩個。但如在1.1環境下，max-age優先級比Expires高。

2.max-age是相對過時時間，Expires是絕對過時時間。max-age在瀏覽器成功緩存文件後，只需相對請求成功以後的多長時間再也不發起請求就行了，而Expires老是須要服務器返回一個精準的GMT格式的日期，並以這個日期爲標準來判斷緩存是否過時，想對就比較麻煩，因此纔有了max-age這樣的存在來代替它。

同理，no-cache和 Pargma也是這樣的存在，一個是1.1的屬性，一個是1.0，向下兼容，同時寫了兩個。

好了，說到這裏其實介紹的差很少了，瞭解了這些，瀏覽器和服務器之間也能過上幸福的生活了。

 

對了，上面抓包工具是fiddler，別找中文版了，不存在的，直接下，官方也有使用說明文檔，這裏就很少說了。

 

參考資料：

1.面試精選之http緩存

2.CDN緩存那些事