HTTP緩存與CDN緩存一直是提升web性能的兩大利器，合理的緩存配置可以降低帶寬成本、減輕服務器壓力、提升用户的體驗。而不合理的緩存配置會導致資源界面無法及時更新，從而引發一系列的衍生問題。本文將分別將從HTTP緩存與cdn緩存的規則、流程、配置入手，能讓大家瞭解基礎概念的同時，可對自己的項目配置定製化的緩存調優方案，以及在遇到緩存問題時如何快速定位解決。

首先，讓我們來了解一下緩存在實際場景中的應用

用户第一次訪問網站時，瀏覽器會從服務器獲取所有的資源。在傳輸過程中，瀏覽器會通過一些約定好的響應頭，從而確定是否需要將這個資源保存一份到本地作為緩存，當用户第二次訪問該網站的時候，瀏覽器就會從緩存中加載資源，不用向服務器請求資源，從而提高了網站的訪問速度，而若使用了CDN，當瀏覽器本地緩存的資源過期之後，瀏覽器不是直接向源站點請求資源，而是向CDN邊緣節點請求資源，CDN邊緣節點中也存在緩存，若CDN中的緩存也過期，那就由CDN邊緣節點向源站點發出回源請求來獲取最新資源。

HTTP緩存

簡介

http緩存是一種客户端緩存，當Web瀏覽器向服務器發起資源請求時，服務器可以在響應報文頭中包含緩存相關的信息。這些HTTP Header會告訴瀏覽器是否以及如何緩存資源，再次請求時如果命中緩存將直接讀取本地緩存不再發出請求。

緩存規則

http緩存規則由響應頭中Expires，Cache-Control ，Last-Modified ，Etag 這四個關鍵字段控制。其中Expires和Cache-Control為強緩存用來確定確定緩存的存儲時間，Last-Modified 和Etag為協商緩存則用來確定緩存是否要被更新，接下來我們簡單來看一下區別。

強緩存

•expires: HTTP1.0中用來控制緩存時間的參數，header裏包含日期/時間，用GMT格式的字符串表示， 即在此時間之後，響應過期。

•cache-control: HTTP1.1中用來控制緩存時間的參數

◦public: 表明響應可以被任何對象（包括：發送請求的客户端，代理服務器，等等）緩存。

◦private: 表明響應只能被單個用户緩存，不能作為共享緩存（即代理服務器例如CDN不能緩存它）。

◦max-age=<seconds>: 設置緩存存儲的最大週期，相對於請求的時間緩存seconds秒，在此時間內，訪問資源直接讀取本地緩存，不向服務器發出請求。（與expires同時出現時，max-age優先級更高）

◦s-maxage=<seconds>: 規則等同max-age，覆蓋max-age 或者 Expires 頭，但是僅適用於共享緩存(比如各個代理)，並且私有緩存中它被忽略。（與expires或max-age同時出現時，s-maxage優先級更高）

◦no-store: 不緩存服務器響應的任何內容，每次訪問資源都需要服務器完整響應

◦no-cache: 緩存資源，但立即過期，每次請求都需要跟服務器對比驗證資源是否被修改。（等同於max-age=0）

協商緩存

•Last-modified: 源頭服務器認定的資源做出修改的日期及時間。精確度比Etag低。包含有If-Modified-Since ( 資源修改的時間 )或 If-Unmodified-Since首部的條件請求會使用這個字段，Last-Modified優先級低於Etag。

•Etag: HTTP響應頭是資源的特定版本的標識符，如果客户端想再次請求相同的URL，將會發送一個包含已保存的ETag和“If-None-Match”（標識符字符串）字段的請求。客户端請求之後，服務器可能會比較客户端的ETag和當前版本資源的ETag（只要文件內容改動，ETag就會重新計算）。如果ETag值匹配，這就意味着資源沒有改變，服務器便會發送回一個極短的響應，包含HTTP “304 未修改”的狀態。304狀態告訴客户端，它的緩存版本是最新的，並應該使用它。

我們通過chrome控制枱可以很輕鬆的找到一個案例：

圖中配置

1.Cache-control: max-age=3600代表相對於請求時間，緩存3600秒，即1小時，在此時間內，再次訪問資源直接讀取本地緩存，不向服務器發送請求.

2.Last-modified: Mon...上次修改時間，如果緩存時間過期，該字段將用於與請求中的If-Modified-Since字段進行對比，一致則繼續使用之前緩存，不一致則認定緩存失效

3.Expires: 在http1.0版本下被cache-control覆蓋，此處意為緩存至Mon, 07 Nov ...

4.Etag: Web服務器會返回資源和其相應的ETag值，該字段將用於與當前客户端版本資源的ETag進行對比，一致則繼續使用之前緩存，不一致則認定緩存失效

緩存流程

緩存規則在其中是如何起作用的呢，我們來看幾個重點關注部分

重點關注1: 緩存是否過期

基於該資源上次響應緩存規則同時滿足下列條件則視為緩存未過期，不發請求直接從本地緩存讀取該文件。需要注意的是，判斷緩存是否過期只跟客户端有關係，與服務端無關。1&2&3同時滿足即認為緩存未過期，相反則是已過期

1.cache-control值為max-age

2.max-age > 0

3.當前 date < 上次請求時的date + max-age

注：如果HTTP為1.0時，則用expires判斷是否過期，如果HTTP為1.1及其以上時，則查看cache-control。

重點關注2: 詢問服務器資源是否修改

判斷資源是否修改，需要客户端與服務器共同協作，客户端在首次拿到資源緩存後會存儲Etag（若有）和Last-Modified（若有）,在下次緩存過期時會將Etag寫在請求頭部中的If-None-Match中，將Last-Modified值寫在請求頭部中的If-Modified-Since中，服務端優先對Etag進行對比，然後再對比Last-Modified，一致即視為緩存沒有修改，命中協商緩存，返回304，不一致則返回新文件並帶上新的Etag或Last-Modified值。

重點關注3: 緩存規則

參考上文緩存規則，不在贅述。

小結

對於http緩存的配置，我們只有在瞭解http緩存的原理、規則、流程後，才能根據不同的情況定製不同的規則，真正的發揮http緩存在實際業務中的價值。

CDN緩存

cdn緩存是一種服務端緩存，cdn服務商可以將源站上的資源緩到其各地的邊緣服務器節點上。當用户訪問該資源時，cdn再通過負載均衡將用户的請求調度到最近的緩存節點上，有效減少了鏈路回源，提高了資源訪問效率及可用性，降低帶寬消耗。

緩存規則

與http緩存規則不同的是，這個規則並不是規範性的，而是由cdn服務商來制定，我們以JD內部CDN舉例，打開cdn接入界面，面板如下。

可以看到，提供給我們的配置項只有文件類型（或文件目錄）和Http2，在cdn節點上緩存默認遵循源站設置緩存時長。

運作流程

由圖我們可以看出CDN的主要處理邏輯集中在緩存處理階段，除了關注CDN緩存的文件類型及時間外，我們還需要引入一個概念——回源，客户端請求訪問資源時，如果CDN節點上未緩存該資源，或者部署預熱任務給CDN節點時，CDN節點會回源站獲取資源。如圖中所示，接入cdn後，我們提供服務的服務器就是源站，源站一般情況下只會在cdn節點沒有資源或cdn資源失效時接收到cdn節點的資源請求，其他時間，源站並不會接收請求。簡單的概括就是，沒有資源就去源站讀取，有資源就直接發送給用户。值得注意的是cdn中有s-maxage=0、max-age=0、no-cache、no-store、private中的任一種時候，該類型文件就被認定為不緩存文件，就是所有請求直接轉發源站，只有當緩存時間大於0且緩存過期的時候，才會與源站對比緩存是否被修改。

緩存配置

與在Web瀏覽器中的緩存規則類似，可通過發送緩存指令標頭來控制緩存在CDN中的執行方式。儘管大部分標頭最初都旨在解決客户端瀏覽器中的緩存問題，但現在所有中間緩存（如 CDN）也會使用這些標頭，可使用兩個標頭來定義緩存刷新：Cache-Control 和 Expires。 如果兩者都存在，則 Cache-Control 為最新且優先於 Expires。 還有兩種用於驗證的標頭類型（稱為驗證程序）：ETag 和 Last-Modified。 如果兩者均已定義，則 ETag 為最新且優先於 Last-Modified。以OSS對象存儲為例，在緩存配置的文檔中特別有以下説明。

緩存繼承

當用户請求您某一業務資源時，源站對應的Response HTTP Header中存在Cache-Control字段，此時默認策略如下:

•Cache-Control字段為max-age,對該資源的緩存時間以配置的緩存時間為主，對於小於1小時的緩存時長，不繼承max-age指定時間。

•Cache-Control字段為s-maxage=0、max-age=0、no-cache、no-store、private、nil或無 Cache-Control字段時，對象存儲會源節點會為CDN默認添加：Cache-Control: max-age=3600頭部字段，已確保提高緩存的命中率，同時應對高併發回源流量帶來的風險與成本的增加。

緩存影響

1.如果http緩存設置cache-control: max-age=600，即緩存10分鐘，但對象存儲cdn緩存配置中設置文件緩存時間默認為1小時，那麼就會出現如下情況，文件被訪問後第20分鐘修改並上傳到服務器，用户重新訪問資源，響應碼會是304，對比緩存未修改，資源依然是舊的，一個小時後再次訪問才能更新為最新資源

2.如果不設置cache-control呢，在http緩存中我們説過，如果不設置cache-control，那麼會有默認的緩存時間，但在這裏，對象存儲cdn服務商明確會在沒有cache-control字段時主動幫我們添加cache-control: max-age=3600。

注：針對問題1，也並非沒有辦法，當我們必須要在緩存期內修改文件，並且不向想影響用户體驗，那麼我們可以使用cdn服務商提供的強制更新緩存功能，主要注意的是，這裏的強制更新是更新服務端緩存，http緩存依然按照http頭部規則進行自己的緩存處理，並不會受到影響。

小結

cdn緩存的配置並不複雜， 複雜的情況在於cdn緩存配置會受到http緩存配置的影響，並且不同的cdn運營商有各自的運營規則計費標準，結合來看才能讓cdn緩存在業務中發揮最大的效能。

HTTP緩存與CDN緩存的結合

在我們分別瞭解http緩存配置和cdn緩存配置後，讓我們再結合引言看一次二者結合的請求過程

當用户訪問我們的業務服務器時，首先進行的就是http緩存處理，如果http緩存通過校驗，則直接響應給用户，如果未通過校驗，則繼續進行cdn緩存的處理，cdn緩存處理完成後返回給客户端，由客户端進行http緩存規則存儲並響應給用户。再回到開篇緩存在實際場景中的應用，當我們分析緩存問題時，一定要將兩個流程獨立開來分析判斷，是由於http緩存配置的不合理，還是cdn緩存未及時更新引起的問題。

實戰場景推薦（懶人版）

不同訪問場景下的緩存規則選擇

1.不更新文件內容

優先使用http的本地緩存，配置cache-control: max-age=seconds //seconds > 0（且設置為較大值31536000，即1年）：強緩存，緩存當前資源，在配置時期內，再次請求資源直接讀取本地緩存。

使用cdn緩存，當本地緩存無法使用時，配置較大的cache-control:同樣可以讓業務直接訪問cdn資源，且配置時間內不會再發生回源請求。

2.很少更新文件內容

對於img，css，js，fonts等非html資源，我們可以直接考慮配置cache-control: max-age=seconds //seconds > 0，並且max-age配置的時間可以相對久一些，類似於緩存規則案例中，cache-control: max-age=36000配置10小時的緩存，需要注意的是，這樣配置並不代表這些資源就一定十小時不變，其根本原因在於目前前端構建工具在靜態資源中都會加入戳的概念（例如，webpack中的[hash]，gulp中的gulp-rev），每次修改均會改變文件名或增加query參數，本質上改變了請求的地址，也就不存在緩存更新的問題。

3.頻繁更新文件內容

對於html資源，作為前端資源的入口文件，一旦被強緩存，那麼相關的js，css，img等均無法更新。對於高頻維護的業務類項目，建議配置cache-control: no-cache或cache-control: max-age=0：採用協商緩存，緩存當前資源，但每次訪問都需要跟服務器對比，檢查資源是否被修改。但是基於流量和成本的考慮更推薦於max-age設置一個較小值，例如3600，一小時過期。對於一些活動項目，上線後不會進行較大改動，建議業務配置一個較小的max-age值，否則一旦出現bug或是未知問題，用户無法及時更新。

除了以上考慮，有時候其他因素也會影響緩存的配置，例如春晚紅包除夕活動，高併發大流量很容易給服務器帶來極大挑戰，這時我們作為前端開發，就可以採用靜態頁面提前加載兜底來避免用户多次進入帶來的流量壓力。

如何減少緩存規則帶來的訪問影響

1.通過清理緩存控制

我們可以使用cdn服務商提供的強制更新緩存功能，主要注意的是，這裏的強制更新是更新服務端緩存，http緩存依然按照http頭部規則進行自己的緩存處理，並不會受到影響。

2.通過url帶版本號或者版本發佈時間

我們在使用對象存儲發佈資源時，可根據版本號或發佈時間定義url，以作為區分。

例：https://storage.jd.com/xxx/xx...

例： https://storage.jd.com/xxx/xx...

線上禁止的訪問策略

對於訪問同一資源，url帶時間戳、uuid等具有唯一性參數會直接回源至後端服務，帶來極高的帶寬成本及擊穿底層服務的風險，業務在使用CDN域名訪問時，請務必謹慎使用帶有時間戳、唯一性參數的url。

總結

技術行業發展到今天，海量的流量已然成為常態，而http緩存和cdn緩存分別作為客户端緩存和服務端緩存基石更是值得我們去深入學習、思考。

作者：管宸昊