CDN緩存的理解

CDN即內容分發網絡Content Delivery Network，CDN的基本原理是廣泛采用各種緩存服務器，將這些緩存服務器分布到用戶訪問相對集中的地區或網絡中，在用戶訪問網站時，利用全局負載技術將用戶的訪問指向距離最近的工作正常的緩存服務器上，由緩存服務器直接響應用戶請求，CDN的基本思路是盡可能避開互聯網上有可能影響數據傳輸速度和穩定性的瓶頸和環節，使內容傳輸的更快、更穩定，通過在網絡各處放置節點服務器所構成的在現有的互聯網基礎之上的一層虛擬網絡，CDN系統能夠實時地根據網絡流量和各節點的連接、負載狀況以及到用戶的距離和響應時間等綜合信息將用戶的請求重新導向離用戶最近的服務節點上，其目的是使用戶可就近取得所需內容，解決Internet網絡擁擠的狀況，提高用戶訪問網站的響應速度。

組成

• 從功能上看，CDN系統由分發服務系統、負載均衡系統和運營管理系統組成：分發服務系統主要負責資源的響應、緩存和同步。負載均衡系統主要負責均衡單點多個內容緩存設備的負載，並對內容進行緩存負載平衡及訪問控制，以及對用戶請求進行調度以及路由。運營管理系統則負責運營需求管理和網絡系統管理。
• 從節點分布上看，CDN系統主要分為邊緣層和中心層，邊緣層分布在CDN網絡的邊緣位置，給用戶提供就近訪問服務，中心層則負責完成資源同步和運營管理等功能。中心層保存了加速域名的相關配置信息比如源站域名，也緩存了加速域名下的各種資源，在邊緣層節點未命中緩存時，需要向中心層節點發起請求，而中心層節點未能命中緩存時，需要查找對應的源站域名，並向該源站域名發起請求，然后再逐層返回並緩存用戶請求的資源。

功能

• 節省骨干網帶寬，減少帶寬需求量。
• 降低通信風暴的影響，提高網絡訪問的穩定性。
• 提供服務器端加速，解決由於用戶訪問量大造成的服務器過載問題。
• 能克服網站用戶分布不均的問題，並且能降低網站自身建設和維護成本。
• 提供資源訪問緩存，實現相同對象的訪問降低響應延遲，並減少主干網帶寬占用。

關鍵技術

• 緩存算法決定命中率、源服務器壓力、POP節點存儲能力。
• 分發能力取決於IDC能力和IDC策略性分布。
• 負載均衡決定最佳路由、響應時間、可用性、服務質量。
• 基於DNS的負載均衡以CNAME實現最優節點服務。
• 緩存點有客戶端瀏覽器緩存、本地DNS服務器緩存。
• 緩存內容有DNS地址緩存、客戶請求內容緩存、動態內容緩存。
• 支持協議如靜動態加速、圖片加速、HTTPS帶證書加速、下載加速等等。

配置

使用CDN服務提供商的CDN服務時，需要做一些配置：

• 解析一個子域名，可以先隨意解析到某個地址，例如是cdn.example.com。
• 到服務提供商添加該域名，並設置源站域名，例如是www.example.com。
• 此時服務商一般會分配一個CNAME地址，例如是cdn.example.com.service.com。
• 將第一步的域名添加CNAME記錄為分配的CNAME地址。
• 或者服務商在第一步即提供了CNAME地址，那么直接解析即可。

訪問流程

簡單的CDN的訪問流程，這是一種pull的方式拉取緩存：

• 訪問資源時，從上述的子域名中加載資源文件，DNS解析該域名。
• 返回CNAME地址，之后解析CNAME地址。
• 獲得CNAME域名對應的IP地址，指向CDN邊緣層節點。
• CDN邊緣層節點未命中資源緩存，則向中心層節點請求。
• 中心層節點未命中資源緩存，則進行回源，到源站域名服務器獲取資源。
• 成功獲取資源后逐層返回並將資源緩存。
• 在這個查找資源的過程中域名可能會發生變化，但是資源的path是不會變化的。
• 之后再進行訪問，則直接能夠從邊緣節點取得緩存而不用回源，加快資源訪問速度。

緩存控制

在計算機中有兩大難題，一是緩存何時失效，二是如何命名，而CDN中緩存何時失效是一個比較麻煩的問題，假如源站的資源文件發生變化，而用戶此時取得的資源是從緩存節點中取得的，此時就會造成資源文件不一致的現象，解決這個問題可以通過主動push刷新所有CDN緩存的方式來實現，但是這種方式成本較高，比較簡單的解決方案就是在固定時間段過后便使緩存失效，除了節點的緩存需要控制，還需要控制用戶本地緩存，在HTTP協議中提供了如下緩存控制的方式：

強緩存

強緩存是通過Expires與Cache-Control來控制緩存在本地的有效期。

Expires

Expires是HTTP 1.0提出的一個表示資源過期時間的Header，它描述的是一個絕對時間，由服務器返回。Expires受限於本地時間，如果修改了本地時間，可能會造成緩存失效.對於資源的請求，如果在Expires之內，則瀏覽器會直接讀取緩存，不再請求服務器。

Expires: Sun, 14 Jun 2020 02:50:57 GMT

Cache-Control

Cache-Control出現於HTTP 1.1，優先級高於Expires，表示的是相對時間，請求頭和響應頭都支持這個屬性，通過它提供的不同的值來定義緩存策略。

Cache-Control: max-age=300

• Cache-Control: no-store: 緩存中不得存儲任何關於客戶端請求和服務端響應的內容，每次由客戶端發起的請求都會下載完整的響應內容。
• Cache-Control: no-cache: 緩存中會存儲服務端響應的內容，只是在與服務端進行新鮮度再驗證之前，該緩存不能夠提供給瀏覽器使用。簡單來說，就是瀏覽器會將服務端響應的資源進行緩存，但是在每次請求時，緩存都要向服務端評估緩存響應的有效性，協商緩存是否可用，根據響應是304還是200判斷是使用本地緩存資源還是使用服務器響應的資源。
• Cache-Control: public || private: public表示該響應可以被任何中間人比如中間代理、CDN等緩存。默認響應為private，private表示該響應是專用的，中間人不能緩存此響應，該響應只能應用於瀏覽器私有緩存中。
• Cache-Control: max-age=31536000: 響應為最大的過期時間，其指令是max-age=<seconds>，表示資源能夠被緩存即保持新鮮的最大時間，max-age是距離請求發起的時間的秒數。
• Cache-Control: must-revalidate: 當使用了must-revalidate指令，那就意味着緩存在考慮使用一個陳舊的資源時，必須先驗證它的狀態，已過期的緩存將不被使用。在正常情況下是沒有必要使用這個指令的，因為在強緩存過期的情況下會進行協商緩存，但是HTTP規范是允許客戶端在某些特殊情況下直接使用過期緩存的，比如校驗請求發送失敗的時候，還比如有配置一些特殊指令stale-while-revalidate、stale-if-error等的時候，must-revalidate指令就是讓緩存在過期后的任何情況下都必須重新驗證。

協商緩存

當瀏覽器對某個資源的請求沒有命中強緩存，就會發一個請求到服務器，驗證協商緩存是否命中，如果協商緩存命中，請求響應返回的HTTP狀態為304 (Not Modified)，該請求不攜帶實體數據，若未命中，則返回200並攜帶資源實體數據。協商緩存是利用的是Last-Modified，If-Modified-Since和ETag、If-None-Match這兩對Header來管理的。

Last-Modified If-Modified-Since

Last-Modified，If-Modified-Since是HTTP 1.0引入的，Last-Modified表示本地文件最后修改日期，瀏覽器會在請求頭加上If-Modified-Since即上次響應的Last-Modified的值，詢問服務器在該日期后資源是否有更新，有更新的話就會將新的資源發送回來，但是如果在本地打開緩存文件，就會造成Last-Modified被修改，所以在HTTP 1.1出現了ETag。

ETag If-None-Match

Etag就像一個指紋，資源變化都會導致ETag變化，跟最后修改時間沒有關系，ETag可以保證每一個資源是唯一的，If-None-Match的請求頭字段會將上次返回的Etag發送給服務器，詢問該資源的Etag是否有更新，有變動就會發送新的資源回來。ETag的優先級比Last-Modified更高，具體使用ETag主要出於下面幾種情況考慮：

• 一些文件也許會周期性的更改，但是他的內容並不改變，比如僅僅改變的修改時間，這個時候我們並不希望客戶端認為這個文件被修改了，而重新GET。
• 某些文件修改非常頻繁，比如在秒以下的時間內進行修改，例如1s內修改了N次，If-Modified-Since能檢查到的粒度是秒級的，這種修改無法判斷。
• 某些服務器不能精確的得到文件的最后修改時間。

每日一題

https://github.com/WindrunnerMax/EveryDay

參考

https://zhuanlan.zhihu.com/p/40682772
https://baike.baidu.com/item/CDN/420951
https://juejin.im/post/6844904190913822727
https://juejin.im/post/6844903906296725518
https://juejin.im/post/6844903605888090125
https://blog.csdn.net/pedrojuliet/article/details/78394732