10 分鐘快速入門：HTTP緩存

場景1：

每次你打開 XXXXHub，準備麒麟臂，滿心歡喜的等待一張圖片加載回來。圖片終於不負衆望加載回來了，可這竟然是昨天看過的那張！這簡直大煞風景！誰能忍！

場景2：

有些時候，辦公室裏會傳來產品大人的尖叫：「怎麼網頁仍是原來的樣子？」 而後你會聽到前端 GGMM 們不屑的回答：「我都說了，有緩存」。 嗯，對的，網頁沒有改變，這是 HTTP 緩存在起做用。由於瀏覽器在使用一樣的資源渲染網頁。

HTTP 緩存讓前端 GG 們又愛又恨。 雖然 HTTP 緩存在某些瞬間給前端 GGMM 們帶來了極大的痛苦（找不到 BUG），但很大程度上，緩存也加速了人們鍛鍊麒麟臂的機會。

合理利用好 HTTP 緩存，我能就能給每一位網頁瀏覽者 +1s。 下面咱們一塊兒來了解一下 HTTP 緩存，揭開他神祕的面紗。

什麼是 HTTP 緩存？

HTTP緩存（或Web緩存）是用於臨時存儲（緩存）Web文檔（如HTML頁面和圖像），以減小服務器延遲的一種信息技術。HTTP緩存系統會保存下經過這套系統的文檔的副本；若是知足某些條件，則能夠由緩存知足後續請求。HTTP緩存系統既能夠指設備，也能夠指計算機程序。

簡單來講，就是在打開網頁的時候，將網頁中可能重複加載的資源，按照必定的規則保存到本地，以便第二次打開一樣的網站時，能夠重複利用已有資源。

一個良好的緩存策略，能夠：

1. 下降資源的重複加載
2. 提升網頁的總體加載速度
3. 節省用戶流量
4. 給前端 GG 帶來痛苦（大霧

2 種緩存機制

通常來講，會有兩種緩存機制，分別是：協商緩存和強緩存。

假設資源 A 已經躺在了本地某個不知名角落裏。 如今，咱們要再拿一次資源 A。

強緩存——瀏覽器說了算

表現形式：

200 OK (from memory cache)
200 OK (from disk)
複製代碼

瀏覽器發現本地資源 A 後，瀏覽器根據以前服務器說下的驗身規則，給本地資源 A 驗明正身。

✅ 若是符合要求，瀏覽器會直接返回這個本地資源！ ❌ 若是不符合要求，瀏覽器會想服務端發一個資源請求。

協商緩存——服務器說了算

命中後的表現形式：

304 Not Modified
複製代碼

瀏覽器發現本地資源 A 後，瀏覽器給服務器發了一個請求，將資源 A 相關的信息告訴服務器，問問服務器本地的資源 A 還能不能用。

✅ 若是服務器說還能用（返回 304），瀏覽器會直接返回本地資源 A。 ❌ 若是不符合要求，服務器會直接返回一份完整的資源 A。

4 種緩存策略

若是服務器在頭部中配置了緩存策略，那麼瀏覽器就會自動執行對應的邏輯了。

Expires

Expires: Wed, 11 May 2018 07:20:00 GMT
複製代碼

這是來自 HTTP 1.0 的頭部內容。 他表示的是資源過時時間。在用戶對已緩存資源發起第二次請求的時候，瀏覽器會將 Expires 對應的時間和本地時間比對。

P.S.：請求頭部帶上 Pragma: no-cache 會讓 Expires 失效。

✅ 沿用舊資源，返回 200 OK (from cache) ❌ 向服務端發起請求，要一個新資源

Cache-Control

Cache-Control: public, max-age=604800
複製代碼

來自 HTTP 1.1，是一個被普遍使用的頭部字段。 能夠被用在請求頭部、響應頭部。

no-store

Cache-Control: no-store
複製代碼

禁止使用緩存。不容許將文件緩存到本地。

no-cache

Cache-Control: no-cache
複製代碼

必須先與代理服務器確認是否更改，而後再決定使用緩存仍是請求，相似於協商緩存（304）

public

Cache-Control: public
複製代碼

能夠被全部用戶緩存（多用戶共享），包括終端和CDN等中間代理服務器 通常搭配其餘 cache-control 配置一同使用。

private

Cache-Control: private
複製代碼

與 public 屬性相反，private 意味着： 資源只能被終端瀏覽器緩存（並且是私有緩存），不容許中繼緩存服務器進行緩存。 通常搭配其餘 cache-control 配置一同使用。

max-age

Cache-Control: max-age=31536000
複製代碼

告訴瀏覽器資源多久以內有效。在這個有效期以內，瀏覽器會直接返回已經存在本地的資源。 是一個經典的緩存過時機制。

s-maxage

Cache-Control: max-age=3600
複製代碼

覆蓋max-age 或者 Expires 頭，可是僅適用於共享緩存(好比各個代理)，而且私有緩存中它被忽略。

must-revalidate

Cache-Control: must-revalidate
複製代碼

revalidate = 使從新生效；使從新有法律效力。 意味着緩存在考慮使用一個陳舊的資源時，必須先驗證它的狀態，已過時的緩存將不被使用。

ETag && If-None-Match

緩存的強校驗器（看文件內容）

ETag

ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"
ETag: W/"0815"
複製代碼

來自響應頭部。 咱們能夠把 ETag 理解爲資源文件的指紋。 資源變化都會致使 ETag 變化，跟最後修改時間沒有關係，ETag 能夠保證每個資源是惟一的。 沒有明確指定生成ETag值的方法。 一般，使用內容的散列，最後修改時間戳的哈希值，或簡單地使用版本號。 例如，MDN使用wiki內容的十六進制數字的哈希值。

If-None-Match

If-None-Match: "33a64df551425fcc55e4d42a148795d9f25f89d4"
複製代碼

在請求資源的時候，瀏覽器會將它放在放在請求頭部。 通常來講，它的值，其實就是下載資源時響應頭部下發的 ETag。

Last-Modified && If-Modified-Since

一個緩存的弱校驗器（精確度比 ETag 要低）。

Last-Modified

Last-Modified: Wed, 21 Oct 2015 07:28:00 GMT
複製代碼

一個響應頭部。 包含源頭服務器認定的資源作出修改的日期及時間。 瀏覽器會將 Last-Modified 與資源綁定在一塊兒。 它一般被用做一個驗證器來判斷接收到的或者存儲的資源是否彼此一致。

If-Modified-Since

If-Modified-Since: Wed, 21 Oct 2015 07:28:00 GMT
複製代碼

一個請求頭部。通常用在 GET 請求。 其實就是下載資源時響應頭部下發的 Last-Modified。

服務器收到請求後，會比較：當前資源的修改時間和 If-Modified-Since。

✅ 當前資源修改時間 <= If-Modified-Since 意味着資源在 If-Modified-Since 這個時間點以後沒有被改動，返回 304 + 空包。

❌ 當前資源修改時間 > If-Modified-Since 意味着資源在 If-Modified-Since 這個時間點以後改動了，返回 200 + 完整資源。

主流搭配

Cache-Control: max-age + expires + last-modified

測試題

概念咱們已經看完了，又長又臭。若是這時候不來點測試題，那麼很快你又會把它忘光了。下面我爲你準備了幾道簡單的題目，目的是讓你能更好的記住緩存的相關概念，並且也知道他們是怎麼應用的。

一、若是在 request/response header 中存在：cache-control: max-age=0，會怎樣？

告訴瀏覽器，必須發請求從新驗證資源。這時候會走協商緩存機制。可能返回 200 或者 304

二、若是在 request/response header 中存在：cache-control: no-cache，會怎樣？

告訴瀏覽器，必須發請求從新驗證資源。這時候會走協商緩存機制。

三、若是在 request/response header 中存在：cache-control: must-revalidate，會怎樣？

告訴瀏覽器，必須發請求從新驗證資源。這時候會走協商緩存機制。

四、若是在 response header 中存在：Cache-Control: max-age=60, must-revalidate，會怎樣？

1. 先來看看 must-revalidate 的定義：告訴瀏覽器、緩存服務器，本地副本過時前，可使用本地副本；本地副本一旦過時，必須去源服務器進行有效性校驗。
2. 基於上面定義，能夠知道這個頭部的執行操做是：若是資源在 60s 內再次訪問，能夠直接返回強緩存；若是超過 60s，則必須發送網絡請求到服務端，去驗證資源的有效性。

五、強緩存 + 協商緩存。強緩存過時，協商緩存返回 304，這時候頭部裏會帶上強緩存的配置嗎？

看服務端是如何配置的。這個說不許。不過通常狀況下， 會返回。

六、爲何大廠都不怎麼用 etag？Yahoo的YSlow頁面分析工具爲何推薦關閉 ETag?

1. 大型網站多使用負載分擔的方式來調度HTTP請求，因此，同一個客戶端對同一個頁面的屢次請求，極可能被分配到不一樣的服務器來相應，而根據ETag的計算原理（計算參數包括inode，最後修改時間，和文件大小），不一樣的服務器，在其它全部方面都同樣的狀況下，對於同一頁面也可以計算出不一樣的ETag。所以，這時，雖然頁面沒有發生任何變化，可是服務器仍是會給出不一樣的ETag，從新發送完整的頁面內容。這並非咱們但願發生的。
2. ETag的計算佔用服務器的CPU資源。

七、cache-control:max-age + etag + last-modified + expires，判斷順序是什麼？

1. 若是expires和cache-control同時存在，cache-control會覆蓋expires。
2. 建議兩個都寫，cache-control是http1.1的頭字段，expires是http1.0的頭字 段，都寫兼容會好點。

八、s-maxage 和 max-age 同時配置，會有什麼效果？

1. max-age 給客戶端用，s-maxage 給代理服務器用
2. s-maxage 通常配置一個比 max-age 要更小一些的值，避免代理服務器直接使用 max-age，將文件緩存過久

結語

看完了這又長又臭的文章以後，相信你對 HTTP 緩存會有一個更深刻的瞭解。若是你還有什麼不懂的話，歡迎留言，我會盡我所能解答你的~~

BTW：冬至到了，廣東的盆友注意防暑降溫！