聊聊 CDN 緩存與瀏覽器緩存

CDN 是互聯網上內容分發的重要一環。不管您以前是否瞭解過 CDN，其實它已經在您的平常生活中發揮做用了。好比您正在淘寶挑選心儀的商品，或者在觀看一段使人捧腹的視頻，以及您正在閱讀的這篇文章，這些資源展現的背後都有 CDN 的默默支撐。

爲何 CDN 使用如此普遍呢？首先你們須要知道，CDN 旨在解決的最重要的問題是什麼，咱們稱之爲網絡延遲。舉個例子，當您輸入一個網址，敲擊回車後到網頁內容實際出如今屏幕上，中間加載耗費的這個時間，就是網絡延遲。經過網絡獲取資源老是比從本地獲取慢，不管服務器是在同一個局域網中仍是位於世界的另外一個角落，都是如此。這裏的速度差別是 IT 行業的一個核心問題，開發者想了不少辦法試圖去彌補這個差別，CDN 就是應用最爲普遍的一個解決方案。

CDN 爲解決網絡延遲提供了一整套技術方案，今天咱們介紹的緩存就是其中重要的一環。這篇文章主要介紹在使用了 CDN 以後，數據是如何被緩存的，以及緩存是如何提升數據加載速度的。

緩存的優勢

在未接入CDN 以前，用戶使用瀏覽器訪問服務的時候，相互交互的過程以下圖所示。

用戶在第一次訪問網站服務器的時候，瀏覽器會從服務器獲取全部的資源，在傳輸過程當中，瀏覽器會經過一些約定好的響應頭，從而肯定是否須要將這個資源保存一份到本地做爲緩存。當用戶第二次訪問該網站的時候，瀏覽器就會優先從緩存中加載資源，不用向服務器請求資源，從而提升了網站的訪問速度。

例如咱們第一次訪問又拍雲官網，下面就是瀏覽器加載資源的快照，能夠看到 5.6MB 的數據被傳輸到本地。

在刷新又拍雲官網後，咱們能夠看到傳輸數據降到了 9.9KB，在使用了緩存以後，瀏覽器不用再下載所有的文件，減小了下載量也就意味着提升了頁面加載的速度。

經過上面的例子，能夠直觀地觀察到瀏覽器緩存對解決網絡延遲起到的做用是很是明顯的。

而對於一些用戶訪問量巨大的網站而言，若是全部用戶都去服務器請求數據，服務器會很快崩潰，而且在不一樣網絡以及不一樣地區的用戶，請求服務器的速度也不同。爲了提升這部分用戶的訪問速度，CDN 中又提出了新的網絡架構，即建立一些最接近用戶網絡的邊緣服務器，而後將文件緩存在這些邊緣服務器（節點）上，這就是 CDN 緩存。

你們能夠看到，服務接入了 CDN 後，數據經歷了客戶端（瀏覽器）緩存和 CDN 邊緣節點緩存兩個階段，那麼下面就分別對這兩個階段的緩存進行介紹。

瀏覽器緩存介紹

當咱們請求一個網頁的時候，服務器會向瀏覽器返回大量數據，可是這些數據須要所有緩存嗎？瀏覽器又是如何區分哪些數據須要進行緩存，哪些是須要實時跟源站獲取的？接下來咱們就來看一下瀏覽器的緩存策略。

瀏覽器緩存策略

服務器會在資源返回的響應中，攜帶上如下四個經常使用的響應頭，瀏覽器會經過判別這些響應值來決定資源緩存的狀態。

• ETag
• Cache-Control
• Expires
• Last-Modified

ETag

ETag 值是一個字符串，其內容一般是數據的哈希值，每一個數據都有一個單獨的標誌，只要這個文件發生了改變，這個標誌就會發生變化。

服務器能夠在響應中返回 ETag，而後瀏覽器會在後續的請求中攜帶上這個參數來肯定緩存是否須要更新。若是 ETag 值相同，說明資源未更改，服務器會返回 304（Not Modified） 響應碼，瀏覽器就知道本地緩存仍然是可使用的。

不過須要注意的是，ETag 只有在本地緩存已過時（Expires）或者緩存模式設置爲 no-cache（Cache-Control）的時候，纔會被瀏覽器攜帶上與服務器端的值進行判別。

Cache-Control

Cache-Control 能夠攜帶多個響應值，這些值能夠設置緩存時間、狀態以及驗證狀態。不一樣值說明以下。

例如，訪問某張圖片，服務器返回的響應以下：Cache-Control: max-age=691200，則說明這張圖片能夠在客戶端存儲 8 天。

Expires

這個響應頭標記了數據的過時時間，超過其中規定的時間後，緩存會被定義爲過時。例如：Expires: Sat, 27 Apr 2019 11:43:15 GMT

說明對應的數據會在 2019 年 4 月 27 號的 11 點 43 分後過時。

須要注意的是，若是 Cache-Control 中有 max-age 指令，瀏覽器會忽略此參數。

Last-Modified

服務器能夠經過配置這個響應頭，來向瀏覽器發送一個數據上次被修改的時間標籤，例如：Last-Modified:Wed, 24 Apr 2019 02:54:16 GMT

這樣瀏覽器就知道了該數據最後被修改的時間，後續請求中，會和服務器進行時間的比較，若是服務器上的時間比本地時間要新，說明數據有更改，瀏覽器須要從新下載數據。

HTTP 響應示例

接下來咱們能夠看一個響應示例。

第 2 行告訴咱們 max-age 是 1 小時；

第 5 行告訴咱們這是一張 PNG 圖片；

第 7 行向咱們顯示了 ETag 值，該值將在 1 小時標記後用於驗證，以驗證資源是否有更改；

第 8 行是 Expires 響應，由於設置了 max-age，它將被瀏覽器忽略；

第 10 行是 Last-Modified 響應，顯示上次修改圖像的時間。

瀏覽器緩存的不足

當服務器返回的響應中有 Expires 或者 Cache-Control 設置了 max-age 響應頭的時候，瀏覽器不會向服務器發起校驗請求，而是直接複用本地緩存。若是此時服務器進行了資源的更新，用戶就沒法獲取到最新的資源，只能經過強制刷新瀏覽器緩存來跟服務器請求最新的資源。

此外，Expires 是服務器返回的一個絕對時間，在服務器時間與客戶端時間相差較大時，緩存管理容易出現問題，好比隨意修改下客戶端時間，就能影響緩存命中的結果。

所以在實際使用過程當中，須要靈活使用瀏覽器的緩存策略。

CDN 緩存介紹

當服務接入了 CDN 以後，瀏覽器本地緩存的資源過時以後，瀏覽器不是直接向源服務器請求資源，而是轉而向 CDN 邊緣節點請求資源。CDN 邊緣節點中將用戶的數據緩存起來，若是 CDN 中的緩存也過時了，CDN 邊緣節點會向源服務器發出回源請求，從而來獲取最新資源。如下介紹以又拍雲 CDN 爲例。

CDN 緩存策略

CDN 節點緩存策略通常都會遵循 HTTP 標準協議，又拍雲在沒有匹配到自定義緩存規則且源服務器也沒有返回任何有效緩存頭的狀況下，默認配置策略以下：

1. 針對靜態資源，全部正常狀態碼（大於等於 200 小於 400）均緩存 8 天。特別地，301 響應緩存 2 小時，302 響應緩存 20 分鐘；
2. 針對動態資源，程序會自動識別，則不進行緩存；
3. 對於其餘大於等於 400 的不正常響應，則不進行緩存；

緩存節點通知瀏覽器緩存的具體時間由 HTTP 響應頭裏面的 Cache-Control 和 Expires 響應頭控制。

CDN 緩存的不足

CDN 緩存不只減小了用戶的訪問延時，相應的也減小了源服務器的負載，但這裏須要注意，當源服務器資源更新後，若是 CDN 節點上緩存數據還未過時，用戶訪問到的依舊是過時的緩存資源，這會致使用戶最終訪問出現誤差。所以，開發者須要手動刷新相關資源，使 CDN 緩存保持爲最新的狀態。

CDN 緩存刷新

又拍云爲開發者執行緩存刷新提供了主動更新和被動更新兩種方式。

主動更新主要是指同名資源在源服務器更新以後，開發者手動刷新文件。又拍雲提供了可視化的操做臺供用戶執行緩存刷新操做，同時支持 URL 刷新和規則刷新。此外開發者也可經過 API 接口完成刷新操做。

被動刷新則是等文件在 CDN 節點的緩存過時以後，節點回源拉取源服務器上最新的文件。這個過程由 CDN 自動完成，無需手動操做。

現現在是一個快節奏的時代，人們老是但願本身可以第一時間獲取到最新的資訊，使用的是最快捷的服務。又拍雲一直致力於解決互聯網網絡擁塞問題，提升終端用戶訪問網站的響應速度和可用性，爲廣大開發者提供更加簡潔方便的 CDN 一站式服務。

目前又拍雲 CDN 能夠提供基於文件後綴、目錄等多個維度來指定 CDN 緩存和瀏覽器時間，爲開發者提供更精細化的緩存管理服務。針對開發者不一樣的業務需求，又拍雲提供了多項預製模板，方便快捷的來幫助開發者進行數據緩存管理，有效減輕源站負載，經過各網絡、各區域的多個節點，來幫助減少終端用戶訪問服務延時。

 

推薦閱讀：

這樣介紹 CDN，老司機也能聽懂

聊聊常見的網絡攻擊