前端必須知道的http緩存

相關字段簡述

RFC2616規定的47種http報文首部字段中與緩存相關的字段。

通用頭部字段

請求頭部字段

響應頭部字段

實體頭部字段

Pragma與Expires

在 http1.0 時代，給客戶端設定緩存方式可經過兩個字段——Pragma和Expires來規範。雖然這兩個字段早可拋棄，但爲了作http協議的向下兼容，你仍是能夠看到不少網站依舊會帶上這兩個字段。

Pragma

當該字段值爲no-cache的時候（事實上如今RFC中也僅標明該可選值），會知會客戶端不要對該資源讀緩存，即每次都得向服務器發一次請求才行。

Expires

有了Pragma來禁用緩存，天然也須要有個東西來啓用緩存和定義緩存時間，對http1.0而言，Expires就是作這件事的首部字段。 Expires的值對應一個GMT（格林尼治時間），好比Mon, 22 Jul 2002 11:12:01 GMT來告訴瀏覽器資源緩存過時時間，若是還沒過該時間點則不發請求。

Tips

若是Pragma頭部和Expires頭部同時存在，則起做用的會是Pragma，有興趣的同窗能夠本身試一下。

須要注意的是，響應報文中Expires所定義的緩存時間是相對服務器上的時間而言的，其定義的是資源「失效時刻」，若是客戶端上的時間跟服務器上的時間不一致（特別是用戶修改了本身電腦的系統時間），那緩存時間可能就意義了。

Cache-Control

針對上述的「Expires時間是相對服務器而言，沒法保證和客戶端時間統一」的問題，http1.1新增了 Cache-Control 來定義緩存過時時間。注意：若報文中同時出現了 Expires 和 Cache-Control，則以 Cache-Control 爲準。

也就是說優先級從高到低分別是 Pragma -> Cache-Control -> Expires 。

Cache-Control也是一個通用首部字段，這意味着它能分別在請求報文和響應報文中使用。在RFC中規範了 Cache-Control 的格式爲：

"Cache-Control" ":" cache-directive

做爲請求首部時，cache-directive 的可選值有：

做爲響應首部時，cache-directive 的可選值有：

Cache-Control 容許自由組合可選值，例如：

Cache-Control: max-age=3600, must-revalidate

它意味着該資源是從原服務器上取得的，且其緩存（新鮮度）的有效時間爲一小時，在後續一小時內，用戶從新訪問該資源則無須發送請求。 固然這種組合的方式也會有些限制，好比 no-cache 就不能和 max-age、min-fresh、max-stale 一塊兒搭配使用。

緩存校驗字段

上述的首部字段均能讓客戶端決定是否向服務器發送請求，好比設置的緩存時間未過時，那麼天然直接從本地緩存取數據便可（在chrome下表現爲200 from cache），若緩存時間過時了或資源不應直接走緩存，則會發請求到服務器去。

咱們如今要說的問題是，若是客戶端向服務器發了請求，那麼是否意味着必定要讀取回該資源的整個實體內容呢？

咱們試着這麼想——客戶端上某個資源保存的緩存時間過時了，但這時候其實服務器並無更新過這個資源，若是這個資源數據量很大，客戶端要求服務器再把這個東西從新發一遍過來，是否很是浪費帶寬和時間呢？

答案是確定的，那麼是否有辦法讓服務器知道客戶端如今存有的緩存文件，其實跟本身全部的文件是一致的，而後直接告訴客戶端說「這東西你直接用緩存裏的就能夠了，我這邊沒更新過呢，就再也不傳一次過去了」。

爲了讓客戶端與服務器之間能實現緩存文件是否更新的驗證、提高緩存的複用率，Http1.1新增了幾個首部字段來作這件事情。

Last-Modified

服務器將資源傳遞給客戶端時，會將資源最後更改的時間以「Last-Modified: GMT」的形式加在實體首部上一塊兒返回給客戶端。

Last-Modified: Fri, 22 Jul 2016 01:47:00 GMT

客戶端會爲資源標記上該信息，下次再次請求時，會把該信息附帶在請求報文中一併帶給服務器去作檢查。

• 若傳遞的時間值與服務器上該資源最終修改時間是一致的，則說明該資源沒有被修改過，直接返回304狀態碼，內容爲空。

• 若是兩個時間不一致，則服務器會發回該資源並返回200狀態碼，和第一次請求時相似。

這樣保證不向客戶端重複發出資源，也保證當服務器有變化時，客戶端可以獲得最新的資源。一個304響應比一個靜態資源一般小得多，這樣就節省了網絡帶寬。

If-Modified-Since: Last-Modified-value

示例爲 If-Modified-Since: Thu, 31 Mar 2016 07:07:52 GMT
該請求首部告訴服務器若是客戶端傳來的最後修改時間與服務器上的一致，則直接回送304 和響應報頭便可。
當前各瀏覽器均是使用的該請求首部來向服務器傳遞保存的 Last-Modified 值。

If-Unmodified-Since: Last-Modified-value

該值告訴服務器，若Last-Modified沒有匹配上（資源在服務端的最後更新時間改變了），則應當返回412(Precondition Failed) 狀態碼給客戶端。 Last-Modified 存在必定問題，若是在服務器上，一個資源被修改了，但其實際內容根本沒發生改變，會由於Last-Modified時間匹配不上而返回了整個實體給客戶端（即便客戶端緩存裏有個如出一轍的資源）。

Etag

爲了解決上述Last-Modified可能存在的不許確的問題，Http1.1還推出了 ETag 實體首部字段。 服務器會經過某種算法，給資源計算得出一個惟一標誌符（好比md5標誌），在把資源響應給客戶端的時候，會在實體首部加上「ETag: 惟一標識符」一塊兒返回給客戶端。例如：

Etag: "5d8c72a5edda8d6a:3239"

客戶端會保留該 ETag 字段，並在下一次請求時將其一併帶過去給服務器。服務器只須要比較客戶端傳來的ETag跟本身服務器上該資源的ETag是否一致，就能很好地判斷資源相對客戶端而言是否被修改過了。

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

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

那麼客戶端是如何把標記在資源上的 ETag 傳回給服務器的呢？請求報文中有兩個首部字段能夠帶上 ETag 值：

If-None-Match: ETag-value

示例爲 If-None-Match: "5d8c72a5edda8d6a:3239"

• 告訴服務端若是 ETag 沒匹配上須要重發資源數據

• 不然直接回送304和響應報頭便可。 當前各瀏覽器均是使用的該請求首部來向服務器傳遞保存的 ETag 值。

If-Match: ETag-value

• 告訴服務器若是沒有匹配到ETag，或者收到了「*」值而當前並無該資源實體，則應當返回412(Precondition Failed) 狀態碼給客戶端。

• 不然服務器直接忽略該字段。

須要注意的是，若是資源是走分佈式服務器（好比CDN）存儲的狀況，須要這些服務器上計算ETag惟一值的算法保持一致，纔不會致使明明同一個文件，在服務器A和服務器B上生成的ETag卻不同。

緩存頭部對比

幾種字段的對比：

頭部	優點和特色	劣勢和問題
Expires	一、HTTP 1.0 產物，能夠在HTTP 1.0和1.1中使用，簡單易用。二、以時刻標識失效時間。	一、時間是由服務器發送的(UTC)，若是服務器時間和客戶端時間存在不一致，可能會出現問題。二、存在版本問題，到期以前的修改客戶端是不可知的。
Cache-Control	一、HTTP 1.1 產物，以時間間隔標識失效時間，解決了Expires服務器和客戶端相對時間的問題。二、比Expires多了不少選項設置。	一、HTTP 1.1 纔有的內容，不適用於HTTP 1.0 。二、存在版本問題，到期以前的修改客戶端是不可知的。
Last-Modified	一、不存在版本問題，每次請求都會去服務器進行校驗。服務器對比最後修改時間若是相同則返回304，不一樣返回200以及資源內容。	一、只要資源修改，不管內容是否發生實質性的變化，都會將該資源返回客戶端。例如週期性重寫，這種狀況下該資源包含的數據實際上同樣的。二、以時刻做爲標識，沒法識別一秒內進行屢次修改的狀況。三、某些服務器不能精確的獲得文件的最後修改時間。
ETag	一、能夠更加精確的判斷資源是否被修改，能夠識別一秒內屢次修改的狀況。二、不存在版本問題，每次請求都回去服務器進行校驗。	一、計算ETag值須要性能損耗。二、分佈式服務器存儲的狀況下，計算ETag的算法若是不同，會致使瀏覽器從一臺服務器上得到頁面內容後到另一臺服務器上進行驗證時發現ETag不匹配的狀況。

用戶刷新/訪問行爲

咱們能夠把刷新/訪問界面的手段分紅三類,在瀏覽器中，有時候你會發現經過不一樣的手段訪問/刷新界面頁面的呈現速度是不同的，那麼它們到底有什麼區別呢?

在URI輸入欄中輸入而後回車/經過書籤訪問

返回響應碼是 200 OK (from cache)，瀏覽器發現該資源已經緩存了並且沒有過時（經過Expires頭部或者Cache-Control頭部），沒有跟服務器確認，而是直接使用了瀏覽器緩存的內容。其中響應內容和以前的響應內容如出一轍，例如其中的Date時間是上一次響應的時間。

F5/點擊工具欄中的刷新按鈕/右鍵菜單從新加載

F5的做用和直接在URI輸入欄中輸入而後回車是不同的，F5會讓瀏覽器不管如何都發一個HTTP Request給Server，即便先前的響應中有Expires頭部。因此，當我在當前 騰訊課堂 網頁中按F5的時候，瀏覽器會發送一個HTTP Request給Server，可是包含這樣的Headers:

Cache-Control: max-age=0
If-Modified-Since: Fri, 15 Jul 2016 04:11:51 GMT

其中Cache-Control是Chrome強制加上的，而If-Modified-Since是由於獲取該資源的時候包含了Last-Modified頭部，瀏覽器會使用If-Modified-Since頭部信息從新發送該時間以確認資源是否須要從新發送。 實際上Server沒有修改這個index.css文件，因此返回了一個304(Not Modified)，這樣的響應信息很小，所消耗的route-trip很少，網頁很快就刷新了。

上面的例子中沒有ETag，若是Response中包含ETag，F5引起的Http Request中也是會包含If-None-Match的。

Ctl+F5

Ctrl+F5要的是完全的從Server拿一份新的資源過來，因此不光要發送HTTP request給Server，並且這個請求裏面連If-Modified-Since/If-None-Match都沒有，這樣就逼着Server不能返回304，而是把整個資源原本來本地返回一份，這樣，Ctrl+F5引起的傳輸時間變長了，天然網頁Refresh的也慢一些。咱們能夠看到該操做返回了200，並刷新了相關的緩存控制時間。

實際上，爲了保證拿到的是從Server上最新的，Ctrl+F5不只是去掉了If-Modified-Since/If-None-Match，還須要添加一些HTTP Headers。

按照HTTP/1.1協議，Cache不光只是存在Browser終端，從Browser到Server之間的中間節點(好比Proxy)也可能扮演Cache的做用，爲了防止得到的只是這些中間節點的Cache，須要告訴他們，別用本身的Cache敷衍我，往Upstream的節點要一個最新的copy吧。

在Chrome 51 中會包含兩個頭部信息， 做用就是讓中間的Cache對這個請求失效，這樣返回的絕對是新鮮的資源。

Cache-Control: no-cache
Pragma: no-cache

緩存實踐

綜上對各類HTTP緩存控制頭部的對比以及用戶可能出現的瀏覽器刷新行爲的討論，當咱們在一個項目上作http緩存的應用時，咱們實際上仍是會把上述說起的大多數首部字段均使用上。

Expires / Cache-Control

Expires用時刻來標識失效時間，難免收到時間同步的影響，而Cache-Control使用時間間隔很好的解決了這個問題。 可是 Cache-Control 是 HTTP1.1 纔有的，不適用於 HTTP1.0，而 Expires 既適用於 HTTP1.0，也適用於 HTTP1.1，因此說在大多數狀況下同時發送這兩個頭會是一個更好的選擇，當客戶端兩種頭都能解析的時候，會優先使用 Cache-Control。

Last-Modified / ETag

兩者都是經過某個標識值來請求資源， 若是服務器端的資源沒有變化，則自動返回 HTTP 304 （Not Changed）狀態碼，內容爲空，這樣就節省了傳輸數據量。而當資源發生比那話後，返回和第一次請求時相似。從而保證不向客戶端重複發出資源，也保證當服務器有變化時，客戶端可以獲得最新的資源。

其中Last-Modified使用文件最後修改做爲文件標識值，它沒法處理文件一秒內屢次修改的狀況，並且只要文件修改了哪怕文件實質內容沒有修改，也會從新返回資源內容；ETag做爲「被請求變量的實體值」，其徹底能夠解決Last-Modified頭部的問題，可是其計算過程須要耗費服務器資源。

from-cache / 304

Expires和Cache-Control都有一個問題就是服務端做爲的修改，若是還在緩存時效裏，那麼客戶端是不會去請求服務端資源的（非刷新），這就存在一個資源版本不符的問題，而強制刷新必定會發起HTTP請求並返回資源內容，不管該內容在這段時間內是否修改過；而Last-Modified和Etag每次請求資源都會發起請求，哪怕是好久都不會有修改的資源，都至少有一次請求響應的消耗。

對於全部可緩存資源，指定一個Expires或Cache-Control max-age以及一個Last-Modified或ETag相當重要。同時使用前者和後者能夠很好的相互適應。

前者不須要每次都發起一次請求來校驗資源時效性，後者保證當資源未出現修改的時候不須要從新發送該資源。而在用戶的不一樣刷新頁面行爲中，兩者的結合也能很好的利用HTTP緩存控制特性，不管是在地址欄輸入URI而後輸入回車進行訪問，仍是點擊刷新按鈕，瀏覽器都能充分利用緩存內容，避免進行沒必要要的請求與數據傳輸。

避免304

同窗們是否還記得咱們在討論用戶刷新頁面行爲中體積的index.css文件，它實際上被命名爲index.03d344bd.css。而細心的同窗也會發現它的Expires和Cache-Control時間出奇的長，這難道不會致使用戶沒法獲得其最近的內容嗎？

其作法實際上很簡單，它把服務側ETag的那一套理論搬到了前端來使用。 頁面的靜態資源以版本形式發佈，經常使用的方法是在文件名或參數帶上一串md5或時間標記符：

https://hm.baidu.com/hm.js?e23800c454aa573c0ccb16b52665ac26
http://tb1.bdstatic.com/tb/_/tbean_safe_ajax_94e7ca2.js
http://img1.gtimg.com/ninja/2/2016/04/ninja145972803357449.jpg

能夠看到上面的例子中有不一樣的作法，有的在URI後面加上了md5參數，有的將md5值做爲文件名的一部分，有的將資源放在特性版本的目錄中。

那麼在文件沒有變更的時候，瀏覽器不用發起請求直接可使用緩存文件；而在文件有變化的時候，因爲文件版本號的變動，致使文件名變化，請求的url變了，天然文件就更新了。這樣能確保客戶端能及時從服務器收取到新修改的文件。經過這樣的處理，增加了靜態資源，特別是圖片資源的緩存時間，避免該資源很快過時，客戶端頻繁向服務端發起資源請求，服務器再返回304響應的狀況（有Last-Modified/Etag）。

Tips

• 須要兼容HTTP1.0的時候須要使用Expires，否則能夠考慮直接使用Cache-Control

• 須要處理一秒內屢次修改的狀況，或者其餘Last-Modified處理不了的狀況，才使用ETag，不然使用Last-Modified。

• 對於全部可緩存資源，須要指定一個Expires或Cache-Control，同時指定Last-Modified或者Etag。

• 能夠經過標識文件版本名、加長緩存時間的方式來減小304響應。

總結

參考

• HTTP緩存小結

• HTTP/1.1: Caching in HTTP