設計一個完美的HTTP緩存策略

德威雅 2019-08-24

展開全文

1、前言

作為一個前端，了解http緩存是非常必要，它不僅是面試的必要環(huán)節(jié)，也更是實戰(zhàn)開發(fā)中必不可少需要了解的知識點，本文作者將從緩存的概念講到如何在業(yè)務中設計一個合理的緩存架構，帶你一步一步解開http緩存的神秘面紗。

2、http緩存定義

當客戶端向服務器請求資源時，會先抵達瀏覽器緩存，如果瀏覽器有“要請求資源”的副本，就可以直接從瀏覽器緩存中提取而不是從原始服務器中提取這個資源。http緩存一般針對GET請求，POST請求一般不會緩存，因為POST請求執(zhí)行的任務都是對服務器產生副作用或者非冪等性的任務，既然要改變服務器資源，自然請求是要進入服務器進行處理的。緩存帶來的好處是巨大的，減少了http請求，自然也就減少的服務端壓力，并且增加了資源的訪問速度，但是胡亂使用緩存，將會帶來資源的不及時更新，甚至資源更新錯位，災難也是巨大的。
http緩存分為強緩存和協(xié)商緩存，下面帶大家一一了解兩種緩存機制。

3、強緩存

3.1、強緩存定義

如果命中緩存，直接從緩存中拿數(shù)據(jù)，請求不會經過服務器，返回的http狀態(tài)碼為200(from disk cache)

下面給一張流程圖來說明強緩存的請求過程，為了方便假設瀏覽器存在一個緩存數(shù)據(jù)庫（其實就是disk磁盤，緩存數(shù)據(jù)存放的地方）。

仔細看上面的流程圖，強緩存的最大特點就是在命中緩存的情況下不會經過服務器，而是直接返回。

3.2、Http頭Expires/Cache-Control設置強緩存

Cache-Control里面存在多個屬性來控制緩存，設置強緩存即設置資源的有效期，屬性為max-age.
下面使用Express給大家演示一下

app.get('/script1.js', function (req, res, next) {    // res.header('Cache-Control', 'must-revalidate, max-age=600')    // res.header('Content-Type', 'text/html')    res.header('Cache-Control', 'max-age=20')    res.sendFile(__dirname + '/script.js')})

4、協(xié)商/對比緩存

4.1、定義

協(xié)商緩存與強制緩存的不同之處在于，協(xié)商緩存每次讀取數(shù)據(jù)時都需要跟服務器通信，并且會增加緩存標識。在第一次請求服務器時，服務器會返回資源，并且返回一個資源的緩存標識，一起存到瀏覽器的緩存數(shù)據(jù)庫。當?shù)诙握埱筚Y源時，瀏覽器會首先將緩存標識發(fā)送給服務器，服務器拿到標識后判斷標識是否匹配，如果不匹配，表示資源有更新，服務器會將新數(shù)據(jù)和新的緩存標識一起返回到瀏覽器；如果緩存標識匹配，表示資源沒有更新，并且返回 304 狀態(tài)碼，瀏覽器就讀取本地緩存服務器中的數(shù)據(jù)。
協(xié)商緩存的最大特點是要經過服務器驗證的，下面我們來講解協(xié)商緩存的驗證流程。
第一次訪問：

再次訪問：

還是給一張流程圖來說明。（圖是盜的，協(xié)商緩存也可以成為對比緩存，圖中的對比緩存就是協(xié)商緩存）

4.2、協(xié)商緩存如何驗證

第一次請求將response header的Last-Modified和Etag存起來，在第二次請求通過request header的If-Modified-Since和If-None-Match傳到服務端進行驗證，如果命中緩存，返回304，不帶返回的數(shù)據(jù)，瀏覽器自動從緩存中獲取數(shù)據(jù)資源，若未命中緩存返回200，帶上數(shù)據(jù)資源。

** Last-Modified：**
服務器在響應請求時，告訴瀏覽器資源的最后修改時間。

** If-Modified-Since：**
再次請求服務器時，通過此字段通知服務器上次請求時，服務器返回的資源最后修改時間。
服務器收到請求后發(fā)現(xiàn)有頭If-Modified-Since 則與被請求資源的最后修改時間進行比對。
若資源的最后修改時間大于If-Modified-Since，說明資源又被改動過，則響應整片資源內容，返回狀態(tài)碼200；
若資源的最后修改時間小于或等于If-Modified-Since，說明資源無新修改，則響應HTTP 304，告知瀏覽器繼續(xù)使用所保存的cache。

** Etag / If-None-Match（優(yōu)先級高于Last-Modified / If-Modified-Since） **
** Etag：**
服務器響應請求時，告訴瀏覽器當前資源在服務器的唯一標識（生成規(guī)則由服務器決定）。

** If-None-Match：**
再次請求服務器時，通過此字段通知服務器客戶段緩存數(shù)據(jù)的唯一標識。
服務器收到請求后發(fā)現(xiàn)有頭If-None-Match 則與被請求資源的唯一標識進行比對，
不同，說明資源又被改動過，則響應整片資源內容，返回狀態(tài)碼200；
相同，說明資源無新修改，則響應HTTP 304，告知瀏覽器繼續(xù)使用所保存的cache。

4.3、Http頭如何設置協(xié)商緩存

在強緩存那一節(jié)說到使用Cache-Control的max-age來設置資源過期時間，那么當max-age=0的時候呢，自然瀏覽器第一時間發(fā)現(xiàn)資源過期，request header就會帶著If-Modified-Since和If-None-Match去服務端驗證。
所以設置response header為：

Cache-Control: max-age=0

就可以觸發(fā)協(xié)商緩存了，其實Cache-Control中還有兩個屬性都可以設置協(xié)商緩存 must-revalidate和no-cache
must-revalidate的意義為必須進行驗證，但是它一般是和max-age一起使用的，不會單獨使用，

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

該頭信息意義就是在資源有效期過后必須進行驗證，與只設置max-age=600的區(qū)別是，前面一個是MUST，而后面一個是SHOULD，理論上來說它們的效果是一致的。
no-cache的意義千萬不能理解為不緩存，下面兩段代碼的意義是一樣的，即請求必須進行驗證，才可以使用緩存資源，注意是MUST

Cache-Control: no-cacheCache-Control: must-revalidate, max-age=0

如果要不緩存，每次都請求新的資源應該使用

Cache-Control: no-store

5、關于緩存的Http頭總結

5.1、'no-cache', 'no-store', 'must-revalidate'

Cache-Control字段可以設置的不僅僅是max-age存儲時間，還有其他額外的值可以填寫，甚至可以組合。主要使用的值有如下：
no-cache: 雖然字面意義是“不要緩存”。但它實際上的機制是，仍然對資源使用緩存，但每一次在使用緩存之前必須（MUST）向服務器對緩存資源進行驗證。
no-store: 不使用任何緩存
must-revalidate: 如果你配置了max-age信息，當緩存資源仍然新鮮（小于max-age）時使用緩存，否則需要對資源進行驗證。所以must-revalidate可以和max-age組合使用Cache-Control: must-revalidate, max-age=60
有趣的事情是，雖然no-cache意為對緩存進行驗證，但是因為大家廣泛的錯誤的把它當作no-store來使用，所以有的瀏覽器也就附和了這種設計。這是一個典型的劣幣驅逐良幣。

5.2、Expires VS. max-age

Expires和max-age都是用于控制緩存的生命周期。不同的是Expires指定的是過期的具體時間，例如Sun, 21 Mar 2027 08:52:14 GMT，而max-age指定的是生命時長秒數(shù)315360000。
區(qū)別在于Expires是 HTTP/1.0 的中的標準，而max-age是屬于Cache-Control的內容，是 HTTP/1.1 中的定義的。但為了想向前兼容，這兩個屬性仍然要同時存在。
但有一種更傾向于使用max-age的觀點認為Expires過于復雜了。例如上面的例子Sun, 21 Mar 2027 08:52:14 GMT，如果你在表示小時的數(shù)字缺少了一個0，則很有可能出現(xiàn)出錯；如果日期沒有轉換到用戶的正確時區(qū)，則有可能出錯。這里出錯的意思可能包括但不限于緩存失效、緩存生命周期出錯等。

5.3、Etag VS. Last-Modified

Etag和Last-Modified都可以用于對資源進行驗證，而Last-Modified顧名思義，表示資源最后的更新時間。
我們把這兩者都成為驗證器（Validators），不同的是，Etag屬于強驗證（Strong Validation），因為它期望的是資源字節(jié)級別的一致；而Last-Modified屬于弱驗證（Weak Validation），只要資源的主要內容一致即可，允許例如頁底的廣告，頁腳不同。
根據(jù)RFC 2616標準中的13.3.4小節(jié)，一個使用HTTP 1.1標準的服務端應該（SHOULD）同時發(fā)送Etag和Last-Modified字段。同時一個支持HTTP 1.1的客戶端，比如瀏覽器，如果服務端有提供Etag的話，必須（MUST）首先對Etag進行Conditional Request（If-None-Match頭信息）；如果兩者都有提供，那么應該（SHOULD）同時對兩者進行Conditional Request（If-Modified-Since頭信息）。如果服務端對兩者的驗證結果不一致，例如通過一個條件判斷資源發(fā)生了更改，而另一個判定資源沒有發(fā)生更改，則不允許返回304狀態(tài)。但話說回來，是否返回還是通過服務端編寫的實際代碼決定的。所以仍然有操縱的空間。

5.4、max-age=0 VS. no-cache

max-age=0是在告訴瀏覽器，資源已經過期了，你應該（SHOULD）對資源進行重新驗證了；而no-cache則是告訴瀏覽器在每一次使用緩存之前，你必須（MUST）對資源進行重新驗證。
區(qū)別在于，SHOULD是非強制性的，而MUST是強制性的。在no-cache的情況下，瀏覽器在向服務器驗證成功之前絕不會使用過期的緩存資源，而max-age=0則不一定了。雖然理論上來說它們的效果應該是一致的。

5.5、public VS. private

要知道從服務器到瀏覽器之間并非只有瀏覽器能夠對資源進行緩存，服務器的返回可能會經過一些中間（intermediate）服務器甚至甚至專業(yè)的中間緩存服務器，還有CDN。而有些請求返回是用戶級別、是私人的，所以你可能不希望這些中間服務器緩存返回。此時你需要將Cache-Control設置為private以避免暴露。

6、緩存實戰(zhàn)

前面寫了很多緩存的基礎知識，那么如何設計一個可靠的緩存規(guī)則，這個其實得根據(jù)你的實際需求而定。
比如某個資源永遠不會改變，比如某些第三方庫（一般都放CDN做優(yōu)化了），或者某些圖片，比如百度的圖片，就讓它們永久緩存著吧，設置一個最大的max-age

Cache-Control: max-age=31536000

其他的資源可根據(jù)下面這張決策樹來進行設置

7、memory cache

“內存緩存”中主要包含的是當前文檔中頁面中已經抓取到的資源。例如頁面上已經下載的樣式、腳本、圖片等。我們不排除頁面可能會對這些資源再次發(fā)出請求，所以這些資源都暫存在內存中，當用戶結束瀏覽網(wǎng)頁并且關閉網(wǎng)頁時，內存緩存的資源會被釋放掉。
這其中最重要的緩存資源其實是preloader相關指令（例如）下載的資源?？偹苤猵reloader的相關指令已經是頁面優(yōu)化的常見手段之一，而通過這些指令下載的資源也都會暫存到內存中。根據(jù)一些材料，如果資源已經存在于緩存中，則可能不會再進行preload。
需要注意的事情是，內存緩存在緩存資源時并不關心返回資源的HTTP緩存頭Cache-Control是什么值，同時資源的匹配也并非僅僅是對URL做匹配，還可能會對Content-Type，CORS等其他特征做校驗
這個應該是瀏覽器做的一種優(yōu)化，緩存也只是暫時的。