[[400059]]

本文轉載自微信公眾號「三分鐘學前端」，作者sisterAn。轉載本文請聯系三分鐘學前端公眾號。

常見的 HTTP 緩存首部字段有：

• Expires：響應頭，代表該資源的過期時間
• Cache-Control：請求/響應頭，緩存控制字段，精確控制緩存策略
• If-Modified-Since：請求頭，資源最近修改時間，由瀏覽器告訴服務器
• Last-Modified：響應頭，資源最近修改時間，由服務器告訴瀏覽器
• Etag：響應頭，資源標識，由服務器告訴瀏覽器
• If-None-Match：請求頭，緩存資源標識，由瀏覽器告訴服務器

其中， 強緩存 ：

• Expires(HTTP/1.0)
• Cache-Control(HTTP/1.1)

協商緩存：

• Last-Modified 和 If-Modified-Since(HTTP/1.0)
• ETag 和 If-None-Match(HTTP/1.1)

緩存過程分析

瀏覽器與服務器通信的方式為應答模式，即瀏覽器發起 HTTP 請求，服務器響應請求。在瀏覽器第一次發起請求時，會根據響應報文中 HTTP 頭的緩存標識，決定是否緩存結果，如果是則將請求結果和緩存標識存入瀏覽器緩存中，簡單的過程如下圖：

由上圖我們可以知道：

• 瀏覽器每次發起請求，都會先在瀏覽器緩存中查找該請求的結果以及緩存標識
• 瀏覽器每次從服務器端拿到返回的請求結果，都會將該結果和緩存標識存入瀏覽器緩存中

以上兩點結論就是瀏覽器緩存機制的關鍵，它確保了每個請求的緩存存入與讀取，只要我們再理解瀏覽器緩存的使用規則，那么所有的問題就迎刃而解了

本文也將圍繞著這點進行詳細分析。為了方便大家理解，這里我們根據是否需要向服務器重新發起HTTP請求將緩存過程分為兩個部分，分別是：

• 強緩存： 向瀏覽器緩存查找該請求結果，并根據該結果的緩存規則來決定是否使用該緩存結果的過程
• 協商緩存： 強緩存失效后，瀏覽器攜帶緩存標識向服務器發起請求，由服務器根據緩存標識決定是否使用緩存的過程

強緩存(緩存控制)

強緩存表示在緩存期間是否使用緩存(緩存是否有效)，需不需要重新發送HTTP請求

控制強緩存的字段分別是 Expires 和 Cache-Control ，其中 Cache-Control 優先級比 Expires 高

Expires(HTTP/1.0)

值為服務器返回該請求結果緩存的到期時間:

Expires: Wed, 22 Oct 2018 08:41:00 GMT 

表示資源會在 Wed, 22 Oct 2018 08:41:00 GMT 后過期，需要再次請求。

并且 Expires 受限于客戶端時間，如果修改了客戶端時間，可能會造成緩存失效。

所以現在 HTTP/1.1中新增了 Cache-Control

Cache-Control(HTTP/1.1)

Cache-control: max-age=30 

該屬性值表示資源會在 30 秒后過期，需要再次請求。也就是說在 30 秒內如果再次發起該請求，則會直接使用緩存，強緩存生效。

它與 Expires 相比：

• HTTP響應報文中 Expires 的時間值，是一個絕對值
• HTTP響應報文中 Cache-Control為max-age=600 ，是相對值(解決 Expires 受限于客戶端時間)

除了 max-age ，它還有以下取值：

注意下面的 no-cache ，資源依然會被緩存，并且這個緩存要服務器驗證后才可以使用

max-age=0 和 no-cache 等價嗎?

從規范的字面意思來說，max-age 到期是 應該(SHOULD) 重新驗證，而 no-cache 是 必須(MUST) 重新驗證。但實際情況以瀏覽器實現為準，大部分情況他們倆的行為還是一致的。(如果是 max-age=0, must-revalidate 就和 no-cache 等價了)

總結

自從 HTTP/1.1 開始，Expires 逐漸被 Cache-Control 取代。Cache-Control 是一個相對時間，即使客戶端時間發生改變，相對時間也不會隨之改變，這樣可以保持服務器和客戶端的時間一致性。而且 Cache-Control 的可配置性比較強大。

Cache-Control 的優先級高于 Expires，為了兼容 HTTP/1.0 和 HTTP/1.1，實際項目中兩個字段我們都會設置。

協商緩存(緩存校驗)

如果緩存過期了:

• 沒有 Cache-Control 和 Expires
• Cache-Control 和 Expires 過期
• 設置了 no-cache

需要發起請求驗證服務器資源是否有更新：

• 有更新，返回200，更新緩存
• 無更新，返回304，更新瀏覽器緩存有效期

Last-Modified 和 If-Modified-Since(HTTP/1.0)

• Last-Modified(響應頭)
• If-Modified-Since(請求頭)

Last-Modified 表示本地文件最后修改日期，If-Modified-Since 會將 Last-Modified 的值發送給服務器，詢問服務器在該日期后資源是否有更新，有更新的話就會將新的資源發送回來，否則返回 304 狀態碼。

但是這種方式存在著一些缺點，例如：

• 負載均衡的服務器，各個服務器生成的 Last-Modified 可能有所不同
• GMT 格式有最小單位，例如，如果在一秒內有更改將不能被識別

ETag 和 If-None-Match(HTTP/1.1)

為了解決上面的那個問題， HTTP/1.1 加了這組標記

• ETag(響應頭)
• If-None-Match(請求頭)

ETag 類似于文件指紋，是文件的一個唯一標識序列，當資源有變化時，Etag就會重新生成，If-None-Match 會將當前 ETag 發送給服務器，詢問該資源 ETag 是否變動，有變動的話就將新的資源發送回來。并且 ETag 優先級比 Last-Modified 高

使用 ETag 就可以精確地識別資源的變動情況，就算是秒內的更新，也會讓瀏覽器感知，能夠更有效地利用緩存

ETag 強弱之分

ETag 機制同時支持強校驗和弱校驗。它們通過ETag標識符的開頭是否存在“W/”來區分，如：

"123456789"   -- 一個強ETag驗證符 
W/"123456789"  -- 一個弱ETag驗證符 

強 ETag 要求資源在字節級別必須完全相符，弱 ETag 在值前有個“W/”標記，只要求資源在語義上沒有變化，但內部可能會有部分發生了改變(例如 HTML 里的標簽順序調整，或者多了幾個空格)

Vary 響應

服務器通過指定 Vary: Accept-Encoding ，告知代理服務器，對于這個資源，需要緩存兩個版本：

• 壓縮
• 未壓縮

這樣老式瀏覽器和新的瀏覽器, 通過代理, 就分別拿到了未壓縮和壓縮版本的資源，避免了都拿同一個資源的尷尬。

Vary: Accept-Encoding, User-Agent 

如上設置，代理服務器將針對是否壓縮和瀏覽器類型兩個維度去緩存資源。如此一來，同一個url，就能針對 PC 和 Mobile 返回不同的緩存內容。

來自：https://github.com/Advanced-Frontend/Daily-Interview-Question