大家好，我是前端西瓜哥。今天講一下 HTTP 緩存策略的強緩存和協(xié)商緩存。

緩存是什么?

緩存(Cache)是一種數(shù)據(jù)存儲技術，廣泛應用在電腦工程領域。

它將原本訪問起來較慢的數(shù)據(jù)，放到訪問更快的存儲介質(zhì)中，當?shù)诙卧L問時，能夠更快地訪問數(shù)據(jù)，是一種 空間換時間 的做法。

比如，有個文件經(jīng)常被讀取，且很少改變，那我們就直接將其緩存到內(nèi)存中，節(jié)省掉耗時的 IO 磁盤讀取時間。

再比如，在寫代碼時，我們的一個方法會接受參數(shù)，然后計算返回一個結果，假設這個計算過程非常耗時，且結果值只依賴傳入的參數(shù)。

那我們就可以將參數(shù)和結果的對應映射，保存到哈希表中，下次如果是相同參數(shù)，就能命中然后直接從哈希表里獲取，速度有了極大提升。

HTTP 緩存也是一樣的道理，用戶通過 HTTP 請求訪問的資源會緩存到本地，在用戶第二次訪問相同資源時，直接使用之前緩存的資源。

當然資源可能并不一定是不變的，在必要的時候需要更新緩存。為此我們可能需要設置一下緩存的有效期，或是發(fā)送一個占用帶寬小的請求詢問服務端等等。

這些，就是 HTTP 緩存策略。

強緩存

強緩存，指的是 讓瀏覽器強制緩存服務端提供的資源。

“東西就給你了，沒事別找我?！?/p>

Cache-Control: max-age=<seconds>

響應頭字段 Cache-Control，通過設置 max-age=<seconds>，可以規(guī)定資源的緩存有效時間長度，單位為秒。

需要注意的是 Cache-Control 是通用頭字段，請求頭和響應頭中都可以使用。

響應頭字段的 Cache-Control 用于告知客戶端如何緩存資源。

客戶端的 Cache-Control 則是告知服務器需要多新鮮的資源，比如 no-cache 或 max-age=0 表示要最新鮮的資源。

Cache-Control: max-age=31536000

在瀏覽器 devtool 的 network 面板，我們看到 from disk cache 的字樣，代表這個資源并沒有去發(fā)送請求，而是使用了來自硬盤的緩存。

如果你不停地刷新頁面，你還會看到 from memory cache ：來自內(nèi)存的緩存。因為刷新前資源正在使用，還在內(nèi)存中，刷新后瀏覽器就直接從內(nèi)存中取出來了。

當你強制刷新時，瀏覽器會在請求頭中加上 Cache-Control: no-cache 或是 Cache-Control: max-age=0，要求服務端返回最新資源。

Expires

Cache-Control: max-age= ，是緩存的有效時長。

當看到一個叫 max-age(有效時長)的東西時，我們經(jīng)常會發(fā)現(xiàn)它的孿生兄弟：Expires(過期時間點)。如果你熟悉 Cookies，你會發(fā)現(xiàn) Cookies 也有這么一對屬性。

Expires: Wed, 21 Oct 2015 07:28:00 GMT

Expires 使用的 GMT 格式的時間戳字符串。

當 max-age 和 Expires 都存在時，使用 max-age。這點和 Cookies 一樣。

強緩存，就是讓瀏覽器將資源緩存下來，在緩存過期前，不發(fā)送請求獲取新資源，而是直接使用本地資源。

協(xié)商緩存

協(xié)商緩存，是在緩存過期的情況下，客戶端和服務端協(xié)商，確認客戶端緩存是否需要更新。

Last-Modified 和 If-Modified-Since

響應頭字段 Last-Modified 表示提供的資源最后被修改的時間。值是 GMT 格式的字符串。

Last-Modified: Sat, 09 Apr 2022 14:47:36 GMT

這個時間會標記在對應緩存上，起到標識的作用。

當瀏覽器的緩存失效后，會再次請求服務端，并帶上 If-Modified-Since 請求頭字段，它的值就是之前 Last-Modified 帶過來的值。

If-Modified-Since: Sat, 09 Apr 2022 14:47:36 GMT

當服務端發(fā)現(xiàn)資源最后修改時間和 If-modified-since 值相等，代表資源從該時間后再未改變過。

服務端于是返回 304(Not Modified)狀態(tài)碼，表示資源沒有改變，并且響應體為空。瀏覽器拿到后，就知道原本可能過期的緩存其實還可以繼續(xù)使用。

如果資源改變了，就會返回 200，且響應體帶上最新資源。

ETag 和 If-None-Match

除了用 Last-Modified 代表的資源最后修改時間作為標識，我們還可以使用 ETag 響應頭。

ETag 的值沒有規(guī)定，你可以是時間戳的哈希值，也可以是版本號。

另外 ETag 分為強 ETag 和弱 ETag，其中弱 ETag 以為 W/ 開頭。

ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"
ETag: W/"0815"

然后和 If-Modified-Since 一樣，當緩存過期時，客戶端會在請求頭帶上 If-None-Match 去請求資源。

If-None-Match: "33a64df551425fcc55e4d42a148795d9f25f89d4"

如果資源依舊新鮮，則返回 304，客戶端繼續(xù)復用本地資源。

結尾

強緩存，設置一個過期時間，讓客戶端在過期前使用本地緩存，直到過期才請求更新鮮的資源。涉及的頭字段有 Cache-Control: max-age= 或 Expires 。

協(xié)商緩存，在客戶端緩存過期的情況下，和服務端協(xié)商一下，是否可以繼續(xù)使用本地緩存。涉及的頭字段有 Last-Modified / If-Modified-Since 和 ETag / If-None-Match。

不過需要注意的是，這些都只是規(guī)范，我們無法確定客戶端或服務端在實現(xiàn)上完全遵循，而且可能在版本更新中會出現(xiàn)一些 bug。

所以對于發(fā)生變化的文件，我更傾向于給文件名加上哈希串。畢竟，訪問一個從來沒訪問過的資源，客戶端是不會有緩存的。這樣就能繞開緩存機制，真正拿到最新資源，而不會掉入緩存陷阱。

參考

• RFC7234 - Request Cache-Control Directives：https://www.rfc-editor.org/rfc/rfc7234#section-5.2.1。
• RFC7232 - Weak versus Strong：https://www.rfc-editor.org/rfc/rfc7232#section-2.1。
• stackoverflow - What takes precedence: the ETag or Last-Modified HTTP header?：https://stackoverflow.com/questions/824152/what-takes-precedence-the-etag-or-last-modified-http-header。