騰訊DeepOcean原創文章：dopro.io/http-cache-and

配置http緩存與cdn緩存一直以來都是web性能優化中重要而常見的手段。合理的http緩存與cdn緩存配置可以起到減輕伺服器壓力，緩解網路瓶頸，提升用戶體驗等作用，不當的緩存配置卻會導致資源無法及時更新，用戶體驗差異，甚至流程出錯等問題。本文主要講解http緩存與cdn緩存的原理和配置規則，希望通過本文的講解能夠讓大家清楚什麼是合理的緩存配置，如何為自己的項目定製化緩存方案，以及如果碰到緩存問題，應該如何分析解決。

首先，讓我們來看這樣一個場景

項目A上線了一個新特性，包含著邏輯的改動和頁面UI的更新，小明作為項目開發將代碼提交後進行了預發布。產品經理小紅開始體驗新特性，奇怪的是，小紅進入項目後卻並沒有看到最新的特性，這時小明思考了一會說，小紅你點擊刷新再試試，果然，刷新後項目有了變化，新特性出來了，但是這時又有了新的問題，項目里的圖片似乎還是舊圖，小明又思考了一會，隨後在電腦前搗鼓一番，讓小紅再次體驗，終於，這個時候特性完整驗收通過。上述的案例中，其實就包含著http緩存和cdn緩存的應用，當然，這是一個反面教材，實際上線過程中，我們不可能讓每一個用戶點擊刷新來體驗我們的新特性，那應該如何解決上述問題呢，接下來上乾貨。

http緩存

簡介

http緩存是客戶端緩存，瀏覽器作為客戶端接受到服務端響應後，對於響應首部欄位進行解析，分析出相應的緩存規則，將資源按規則進行緩存，再次請求時如果命中緩存則直接讀取本地緩存不再發出請求。

緩存規則

http緩存規則由響應首部欄位進行控制，其中的關鍵欄位有Expires，Cache-Control ，Last-Modified ，Etag 四個欄位，Expires和Cache-Control用來確定確定緩存的存儲時間，Last-Modified 和Etag則用來確定緩存是否要被更新，我們簡單來看一下區別。

  • expires: HTTP1.0中用來控制緩存時間的參數，響應頭包含日期/時間， 即在此時間之後，響應過期。
  • cache-control: HTTP1.1中用來控制緩存時間的參數
    • public: 表明響應可以被任何對象（包括：發送請求的客戶端，代理伺服器，等等）緩存。
    • private: 表明響應只能被單個用戶緩存，不能作為共享緩存（即代理伺服器不能緩存它）。
    • 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首部的條件請求會使用這個欄位。
  • Etag: HTTP響應頭是資源的特定版本的標識符。

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

圖中配置

  1. cache-control: max-age=31535000 代表相對於請求時間，緩存31536000秒，即365天，在此時間內，再次訪問資源直接讀取本地緩存，不向伺服器發送請求.
  2. last-modified: Mon...上次修改時間，如果緩存時間過期，該欄位將用於與請求中的If-Modified-Since欄位進行對比，一致則繼續使用之前緩存，不一致則認定緩存失效
  3. expires: 在http1.0版本下被cache-control覆蓋，此處意為緩存至Sat, 11 Aug ...

緩存流程

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

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

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

  1. cache-control值為max-age
  2. max-age > 0
  3. 當前 date < 上次請求時的date + max-age

註：expire可同等轉化為cache-control=max-age形式，不再贅述，s-maxage與maxage規則相同，不再贅述

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

判斷資源是否修改，需要客戶端與伺服器共同協作，客戶端在首次拿到資源緩存後會存儲Etag（若有）和Last-Modified（若有）,在下次緩存過期時會將Etag寫在請求頭部中的If-None-Match中，將Last-Modified值寫在請求頭部中的If-Modified-Since中，服務端優先對Etag進行對比，然後再對比Last-Modified，完全通過後即視為緩存沒有修改，有一項不通過則認為資源已被修改，緩存失效

重點關注3: 緩存規則

緩存規則主要由cache-control欄位和expires欄位體現，同時出現則以cache-control為準具體情況如下：

  1. cache-control=no-store 不緩存任何資源
  2. cache-control=no-cache 緩存但立即過期
  3. cache-control=max-age（s-maxage） = 0 緩存但立即過期（等同於no-cache）
  4. cache-control=max-age（s-maxage）= seconds （seconds > 0）—— 基於請求時間緩存seconds秒
  5. cache-control=其他 根據http標準，如果不攜帶任何關於緩存時常的標記，則緩存時間等於當前時間和 Last-Modified時間的差值的10%，等同於cache-control=max-age=（date - Last-Modified）/ 10，通過fiddler抓包可看到英文原文：No explicit HTTP Cache Lifetime information was provided.Heuristic expiration policies suggest defaulting to: 10% of the delta between Last-Modified and Date.
  6. expires = 過去的時間或無效時間，緩存但立即過期，等同於cache-control=no-cache
  7. expires = 未來的時間，緩存到對應時間

緩存配置

從上述規則和與流程圖中我們可以看到，緩存規則的配置其實並不複雜，除開Etag和Last-Modified用於緩存對比（實際使用中只需要開啟該功能即可），我們需要關注的其實只是cache-control（expires可轉化為max-age形式，不再贅述），方案如下：

  1. cache-control: no-store：不緩存，每次訪問都從服務下載所有資源。
  2. cache-control: no-cache或cache-control: max-age=0：對比緩存，緩存當前資源，但每次訪問都需要跟伺服器對比，檢查資源是否被修改。
  3. cache-control: max-age=seconds //seconds > 0：強緩存，緩存當前資源，在一定時期內，再次請求資源直接讀取本地緩存。

註：強緩存下資源也並非不可更新，例如chrome的ctrl + f5等同於直接觸發方案1，f5或者webview的刷新鍵會直接觸發方案2，但都是基於客戶端操作，不建議納入實際項目考慮。

實際項目中，方案1的應用基本上看不到，對比方案2和方案3，方案1沒有任何優勢。在方案2和方案3的選擇中，我們會對資源作區分。

  • 對於img，css，js，fonts等非html資源，我們可以直接考慮方案3，並且max-age配置的時間可以儘可能久，類似於緩存規則案例中，cache-control: max-age=31535000配置365天的緩存，需要注意的是，這樣配置並不代表這些資源就一定一年不變，其根本原因在於目前前端構建工具在靜態資源中都會加入戳的概念（例如，webpack中的[hash]，gulp中的gulp-rev），每次修改均會改變文件名或增加query參數，本質上改變了請求的地址，也就不存在緩存更新的問題。
  • 對於html資源，我們建議根據項目的更新頻度來確定採用哪套方案。html作為前端資源的入口文件，一旦被強緩存，那麼相關的js，css，img等均無法更新。對於高頻維護的業務類項目，建議採用方案2，或是方案3但max-age設置一個較小值，例如3600，一小時過期。對於一些活動項目，上線後不會進行較大改動，建議採用方案3，不過max-age也不要設置過大，否則一旦出現bug或是未知問題，用戶無法及時更新。

除了以上考慮，有時候其他因素也會影響緩存的配置，例如QQ紅包除夕活動，高並發大流量很容易給伺服器帶來極大挑戰，這時我們作為前端開發，就可以採用方案3來避免用戶多次進入帶來的流量壓力。

小結

對於http緩存的配置，我們始終要做到兩點，一是清楚明白http緩存的原理與規則，二是明確緩存的配置不是一次性的，根據不同的情況配置不同的規則，才能夠更好的發揮http緩存的價值。

cdn緩存

cdn緩存是一種服務端緩存，CDN服務商將源站的資源緩存到遍布全國的高性能加速節點上，當用戶訪問相應的業務資源時，用戶會被調度至最接近的節點最近的節點ip返回給用戶，在web性能優化中，它主要起到了，緩解源站壓力，優化不同用戶的訪問速度與體驗的作用。

緩存規則

與http緩存規則不同的是，這個規則並不是規範性的，而是由cdn服務商來制定，我們以騰訊雲舉例，打開cdn加速服務配置，面板如下。

可以看到，提供給我們的配置項只有文件類型（或文件目錄）和刷新時間，意義也很簡單，針對不同文件類型，在cdn節點上緩存對應的時間。

cdn運作流程

由圖我們可以看出，cdn緩存的配置主要作用在緩存處理階段，雖然配置項只有文件類型和緩存時間，但流程卻並不簡單，我們先來明確一個概念——回源，回源的意思就是返回源站，何為源站，就是我們自己的伺服器，很多人誤解接入cdn就是把資源放在了cdn上，其實不然，如圖中所示，接入cdn後，我們的伺服器就是源站，源站一般情況下只會在cdn節點沒有資源或cdn資源失效時接收到cdn節點的請求，其他時間，源站並不會接收請求（當然，如果我們知道源站的地址，我們可以直接訪問源站）。明確了回源的概念後，cdn的流程就顯得不那麼複雜了，簡單的理解就是，沒有資源就去源站讀取，有資源就直接發送給用戶。與http緩存不同的是，cdn中沒有no-cache（max-age=0）的情況，當我們設置緩存時間為0的時候，該類型文件就被認定為不緩存文件，就是所有請求直接轉發源站，只有當緩存時間大於0且緩存過期的時候，才會與源站對比緩存是否被修改。

緩存配置

cdn緩存配置並不麻煩，整體來說，建議和http緩存配置保持統一。需要特別注意的是，cdn的緩存配置會受到http緩存配置的影響，而且各個cdn服務商並不完全一致，以騰訊云為例，在緩存配置的文檔中特別有以下說明。

這會對我們有什麼影響呢？

  1. 如果我們http緩存設置cache-control: max-age=600，即緩存10分鐘，但cdn緩存配置中設置文件緩存時間為1小時，那麼就會出現如下情況，文件被訪問後第12分鐘修改並上傳到伺服器，用戶重新訪問資源，響應碼會是304，對比緩存未修改，資源依然是舊的，一個小時後再次訪問才能更新為最新資源
  2. 如果不設置cache-control呢，在http緩存中我們說過，如果不設置cache-control，那麼會有默認的緩存時間，但在這裡，cdn服務商明確會在沒有cache-control欄位時主動幫我們添加cache-control: max-age=600。

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

小結

cdn緩存的配置並不複雜， 複雜的情況在於cdn緩存配置會受到http緩存配置的影響，並且不同的cdn運營商對於這種影響的處理也都不一致，實際使用時，建議去對應的cdn服務商文檔中找到對應的注意事項。

http緩存與cdn緩存的結合

當我們分別理解了http緩存配置和cdn緩存配置後，我們還有一件事情，就是理解二者結合時，請求的流向問題

當用戶訪問我們的業務伺服器時，首先進行的就是http緩存處理，如果http緩存通過校驗，則直接響應給用戶，如果未通過校驗，則繼續進行cdn緩存的處理，cdn緩存處理完成後返回給客戶端，由客戶端進行http緩存規則存儲並響應給用戶。當我們分析緩存問題時，一定要將兩個流程獨立開來分析，現在來看開篇時的錯誤案例，很明顯，第一個問題時由於http緩存配置不合理，導致用戶必須進行強制刷新才能更新資源，第二個問題則是cdn緩存未及時更新造成的。

總結

http緩存和cdn緩存分別作為客戶端緩存和服務端緩存共同影響著我們的web請求流向，要想做好緩存配置，首先是清楚緩存的原理和配置規則，其次則是結合項目分析緩存級別，具體情況具體處理。

歡迎關注"騰訊DeepOcean"微信公眾號,每周為你推送前端、人工智慧、SEO/ASO等領域相關的原創優質技術文章：

看小編搬運這麼辛苦，關注一個唄：)

weixin.qq.com/r/IiiVjTv (二維碼自動識別)


推薦閱讀：
相关文章