1. 程式人生 > >http快取與cdn快取配置指南

http快取與cdn快取配置指南

騰訊DeepOcean原創文章:dopro.io/http-cache-…

 

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

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

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

http快取

簡介

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

快取規則

http快取規則由響應首部欄位進行控制,其中的關鍵欄位有ExpiresCache-ControlLast-ModifiedEtag 四個欄位,ExpiresCache-Control用來確定確定快取的儲存時間,Last-ModifiedEtag則用來確定快取是否要被更新,我們簡單來看一下區別。
  • 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控制檯可以很輕鬆的找到一個案例:

http-cdn-example

圖中配置

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

快取流程

http-cdn-http-process

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

重點關注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加速服務配置,面板如下。http-cdn-cdn-config

 

可以看到,提供給我們的配置項只有檔案型別(或檔案目錄)和重新整理時間,意義也很簡單,針對不同檔案型別,在cdn節點上快取對應的時間。

cdn運作流程

http-cdn-cdn-process

 

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

快取配置

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

http-cdn-cloud-tencent-cache這會對我們有什麼影響呢?

  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-cdn-summery

 

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

總結

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

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

看小編搬運這麼辛苦,關注一個唄:)