作為前端開發(fā)，緩存是整天接觸的概念，面試必問、工作中也頻繁接觸到，可能大家對緩存的 header 記的比較熟了，可是大家有沒有思考過為什么 HTTP 的緩存控制要這么設(shè)計呢?

首先，為什么要有緩存?

網(wǎng)頁中的代碼和資源都是從服務(wù)器下載的，如果服務(wù)器和用戶的瀏覽器離得比較遠(yuǎn)，那下載過程會比較耗時，網(wǎng)頁打開也就比較慢。下次再訪問這個網(wǎng)頁的時候，又要重新再下載一次，如果資源沒有啥變動的話，那這樣的重新下載就很沒必要。所以，HTTP 設(shè)計了緩存的功能，可以把下載的資源保存起來，再打開網(wǎng)頁的時候直接讀緩存，速度自然會快很多。

而且，每個請求都要服務(wù)端做相應(yīng)的處理，比如解析 url，讀取文件，返回響應(yīng)等，而服務(wù)器能同時處理的請求是有上限的，也就是負(fù)載是有上限的，所以如果能通過緩存減少沒必要的資源的請求，就能解放服務(wù)器，讓它去處理一些更有意義的請求。

綜上，為了提高網(wǎng)頁打開速度，降低服務(wù)器的負(fù)擔(dān)，HTTP 設(shè)計了緩存的功能。

那 HTTP 是怎么設(shè)計的緩存功能呢?

如果讓大家設(shè)計 HTTP 的緩存功能，大家會怎么設(shè)計呢?

最容易想到的就是指定一個時間點了，到這個時間之前都直接用緩存，過期之后才去下載新的。

HTTP 1.0 的時候也是這么設(shè)計的，也就是 Expires 的 header，它可以指定資源過期時間，到這個時間之前不去請求服務(wù)器，直接拿上次下載好被緩存起來的內(nèi)容，

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

但是這種設(shè)計有個 bug，不知道大家能猜出來不。

首先這個時間是指 GMT 時間，也就是會轉(zhuǎn)化為格林尼治那個時區(qū)的時間，不存在時區(qū)問題。

服務(wù)端會把當(dāng)?shù)氐臅r間轉(zhuǎn)化為 GMT 時間，比如當(dāng)前是某個時間點 xxx，想緩存的時間為 yyy，那 Expires 就設(shè)置為 xxx + yyy 的時間。

如果瀏覽器的時間是準(zhǔn)確的，那轉(zhuǎn)化為 GMT 時間后應(yīng)該也是 xxx，所以緩存的時間就是 yyy。

這是理想中的情況。

但萬一瀏覽器的時間不準(zhǔn)呢?轉(zhuǎn)化為 GMT 時間之后就不是 xxx，那具體緩存的時間也就不是 yyy 了，這就是問題。

所以，這個過期時間不能讓服務(wù)端來算，應(yīng)該讓瀏覽器自己算。

這也是為什么在 HTTP 1.1 里面改為了 max-age 的方式：

Cache-Control: max-age=600

上面就代表資源緩存 600 秒，也就是 10 分鐘。

讓瀏覽器來自己算啥時候過期，也就沒有 Expires 的問題了。(這也是為什么同時存在 max-age 和 Expires 會用 max-age 的原因)

當(dāng)然，不同的資源會有不同的 max-age，比如打開 b 站首頁你會看到不同資源的 max-age 是不同的：

比如一些庫的 js 文件就設(shè)置了 31536000，也就是 1 年后過期，因為一般也不會變，以年為單位沒啥問題。

而業(yè)務(wù)的 js 文件設(shè)置了 600，也就是 10 分鐘過期，業(yè)務(wù)代碼經(jīng)常會變動嘛。

細(xì)心的同學(xué)可能會發(fā)現(xiàn)之前都是 key: value 形式的 header，現(xiàn)在咋變成了 key: k1=v1,k2=v2 的形式了呢?

沒錯，這也是 HTTP 1.1 做的設(shè)計，他們想把緩存相關(guān)的 header 都集中到一起，所以就包了一層，都放在 Cache-Control 的 header 里。

所以名字上也就不一樣了，Expires: xxx 這種叫做消息頭(header)，而 Cache-Control: max-age=xxx 里面的 max-age 叫做指令(directive)。

好了，改成 max-age 之后，瀏覽器就會在本地計算出的過期時間就去下載新的資源了。

但是這樣就行了么?

只是到了過期時間，但是資源并不一定有變化呀，那再下載一次同樣的內(nèi)容還是很沒必要。

所以要和服務(wù)端確認(rèn)下是否內(nèi)容真的變了，變了的話就重新下載，否則的話就不用再下載了，有這樣一個協(xié)商的過程。

所以 HTTP 1.1 又設(shè)計了協(xié)商緩存的 header。

我們說到資源過期了，瀏覽器要和服務(wù)端確認(rèn)下是否有更新，怎么判斷資源過期呢?

比較容易想到可以通過文件內(nèi)容的 hash，也可以通過最后修改時間，這倆分別叫 Etag 和 Last-Modified：

服務(wù)端返回資源的時候就會帶上這倆 header。

那在 max-age 時間到了的時候，就可以帶上 etag 和 last-modified 就請求服務(wù)器，問下是否資源有更新。

帶上 etag 的 header 叫做 If-None-Match:

If-None-Match: "bfc13a64729c4290ef5b2c2730249c88ca92d82d"

帶上 last-modified 時間的叫做 If-Modified-Since：

If-Modified-Since: Wed, 21 Oct 2015 07:28:00 GMT

服務(wù)端判斷下如果資源有變化，那就返回 200，并在響應(yīng)體帶上新的內(nèi)容，瀏覽器就用這份新下載的資源。

如果沒有變化，那就返回 304，響應(yīng)體是空的，瀏覽器會直接讀緩存。

這樣多了一個協(xié)商的階段，那在本地緩存過期但是服務(wù)端改資源沒有變化的時候就能避免重復(fù)的下載。

那如果文件確定不會變，不需要協(xié)商的話，怎么告訴瀏覽器呢?可以用 immutable 的 header 來告訴瀏覽器，這個資源就是不變的，不用協(xié)商了。這樣就算緩存過期了也不會發(fā)驗證的 header(If-None-Match 和 If-Modified-Since)：

Cache-control: immutable

我們前面講了 HTTP 1.1 改成了 Cache-control: k1=v1,k2=v2 的形式，那除了 max-age 還有啥其他的 directive 呢?

前面我們講的都是瀏覽器的緩存控制，但請求從瀏覽器到服務(wù)器的過程中，中間可能經(jīng)過很多層代理。

代理服務(wù)器的緩存怎么控制?

瀏覽器里的緩存都是用戶自己的，叫做私有緩存，而代理服務(wù)器上的緩存大家都可以訪問，叫做公有緩存。

如果這個資源只想瀏覽器里緩存，不想代理服務(wù)器上緩存，那就設(shè)置 private，否則設(shè)置 public：

比如這樣設(shè)置就是資源可以在代理服務(wù)器緩存，緩存時間一年(代理服務(wù)器的 max-age 用 s-maxage 設(shè)置)，瀏覽器里緩存時間 10 分鐘：

Cache-control:public, max-age=600,s-maxage:31536000

這樣設(shè)置就是只有瀏覽器可以緩存：

Cache-control: private, max-age=31536000

而且，緩存過期了就完全不能用了么?

不是的，其實也想用過期的資源也是可以的，有這樣的指令：

Cache-control: max-stale=600

stale 是不新鮮的意思。請求里帶上 max-stale 設(shè)置 600s，也就是說過期 10 分鐘的話還是可以用的，但是再長就不行了。

Cache-control: stale-while-revalidate=600

也可以設(shè)置 stale-while-revalidate，也就是說在和瀏覽器協(xié)商還沒結(jié)束的時候，就先用著過期的緩存吧。

Cache-control: stale-if-error=600

或者設(shè)置 stale-if-error，也就是說協(xié)商失敗了的話，也先用著過期的緩存吧。

所以說，max-age 的過期時間也不是完全強制的，是可以允許過期一段時間的。

那如果我想強制在緩存還沒協(xié)商完的時候不用過期的緩存怎么辦呢?

用這個指令 must-revalidate：

Cache-Control: max-age=31536000, must-revalidate

名字上就可以看出來，就是緩存失效了的話，必須等驗證結(jié)束，中間不能用過期的緩存。

可能有的同學(xué)會有疑問，緩存不都是自己設(shè)置的么，咋還一個允許過期，一個禁止過期呢?

自己會同時用這兩種和自己玩么?

自己肯定不會，但是 CDN 廠商可能會呀，想禁止這種用過期緩存的行為，就可以設(shè)置這個 must-revalidate 指令。

最后，HTTP 當(dāng)然也支持禁止緩存，也就是這樣：

Cache-control: no-store

設(shè)置了 no-store 的指令就不會緩存文件了，也就沒有過期時間和之后的協(xié)商過程。

如果允許緩存，但是需要每次都協(xié)商下的話就用 no-cache:

Cache-control: no-store

可能有的同學(xué)對 no-cache 和 must-revalidate 的區(qū)別比較迷糊，我們理一下：

no-cache 相當(dāng)于禁掉了強緩存，每次都要協(xié)商下，而 must-revalidate 只是在強緩存過期之后，禁止掉了用過期的緩存的過程，強制必須協(xié)商。

至此，http 的緩存設(shè)置我們就講完了，來總結(jié)一下：

總結(jié)

緩存能加快也面的打開速度，也能減輕服務(wù)器壓力，所以 HTTP 設(shè)計了緩存機(jī)制。

HTTP 1.0 的時候是使用 Expires 的 header 來控制的，指定一個 GMT 的過期時間，但是當(dāng)瀏覽器時間不準(zhǔn)的時候就有問題了。

HTTP 1.1 的時候改為了 max-age 的方式來設(shè)置過期時間，讓瀏覽器自己計算。并且把所有的緩存相關(guān)的控制都放到了 Cache-control 的 header 里，像 max-age 等叫做指令。

緩存過期后，HTTP 1.1 還設(shè)計了個協(xié)商階段，會分別通過 If-None-Match 和 If-Modified-Since 的 header 帶資源的 Etag 和 Last-Modied 到服務(wù)端問下是否過期了，過期了的話就返回 200 帶上新的內(nèi)容，否則返回 304，讓瀏覽器拿緩存。

除了 max-age 的指令外，我們還學(xué)了這些指令：

• public：允許代理服務(wù)器緩存資源。
• s-maxage：代理服務(wù)器的資源過期時間。
• private：不允許代理服務(wù)器緩存資源，只有瀏覽器可以緩存。
• immutable：就算過期了也不用協(xié)商，資源就是不變的。
• max-stale：過期了一段時間的話，資源也能用。
• stale-while-revalidate：在驗證(協(xié)商)期間，返回過期的資源。
• stale-if-error：驗證(協(xié)商)出錯的話，返回過期的資源。
• must-revalidate：不允許過期了還用過期資源，必須等協(xié)商結(jié)束。
• no-store：禁止緩存和協(xié)商。
• no-cache：允許緩存，但每次都要協(xié)商。

雖然 HTTP 緩存相關(guān)的指令還是挺多的，但是都是圍繞 max-age 和過期后的協(xié)商來設(shè)計的，思路理清的話，還是很容易就能記住的。