?前言

HTTP緩存機制是優化web性能的重要手段，也是優化用戶體驗的重要一環。了解和熟悉HTTP緩存機制也成為了前端工作者必不可少的技能。

HTTP緩存是用于臨時存儲網頁資源（如HTML頁面、圖像等），以減少服務器延遲的一種技術。HTTP緩存系統會保存下通過這套系統的文檔的副本；如果滿足某些條件，則可以由緩存滿足后續請求。HTTP緩存系統既可以指設備，也可以指計算機程序。

一、HTTP緩存的類別

HTTP緩存可分為強制緩存和協商緩存。

強制緩存：直接使用客戶端緩存，不從服務器拉取新資源，也不驗證緩存資源是否過期。返回的狀態碼為200（OK）。

協商緩存：通過服務器驗證資源有效性，資源有效則返回304（Not Modified），資源失效則返回最新的資源文件。

HTTP主流的有三個版本：HTTP/1.0、HTTP/1.1、HTTP/2.0。其中HTTP/1.0和HTTP/1.1的應用最為廣泛。HTTP/2.0因對緩存機制的改動有別于HTTP/1.0和HTTP/1.1，因此HTTP/2.0相關內容會在文末總結部分進行介紹。HTTP/1.0與HTTP/1.1可根據緩存類別區分如下：

二、主流的HTTP緩存參數

2.1 強制緩存

2.1.1 HTTP/1.0 - Expires

Expires?的值為服務端返回的到期時間，是一個GMT?（格林尼治標準時間）絕對時間，如：Tue, 17 Jan 2023 03:48:45 GMT?。下一次請求時，客戶端判斷當前系統GMT?時間是否小于緩存攜帶的GMT時間。若小于，直接使用緩存數據，否則從服務器請求新的文件。

不過Expires存在的問題也顯而易見。

首先，使用客戶端獲取的GMT?時間與服務器GMT時間作比較，如果客戶端主動修改了系統時間，就會出現緩存命中的誤差。

其次，GMT時間是基于格林尼治天文臺測算時間后，每隔一小時想全世界發放調時信息。觀測本身存在的誤差以及非實時的同步機制，都可能會導致出現緩存命中的誤差。

所以在HTTP/1.1版本中，使用Cache-Control?中的max-age替代。

2.1.2 HTTP/1.1 - Cache-Control

Cache-Control 是HTTP/1.1中重要的緩存規則。它可以在HTTP請求頭和響應頭中使用，提供了多樣化的配置參數。同時也可以適用于更廣泛的復雜場景。

指令格式具有以下有效規則：

• 不區分大小寫，但建議使用小寫。
• 多個指令以逗號分隔。
• 具有可選參數，可以用令牌或者帶引號的字符串語法。

常用的指令如下：

• no-store：不使用任何形式的緩存。具有HTTP緩存的最高優先級。

• no-cache：不使用強制緩存。每次進行響應前都向服務器進行緩存有效性驗證。

• public：公共緩存。任何從源服務器到客戶端中的每個節點都可以對資源進行緩存。
• private：私有緩存。僅客戶端可以對資源進行緩存。
• max-age：客戶端緩存存儲的最長時間，單位秒。判斷的優先級高于Expires?，客戶端會判斷資源已緩存的時長是否小于設置的max-age?時長。是則直接使用緩存數據，否則會進行Expires的判斷流程。

• s-maxage：代理緩存服務器最長的緩存時間，單位秒。優先級高于max-age和Expires，僅適用于緩存服務器。

2.2 協商緩存

客戶端緩存失效后會向服務器進行進行緩存有效性驗證，這個緩存有效性驗證的過程就是協商緩存?。若資源有效，則返回304（Not Modified）?。客戶端拿到304狀態碼后會再從本地緩存中獲取資源。整個請求響應過程是與無緩存流程一樣的。相對于無緩存流程的優勢在于僅響應狀態碼后，客戶端直接從本地緩存獲取文件，而無需進行文件下載。減少了網絡響應的文件大小，進而加快了網絡響應速度。

協商緩存的請求和響應是需要相互配合的，可組合使用。如下表：

協商緩存會先判斷請求頭中是否攜帶no-store。如果攜帶，則直接返回最新的服務器文件。

2.2.1 HTTP/1.0 - Last-Modified

客戶端第一次向服務器請求資源時，服務器會返回資源。同時會在響應頭中添加Last-Modified?字段來表明資源的最后修改時間。當客戶端強制緩存失效后，會重新向服務器進行緩存有效性驗證。在驗證的請求頭中，會添加If-Modified-Since?字段。服務器會對請求頭中的If-Modified-Since?和其存儲的資源Last-Modified?進行比較。若If-Modified-Since?的時間不小于Last-Modified?，則資源有效，返回304（Not Modified）?。否則返回資源本身，并且重新記錄文件的Last-Modified。

Last-Modified?：響應頭攜帶的資源最后修改時間。格式為last-modified:GMT。

如：last-modified: Sat, 14 Jan 2023 08:40:00 GMT

If-Modified-Since?：請求頭攜帶的資源是否在某個時間后有修改。服務器會使用此值和其本身存儲的時間進行比較。格式為：If-Modified-Since:GMT?。只可以用在 GET? 或 HEAD請求中。

If-Unmodified-Since?：請求頭攜帶的資源是否在某個時間后沒有修改。格式為：if-unmodified-since:GMT? 。有別于If-Modified-Since，If-Unmodified-Since?被用于POST?或其他非簡單請求。如果在If-Unmodified-Since?指定的時間內有過修改，則返回412(Precondition Failed)。

Last-Modified也是存在嚴重問題的。

首先，Last-Modified只關注文件的最后修改時間，和文件內容無關。所以文件內容在修改后又重新恢復，也會導致文件的最后修改時間改變。此時客戶端的請求則無法使用緩存。

其次，Last-Modified?只能監聽到秒級別的文件修改，如果文件在1秒內進行了多次修改，那么響應頭返回的Last-Modified?的時間是不變的。此時客戶端因接收到響應304，會導致資源無法及時更新，使用緩存的資源文件。

因此HTTP/1.1使用了ETag來進行緩存協商。

2.2.1 HTTP/1.1 - ETag

為了解決上述Last-Modified?可能存在的不準確的問題，HTTP/1.1推出了新的響應字段ETag?來進行協商緩存。ETag?的優先級比Last-Modified高。

服務器接收到瀏覽器請求后，會先進行If-None-Match與ETag?值的比較。若相等，則資源有效，返回304（Not Modified）?。否則返回資源本身，并且重新記錄文件的ETag。

ETag?：響應頭攜帶的資源標識符。格式為ETag:ETag-value可由服務器自行設置算法生成，通常是使用內容的散列或簡單的使用版本號。

如：etag: "I82YRPyDtSi45r0Ps/eo8GbnDfg="

If-None-Match?：請求頭攜帶的是否無匹配文件字段。優先級高于Last-Modified?。當服務器沒有任何資源的ETag?與請求頭攜帶的ETag值完全一樣時，返回最新的資源，否則服務器會返回304。

如: if-none-match："I82YRPyDtSi45r0Ps/eo8GbnDfg="

If-Match?：請求頭攜帶的是否存在匹配文件字段。對于簡單請求需要搭配 Range?首部使用。對于非簡單請求，如PUT?，可用于上傳ETag。

如: if-match："I82YRPyDtSi45r0Ps/eo8GbnDfg="

三、總結

通過前文，我們了解到 HTTP 緩存主要分：強制緩存、協商緩存。強制緩存由Exipres（HTTP/1.0）、 Cache-Control（HTTP/1.1）控制。客戶端直接讀本地緩存，不會再跟服務器端交互，狀態碼 200。

協商緩存由 Last-Modified / If-Modified-Since（HTTP/1.0）， Etag /If-None-Match（HTTP/1.1）進行有效性驗證，每次請求需要讓服務器判斷一下資源是否更新過，從而決定客戶端是否使用緩存，如果是，則返回 304，否則返回最新文件。

HTTP/2.0中設計了新的緩存方式，服務器推送（Push Server）。有別于強制緩存和協商緩存，屬于推送緩存。這種新的緩存方式主要是為了解決客戶端緩存時效性的問題，即還沒有收到客戶端的請求，服務器就把各種資源推送給客戶端。比如，客戶端只請求了a.html，但是服務器把a.html、a.css、a.png全部發送給客戶端。這樣的話，只需要一次請求，客戶端就更新了所有文件的緩存，提高了緩存的時效性。

參考：

GMT（維基百科）：https://en.wikipedia.org/wiki/Greenwich_Mean_Time

HTTP緩存（MDN）：https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Caching