[[400059]]

本文轉(zhuǎn)載自微信公眾號「三分鐘學(xué)前端」，作者sisterAn。轉(zhuǎn)載本文請聯(lián)系三分鐘學(xué)前端公眾號。

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

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

其中， 強緩存 ：

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

協(xié)商緩存：

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

緩存過程分析

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

由上圖我們可以知道：

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

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

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

• 強緩存： 向瀏覽器緩存查找該請求結(jié)果，并根據(jù)該結(jié)果的緩存規(guī)則來決定是否使用該緩存結(jié)果的過程
• 協(xié)商緩存： 強緩存失效后，瀏覽器攜帶緩存標識向服務(wù)器發(fā)起請求，由服務(wù)器根據(jù)緩存標識決定是否使用緩存的過程

強緩存(緩存控制)

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

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

Expires(HTTP/1.0)

值為服務(wù)器返回該請求結(jié)果緩存的到期時間:

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

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

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

所以現(xiàn)在 HTTP/1.1中新增了 Cache-Control

Cache-Control(HTTP/1.1)

Cache-control: max-age=30 

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

它與 Expires 相比：

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

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

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

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

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

總結(jié)

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

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

協(xié)商緩存(緩存校驗)

如果緩存過期了:

• 沒有 Cache-Control 和 Expires
• Cache-Control 和 Expires 過期
• 設(shè)置了 no-cache

需要發(fā)起請求驗證服務(wù)器資源是否有更新：

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

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

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

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

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

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

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

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

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

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

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

ETag 強弱之分

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

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

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

Vary 響應(yīng)

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

• 壓縮
• 未壓縮

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

Vary: Accept-Encoding, User-Agent 

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

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