HTTP 緩存的四種風味與緩存策略

本文從屬於筆者的HTTP 理解與實踐系列文章，對於HTTP的學習主要包含HTTP 基礎、HTTP 請求頭與請求體、HTTP 響應頭與狀態碼、HTTP 緩存這四個部分，而對於HTTP相關的擴展與引伸，咱們還須要瞭解HTTPS 理解與實踐 、HTTP/2 基礎、WebSocket 基礎這些部分。本部分知識點同時也概括於筆者的個人校招準備之路:從Web前端到服務端應用架構這篇綜述。

HTTP Cache

經過網絡獲取內容既緩慢，成本又高：大的響應須要在客戶端和服務器之間進行屢次往返通訊，這拖延了瀏覽器可使用和處理內容的時間，同時也增長了訪問者的數據成本。所以，緩存和重用之前獲取的資源的能力成爲優化性能很關鍵的一個方面。每一個瀏覽器都實現了 HTTP 緩存！ 咱們所要作的就是，確保每一個服務器響應都提供正確的 HTTP 頭指令，以指導瀏覽器什麼時候能夠緩存響應以及能夠緩存多久。服務器在返回響應時，還會發出一組 HTTP 頭，用來描述內容類型、長度、緩存指令、驗證令牌等。例如，在下圖的交互中，服務器返回了一個 1024 字節的響應，指導客戶端緩存響應長達 120 秒，並提供驗證令牌（x234dff），在響應過時以後，能夠用來驗證資源是否被修改。

咱們打開百度首頁，能夠看下百度的HTTP緩存的實現：

發現對於靜態資源的訪問都是返回的200狀態碼。

頭部	優點和特色	劣勢和問題
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不匹配的狀況。

Header

HTTP報文頭部中與緩存相關的字段爲：

1. 通用首部字段（就是請求報文和響應報文都能用上的字段）

2. 請求首部字段

3. 響應首部字段

4. 實體首部字段

Reference

• HTTP緩存

• 淺談瀏覽器http的緩存機制

• HTTP緩存控制小結

HTTP 1.0: 基於Pragma&Expires的緩存實現

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

Pragma

當該字段值爲「no-cache」的時候（事實上如今RFC中也僅標明該可選值），會知會客戶端不要對該資源讀緩存，即每次都得向服務器發一次請求才行。Pragma屬於通用首部字段，在客戶端上使用時，常規要求咱們往html上加上這段meta元標籤（僅對該頁面有效，對頁面上的資源無效）：

<meta http-equiv="Pragma" content="no-cache">

它告訴瀏覽器每次請求頁面時都不要讀緩存，都得往服務器發一次請求才行。不過這種限制行爲在客戶端做用有限：

1. 僅有IE才能識別這段meta標籤含義，其它主流瀏覽器僅能識別「Cache-Control: no-store」的meta標籤。

2. 在IE中識別到該meta標籤含義，並不必定會在請求字段加上Pragma，但的確會讓當前頁面每次都發新請求（僅限頁面，頁面上的資源則不受影響）。

另外，須要知道的是，Pragma的優先級是高於Cache-Control 的。譬如在下圖這個例子中，咱們使用Fiddler爲圖片資源額外增長如下頭部信息:

前者用來設定緩存資源一天，後者禁用緩存，從新訪問該頁面會發現訪問該資源會從新發起一次請求。

Expire

有了Pragma來禁用緩存，天然也須要有個東西來啓用緩存和定義緩存時間，對http1.0而言，Expires就是作這件事的首部字段。Expires的值對應一個GMT（格林尼治時間），好比「Mon, 22 Jul 2002 11:12:01 GMT」來告訴瀏覽器資源緩存過時時間，若是還沒過該時間點則不發請求。在客戶端咱們一樣可使用meta標籤來知會IE（也僅有IE能識別）頁面（一樣也只對頁面有效，對頁面上的資源無效）緩存時間：

<meta http-equiv="expires" content="mon, 18 apr 2016 14:30:00 GMT">

若是但願在IE下頁面不走緩存，但願每次刷新頁面都能發新請求，那麼能夠把「content」裏的值寫爲「-1」或「0」。注意的是該方式僅僅做爲知會IE緩存時間的標記，你並不能在請求或響應報文中找到Expires字段。若是是在服務端報頭返回Expires字段，則在任何瀏覽器中都能正確設置資源緩存的時間。

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

HTTP 1.1 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 一塊兒搭配使用。組合的形式還能作一些瀏覽器行爲不一致的兼容處理。例如在IE咱們可使用 no-cache 來防止點擊「後退」按鈕時頁面資源從緩存加載，但在 Firefox 中，須要使用 no-store 才能防止歷史回退時瀏覽器不從緩存中去讀取數據，故咱們在響應報頭加上以下組合值便可作兼容處理：

Cache-Control: no-cache, no-store

HTTP 1.1 緩存校驗

上述的首部字段均能讓客戶端決定是否向服務器發送請求，好比設置的緩存時間未過時，那麼天然直接從本地緩存取數據便可（在chrome下表現爲200 from cache），若緩存時間過時了或資源不應直接走緩存，則會發請求到服務器去。咱們如今要說的問題是，若是客戶端向服務器發了請求，那麼是否意味着必定要讀取回該資源的整個實體內容呢？咱們試着這麼想——客戶端上某個資源保存的緩存時間過時了，但這時候其實服務器並無更新過這個資源，若是這個資源數據量很大，客戶端要求服務器再把這個東西從新發一遍過來，是否很是浪費帶寬和時間呢？答案是確定的，那麼是否有辦法讓服務器知道客戶端如今存有的緩存文件，其實跟本身全部的文件是一致的，而後直接告訴客戶端說「這東西你直接用緩存裏的就能夠了，我這邊沒更新過呢，就再也不傳一次過去了」。爲了讓客戶端與服務器之間能實現緩存文件是否更新的驗證、提高緩存的複用率，Http1.1新增了幾個首部字段來作這件事情。

Last-Modified:根據最後修改時間匹配

服務器將資源傳遞給客戶端時，會將資源最後更改的時間以「Last-Modified: GMT」的形式加在實體首部上一塊兒返回給客戶端。客戶端會爲資源標記上該信息，下次再次請求時，會把該信息附帶在請求報文中一併帶給服務器去作檢查，若傳遞的時間值與服務器上該資源最終修改時間是一致的，則說明該資源沒有被修改過，直接返回304狀態碼便可。至於傳遞標記起來的最終修改時間的請求報文首部字段一共有兩個：

1. If-Modified-Since: Last-Modified-value

示例爲  If-Modified-Since: Thu, 31 Mar 2016 07:07:52 GMT

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

2. If-Unmodified-Since: Last-Modified-value

告訴服務器，若Last-Modified沒有匹配上（資源在服務端的最後更新時間改變了），則應當返回412(Precondition Failed) 狀態碼給客戶端。

當遇到下面狀況時，If-Unmodified-Since 字段會被忽略：

1. Last-Modified值對上了（資源在服務端沒有新的修改）；
2. 服務端需返回2XX和412以外的狀態碼；
3. 傳來的指定日期不合法

Last-Modified 說好卻也不是特別好，由於若是在服務器上，一個資源被修改了，但其實際內容根本沒發送改變，會由於Last-Modified時間匹配不上而返回了整個實體給客戶端（即便客戶端緩存裏有個如出一轍的資源）。

ETag:根據資源標識符匹配

爲了解決上述Last-Modified可能存在的不許確的問題，Http1.1還推出了 ETag 實體首部字段。服務器會經過某種算法，給資源計算得出一個惟一標誌符（好比md5標誌），在把資源響應給客戶端的時候，會在實體首部加上「ETag: 惟一標識符」一塊兒返回給客戶端。客戶端會保留該 ETag 字段，並在下一次請求時將其一併帶過去給服務器。服務器只須要比較客戶端傳來的ETag跟本身服務器上該資源的ETag是否一致，就能很好地判斷資源相對客戶端而言是否被修改過了。若是服務器發現ETag匹配不上，那麼直接以常規GET 200回包形式將新的資源（固然也包括了新的ETag）發給客戶端；若是ETag是一致的，則直接返回304知會客戶端直接使用本地緩存便可。

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

1. If-None-Match: ETag-value

示例爲  If-None-Match: "56fcccc8-1699"

告訴服務端若是 ETag 沒匹配上須要重發資源數據，不然直接回送304和響應報頭便可。當前各瀏覽器均是使用的該請求首部來向服務器傳遞保存的 ETag 值。

2. If-Match: ETag-value

告訴服務器若是沒有匹配到ETag，或者收到了「*」值而當前並無該資源實體，則應當返回412(Precondition Failed) 狀態碼給客戶端。不然服務器直接忽略該字段。If-Match 的一個應用場景是，客戶端走PUT方法向服務端請求上傳/更替資源，這時候能夠經過 If-Match 傳遞資源的ETag。

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

若是 Last-Modified 和 ETag 同時被使用，則要求它們的驗證都必須經過纔會返回304，若其中某個驗證沒經過，則服務器會按常規返回資源實體及200狀態碼。

在較新的 nginx 上默認是同時開啓了這兩個功能的：

上圖的前三條請求是原始請求，接着的三條請求是刷新頁面後的新請求，在發新請求以前咱們修改了 reset.css 文件，因此它的 Last-Modified 和 ETag 均發生了改變，服務器所以返回了新的文件給客戶端（狀態值爲200）。

而 dog.jpg 咱們沒有作修改，其Last-Modified 和 ETag在服務端是保持不變的，故服務器直接返回了304狀態碼讓客戶端直接使用緩存的 dog.jpg 便可，沒有把實體內容返回給客戶端（由於不必）。

緩存策略

按照上面的決策樹來肯定您的應用使用的特定資源或一組資源的最優緩存策略。理想狀況下，目標應該是在客戶端上緩存儘量多的響應、緩存儘量長的時間，而且爲每一個響應提供驗證令牌，以便進行高效的從新驗證。

Cache-Control 指令	說明
max-age=86400	瀏覽器和任何中繼緩存都可以將響應（若是是public的）緩存長達一天（60 秒 x 60 分 x 24 小時）
private, max-age=600	客戶端瀏覽器只能將響應緩存最長 10 分鐘（60 秒 x 10 分）
no-store	不容許緩存響應，每一個請求必須獲取完整的響應。

根據 HTTP Archive，在排名最高的 300,000 個網站中（Alexa 排名），全部下載的響應中，幾乎有半數能夠由瀏覽器進行緩存，對於重複性網頁瀏覽和訪問來講，這是一個巨大的節省！ 固然，這並不意味着特定的應用會有 50% 的資源能夠被緩存：有些網站能夠緩存 90% 以上的資源， 而有些網站有許多私密的或者時間要求苛刻的數據，根本沒法被緩存。
當咱們在一個項目上作http緩存的應用時，咱們仍是會把上述說起的大多數首部字段均使用上，例如使用 Expires 來兼容舊的瀏覽器，使用 Cache-Control 來更精準地利用緩存，而後開啓 ETag 跟 Last-Modified 功能進一步複用緩存減小流量。

那麼這裏會有一個小問題——Expires 和 Cache-Control 的值應設置爲多少合適呢？

答案是不會有過於精準的值，均須要進行按需評估。

例如頁面連接的請求常規是無須作長時間緩存的，從而保證回退到頁面時能從新發出請求，百度首頁是用的 Cache-Control:private，騰訊首頁則是設定了60秒的緩存，即 Cache-Control:max-age=60。

而靜態資源部分，特別是圖片資源，一般會設定一個較長的緩存時間，並且這個時間最好是能夠在客戶端靈活修改的。以騰訊的某張圖片爲例：

http://i.gtimg.cn/vipstyle/vipportal/v4/img/common/logo.png?max_age=2592000

客戶端能夠經過給圖片加上「max_age」的參數來定義服務器返回的緩存時間：

廢棄和更新已緩存的響應

瀏覽器發出的全部 HTTP 請求會首先被路由到瀏覽器的緩存，以查看是否緩存了能夠用於實現請求的有效響應。若是有匹配的響應，會直接從緩存中讀取響應，這樣就避免了網絡延遲以及傳輸產生的數據成本。然而，若是咱們但願更新或廢棄已緩存的響應，該怎麼辦？

例如，假設咱們已經告訴訪問者某個 CSS 樣式表緩存長達 24 小時 (max-age=86400)，可是設計人員剛剛提交了一個更新，咱們但願全部用戶都能使用。咱們該如何通知全部訪問者緩存的 CSS 副本已過期，須要更新緩存？ 這是一個欺騙性的問題 - 實際上，至少在不更改資源網址的狀況下，咱們作不到。

一旦瀏覽器緩存了響應，在過時之前，將一直使用緩存的版本，這是由 max-age 或者 expires 指定的，或者直到由於某些緣由從緩存中刪除，例如用戶清除了瀏覽器緩存。所以，在構建網頁時，不一樣的用戶可能使用的是文件的不一樣版本；剛獲取該資源的用戶將使用新版本，而緩存過以前副本（可是依然有效）的用戶將繼續使用舊版本的響應。

因此，咱們如何才能魚和熊掌兼得：客戶端緩存和快速更新？ 很簡單，在資源內容更改時，咱們能夠更改資源的網址，強制用戶下載新響應。一般狀況下，能夠經過在文件名中嵌入文件的指紋碼（或版本號）來實現 - 例如 style.x234dff.css。

固然這須要有一個前提——靜態資源能確保長時間不作改動。若是一個腳本文件響應給客戶端並作了長時間的緩存，而服務端在近期修改了該文件的話，緩存了此腳本的客戶端將沒法及時得到新的數據。

解決該困擾的辦法也簡單——把服務側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

若是文件被修改了，才更改其標記符內容，這樣能確保客戶端能及時從服務器收取到新修改的文件。

由於可以定義每一個資源的緩存策略，因此，咱們能夠定義’緩存層級’，這樣，不但能夠控制每一個響應的緩存時間，還能夠控制訪問者看到新版本的速度。例如，咱們一塊兒分析一下上面的例子：

• HTML 被標記成no-cache，這意味着瀏覽器在每次請求時都會從新驗證文檔，若是內容更改，會獲取最新版本。同時，在 HTML 標記中，咱們在 CSS 和 JavaScript 資源的網址中嵌入指紋碼：若是這些文件的內容更改，網頁的 HTML 也會隨之更改，並將下載 HTML 響應的新副本。

• 容許瀏覽器和中繼緩存（例如 CDN）緩存 CSS，過時時間設置爲 1 年。注意，咱們能夠放心地使用 1 年的’遠期過時’，由於咱們在文件名中嵌入了文件指紋碼：若是 CSS 更新，網址也會隨之更改。

• JavaScript 過時時間也設置爲 1 年，可是被標記爲 private，也許是由於包含了 CDN 不該緩存的一些用戶私人數據。

• 緩存圖片時不包含版本或惟一指紋碼，過時時間設置爲 1 天。

緩存檢查表

不存在最佳的緩存策略。根據您的通訊模式、提供的數據類型以及應用特定的數據更新要求，必須定義和配置每一個資源最適合的設置以及總體的’緩存層級’。

在定義緩存策略時，要記住下列技巧和方法：

1. 使用一致的網址：若是您在不一樣的網址上提供相同的內容，將會屢次獲取和存儲該內容。提示：注意，網址區分大小寫！

2. 確保服務器提供驗證令牌 (ETag)：經過驗證令牌，若是服務器上的資源未被更改，就沒必要傳輸相同的字節。

3. 肯定中繼緩存能夠緩存哪些資源：對全部用戶的響應徹底相同的資源很適合由 CDN 或其餘中繼緩存進行緩存。

4. 肯定每一個資源的最優緩存週期：不一樣的資源可能有不一樣的更新要求。審查並肯定每一個資源適合的 max-age。

5. 肯定網站的最佳緩存層級：對 HTML 文檔組合使用包含內容指紋碼的資源網址以及短期或 no-cache 的生命週期，能夠控制客戶端獲取更新的速度。

6. 攪動最小化：有些資源的更新比其餘資源頻繁。若是資源的特定部分（例如 JavaScript 函數或一組 CSS 樣式）會常常更新，應考慮將其代碼做爲單獨的文件提供。這樣，每次獲取更新時，剩餘內容（例如不會頻繁更新的庫代碼）能夠從緩存中獲取，確保下載的內容量最少。