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 標准協議，又拍雲在沒有匹配到自定義緩存規則且源服務器也沒有返回任何有效緩存頭的情況下，默認配置策略如下：
- 針對靜態資源，所有正常狀態碼（大於等於 200 小於 400）均緩存 8 天。特別地，301 響應緩存 2 小時，302 響應緩存 20 分鍾；
- 針對動態資源，程序會自動識別，則不進行緩存；
- 對於其他大於等於 400 的不正常響應，則不進行緩存；
緩存節點通知瀏覽器緩存的具體時間由 HTTP 響應頭里面的 Cache-Control 和 Expires 響應頭控制。
CDN 緩存的不足
CDN 緩存不僅減少了用戶的訪問延時，相應的也減少了源服務器的負載，但這里需要注意，當源服務器資源更新后，如果 CDN 節點上緩存數據還未過期，用戶訪問到的依舊是過期的緩存資源，這會導致用戶最終訪問出現偏差。因此，開發者需要手動刷新相關資源，使 CDN 緩存保持為最新的狀態。
CDN 緩存刷新
又拍雲為開發者執行緩存刷新提供了主動更新和被動更新兩種方式。
主動更新主要是指同名資源在源服務器更新之后，開發者手動刷新文件。又拍雲提供了可視化的操作台供用戶執行緩存刷新操作，同時支持 URL 刷新和規則刷新。此外開發者也可通過 API 接口完成刷新操作。
被動刷新則是等文件在 CDN 節點的緩存過期之后，節點回源拉取源服務器上最新的文件。這個過程由 CDN 自動完成，無需手動操作。
現如今是一個快節奏的時代，人們總是希望自己能夠第一時間獲取到最新的資訊，使用的是最快捷的服務。又拍雲一直致力於解決互聯網網絡擁塞問題，提高終端用戶訪問網站的響應速度和可用性，為廣大開發者提供更加簡潔方便的 CDN 一站式服務。
目前又拍雲 CDN 可以提供基於文件后綴、目錄等多個維度來指定 CDN 緩存和瀏覽器時間，為開發者提供更精細化的緩存管理服務。針對開發者不同的業務需求，又拍雲提供了多項預制模板，方便快捷的來幫助開發者進行數據緩存管理，有效減輕源站負載，通過各網絡、各區域的多個節點，來幫助減小終端用戶訪問服務延時。
推薦閱讀：