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?verson=1.1.1
例：
https://storage.jd.com/xxx/xx?verson=20221111
線上禁止的訪問策略
對于訪問同一資源，url帶時間戳、uuid等具有唯一性引數會直接回源至后端服務，帶來極高的帶寬成本及擊穿底層服務的風險，業務在使用CDN域名訪問時，請務必謹慎使用帶有時間戳、唯一性引數的url，
總結
技術行業發展到今天，海量的流量已然成為常態，而http快取和cdn快取分別作為客戶端快取和服務端快取基石更是值得我們去深入學習、思考，
作者：管宸昊
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/535194.html
標籤：其他
上一篇：6個步驟強化 CI/CD 安全