淺談HTTP緩存

1、HTTP緩存概述（HTTP Cache）

要搞清楚HTTP緩存，首先固然是要搞清楚緩存是啥，按照MDN的描述，緩存是這樣的：

緩存是一種保存資源副本並在下次請求時直接使用該副本的技術。當 web 緩存發現請求的資源已經被存儲，它會攔截請求，返回該資源的拷貝，而不會去源服務器從新下載。這樣帶來的好處有：緩解服務器端壓力，提高性能(獲取資源的耗時更短了)。對於網站來講，緩存是達到高性能的重要組成部分。緩存須要合理配置，由於並非全部資源都是永久不變的：重要的是對一個資源的緩存應截止到其下一次發生改變（即不能緩存過時的資源）。

上面已經將會緩存是什麼描述的很清楚了，而HTTP緩存顧名思義，就是經過HTTP協議，來實現對資源緩存的目的。總的來講，HTTP緩存主要經過兩個HTTP頭來實現的，其中Expires是由HTTP1.0提供的，而Cache-Control則是由HTTP1.1所提供的：

下面咱們就來對這兩個頭進行一個瞭解。

2、Expires

Expires是由HTTP1.0所提供的支持HTTP緩存的頭部，由服務器返回，用GMT格式的字符串表示：

expires: Tue, 14 Aug 2018 14:32:49 GMT
複製代碼

而讀取緩存的條件則是：緩存過時時間（服務器的時間）< 當前時間（客戶端的時間）

值得注意的是，咱們在expires所設置的時間是一個絕對的時間，並且所參照的是用戶電腦上所設置的時間。這種絕對的時間很容易出問題，當用戶本地的時間不許確，或用戶進行跨時區的移動時，這個時間極可能就會過時，而沒法發揮它本應該發揮的做用。

其次，在HTTP1.0裏，沒有提供相應的配置緩存的方法，只是提供了這個強緩存的頭部而已，不足以知足項目對緩存多樣化的需求。也正是出於以上兩個緣由，在HTTP1.1中對HTTP緩存又進行了升級。

3、 Cache-Control

正是因爲Expires存在着不少不足，因此HTTP1.1又爲咱們提供了

Cache-Control主要可配置的參數有如下幾個：

1. max-age 會指定從請求的時間開始，容許獲取的響應被重用的最長時間（單位：秒）。例如，「max-age=60」表示可在接下來的 60 秒緩存和重用響應。
2. Public 表示響應可被任何緩存區緩存
3. Private 表示對於單個用戶的整個或部分響應消息，不能被共享緩存處理。這些響應一般只爲單個用戶緩存，所以不容許任何中間緩存對其進行緩存。例如，用戶的瀏覽器能夠緩存包含用戶私人信息的 HTML 網頁，但 CDN 卻不能緩存。
4. no-cache 表示必須先與服務器確認返回的響應是否發生了變化，而後才能使用該響應來知足後續對同一網址的請求。所以，若是存在合適的驗證，no-cache 會發起往返通訊來驗證緩存的響應，但若是資源未發生變化，則可避免下載。
5. no-store則要簡單得多。它直接禁止瀏覽器以及全部中間緩存存儲任何版本的返回響應，例如，包含我的隱私數據或銀行業務數據的響應。每次用戶請求該資產時，都會向服務器發送請求，並下載完整的響應。
6. min-fresh 表示客戶端能夠接收響應時間小於當前時間加上指定時間的響應。（用的很少）
7. max-stale 表示客戶端能夠接收超出超時期間的響應消息。若是指定max-stale消息的值，那麼客戶機能夠接收超出超時期指定值以內的響應消息。（用的很少）

4、強緩存

上面已經將Catch-Control作了一個簡單的介紹，而具體使用它們兩者進行緩存操做的具體實現又分爲強緩存與協商緩存。首先來聊一聊強緩存。

強緩存是利用Expires或者Cache-Control這兩個http response header實現的，它們都用來表示資源在客戶端緩存的有效期。在這個有效期內當瀏覽器對某個資源的請求命中了強緩存時，其返回的http狀態爲200，而且不會去對服務器進行請求，而是直接使用其本地的緩存。

具體實現以下：

expires: Tue, 21 Aug 2018 10:17:45 GMT
cache-control: max-age=691200
複製代碼

只要存在以上兩個頭部信息的其中一個，咱們就能夠對資源進行強緩存了。另外須要注意的是，當Catch-Control的優先級是要高於expires的。

總的來講，強緩存是前端性能優化的一大助力。當咱們頁面存在不少長期不變的靜態資源時，都應該對其進行強緩存的處理，咱們一般能夠爲這些靜態資源所有配置一個超時時間很長的Expires或Cache-Control。當用戶在訪問網頁時，就只會在第一次加載時從服務器請求靜態資源，在日後訪問該頁面時，就只要緩存沒有失效而且用戶沒有強制刷新的條件下都會從本身的緩存中加載。這樣既節省了資源加載的時間的消耗，又不會去訪問服務器，能夠有效地爲服務器減壓。

不過強緩存也存在一個很大的弊端，那就是對於動態資源它就有點力不從心了。由於若是咱們對動態資源進行了強緩存，那麼極可能會在這動態資源更改後，瀏覽器仍是會直接去請求沒有更改前的動態資源。也這是因爲這方面的考慮，在強緩存外還存在着協商緩存的緩存方案。

5、協商緩存

當瀏覽器對某個資源的請求沒有命中強緩存，就會發一個請求到服務器，驗證協商緩存是否命中，若是協商緩存命中，請求響應返回的http狀態爲304而且會顯示一個Not Modified的字符串； 若未命中請求，則將資源返回客戶端，並更新本地緩存數據，並返回200的狀態碼。

除此以外，咱們也能夠設置爲協商緩存，以解決動態資源緩存與更新的問題，首先咱們來看一張關於協商緩存的圖：

能夠看到，在這個實現了協商緩存的Cache-Control中，設置了no-catch，當咱們設置爲no-catch時，咱們就是能夠直接去訪問服務器，去查看該資源的更改狀況，已肯定是是否須要使用緩存。而在校驗的這一步咱們就須要使用如下幾個頭來幫助驗證資源的更改狀況了：

• Last-Modified：表示這個響應資源的最後修改時間。web服務器在響應請求時，會告訴瀏覽器該資源的最後修改時間，但它的最小單位是秒級，也就是若是咱們在1秒內屢次修改該資源，那麼Last-Modified也沒法發揮其應有的做用。
• If-Modified-Since：當資源過時時（強緩存失效），發現資源具備Last-Modified聲明，則再次向web服務器請求時帶上頭 If-Modified-Since，表示請求時間。web服務器收到請求後發現有頭If-Modified-Since 則與被請求資源的最後修改時間進行比對。若最後修改時間較新，說明資源又被改動過，則響應整片資源內容（寫在響應消息包體內），HTTP 200；若最後修改時間較舊，說明資源無新修改，則響應HTTP 304 (無需包體，節省瀏覽)，告知瀏覽器繼續使用所保存的cache。

也正是因爲 Last-Modified存在着缺陷，咱們就須要ETag來幫助咱們來對資源的更改進行判斷：

• Etag：當Web服務器響應請求時，會告訴瀏覽器當前資源在服務器的惟一標識（生成規則是由服務器決定的）。就好比在Apache中，ETag的值，其默認是對文件的索引節（INode），大小（Size）和最後修改時間（MTime）進行Hash後獲得的。
• If-None-Match：當資源過時時，若是發現資源具備Etage聲明，則再次向web服務器請求時帶上頭If-None-Match （Etag的值）。Web服務器收到請求後發現有頭If-None-Match， 就會將其被請求的資源的相應校驗字段進行對比，而後再決定返回200或304。

這就是強緩存與協商緩存的大部分狀況了，具體的流程可見下圖：

原圖連接：user-gold-cdn.xitu.io/2018/8/16/1…

6、定義最佳 Cache-Control 策略

一般咱們能夠按照上面這張流程圖來對HTTP緩存進行相應的配置，詳情能夠看這篇文章：

developers.google.com/web/fundame…?

這位大佬對緩存的配置作了一個很好的闡述。

參考資料：

• developers.google.com/web/fundame…?
• www.cnblogs.com/lyzg/p/5125…
• developer.mozilla.org/zh-CN/docs/…