《CDN 之我見》原理篇——CDN的由來與調度

CDN是將源站內容分發至全國全部的節點，從而縮短用戶查看對象的延遲，提升用戶訪問網站的響應速度與網站的可用性的技術。它可以有效解決網絡帶寬小、用戶訪問量大、網點分佈不均等問題。

 

爲了讓你們更全面的瞭解CDN的原理、調度、緩存和安全等關鍵技術點，阿里雲高級技術專家白金將本身從事 CDN 相關領域工做 8 年來的一些經驗、收穫和我的認知撰寫成《CDN之我見》系列文章，分享給你們。

《CDN 之我見》共分紅多個部分，分爲原理篇、詳解篇和隕坑篇，由於篇幅問題這裏先講第一部分。本篇章適合那些從未接觸過、或僅瞭解一些 CDN 專業術語，想深刻了解和感覺 CDN 到底是什麼的同窗。下面咱們進入分享正文：

 

這個篇章，主要分紅 4 個小部分來和你們作一下簡單的介紹和分享。

 

CDN的起源

 

CDN 誕生於二十多年前，隨着骨幹網壓力的逐漸增大，以及長傳需求的逐漸增多，使得骨幹網的壓力愈來愈大，長傳效果愈來愈差。因而在 1995 年，MIT 的應用數學教授 Tom Leighton 帶領着研究生 Danny Lewin 和其餘幾位頂級研究人員一塊兒嘗試用數學問題解決網絡擁堵問題。

 

他們使用數學算法，處理內容的動態路由安排，並最終解決了困擾 Internet 使用者的難題。後來，史隆管理學院的 MBA 學生 Jonathan Seelig 加入了 Leighton 的隊伍中，從那之後他們開始實施本身的商業計劃，最終於 1998 年 8 月 20 日正式成立公司，命名爲 Akamai。

同年 1998 年，中國第一家 CDN 公司 ChinaCache 成立。

 

在接下來的20年中，CDN行業歷經變革和持續發展，行業也涌現出不少雲CDN廠商。阿里雲CDN是2008年從淘寶CDN起家，在2014年正式發展成爲阿里雲CDN的，它不只爲阿里巴巴集團全部子公司提供服務，同時也將自身的資源、技術以雲計算的方式輸出。

 

那什麼是 CDN 呢？

 

CDN 實際上是 Content Delivery Network 的縮寫，即「內容分發網絡」。

上圖是一個作過 CDN 以後的拓撲圖，裏面有幾個概念須要明確一下:

• Origin Server：源站，也就是作 CDN 以前的客戶真正的服務器。
• User：訪問者，也就是問網站的網民。
• Edge Server：CDN 的服務器，不單指「邊緣服務器」，這個以後細說。

在 CDN 中，還有 3 個」一英里「的概念，即 First Mile、Middle Mile 和 Last Mile。

• First Mile：和 CDN 客戶的服務器越近越好的 CDN 設備，即第一英里。
• Last Mile：訪問者（網民）到離他最近的 CDN 服務器，即最後一英里。
• Middle Mile：數據從進入 CDN 網絡，到出 CDN 網絡以前的全部環節，即中間一英里。

 

爲何要用 CDN 呢？

 

從上圖能夠看到，左圖是未作 CDN 以前跨洋跨國的長傳業務，用戶從西班牙訪問到美國紐約要通過北大西洋，直線距離6,000km 左右，按照光速300,000km/s 的傳輸速度，一束光從西班牙到紐約也至少須要 20ms 時間，一個往返就須要 40ms。若是是光纖傳輸數據，加上傳輸損耗、傳輸設備延時引入等，可能上百毫秒就出去了，即便用瀏覽器訪問一個再小不過的圖片，也會等個上百毫秒，聚沙成塔，訪問一個美國購物網站會讓用戶沒法接受。

 

右側這張圖是作過 CDN 以後的示意圖。從圖上能夠看出，網民實際訪問到的服務器不是位於美國的真實服務器，而是位於英國的 CDN 服務器。而 CDN 自己有緩存功能，把那些網頁裏一成不變的內容，例如圖片、音樂、視頻等，都分發並緩存到了各個 CDN 服務節點上，這樣網民就沒必要從西班牙訪問到紐約，而是訪問距離本身較近的英國節點便可，從而節省了 80% 以上的時間。

 

固然，這是一個西班牙訪問英國 CDN 節點的例子，若是 CDN 節點也位於西班牙本地，則效果會更加明顯，具體細節後續會有更詳細的說明。

 

接下來講一下調度。調度是 CDN 中的重中之重，流量接入、流量牽引、選擇合適的 CDN 節點服務器等工做，都是在調度環節完成的。

 

要理解調度策略和原理，必須先了解 DNS 協議及其工做原理。

咱們平時所工做的電腦裏，都會配置（人爲或自動）一個 DNS 服務器地址，咱們稱之爲」本地 DNS「，也叫 Local DNS，簡稱 LDNS。在解析一個域名的時候，實際訪問的不是」域名「而是 IP 地址，則 LDNS 服務器的用途就是負責將域名翻譯成 Internet 能夠識別的 IP 地址。

在請求某個域名時，LDNS 通常有兩個狀況：一種是域名在 LDNS 上有記錄，另外一種狀況是沒有記錄，兩種狀況的處理流程不同。

• 假設當訪問 163 這個域名時，若是 LDNS 上有緩存記錄，那它會直接將 IP 地址吐出來。
• 若是沒有緩存記錄，它將會一步步向後面的服務器作請求，而後將全部數據進行彙總後交給最終的客戶，這個環節術語叫」遞歸「。

在徹底不命中狀況，LDNS 首先會向全球13個根域服務器發起請求，詢問 .com 域名在哪裏，而後根域服務器做出回答，而後去向 .com 的服務器詢問 .163.com 在哪裏，一步步往下，最後拿到 www.163.com 這個域名所對應的 IP 地址。這個過程較複雜，若是你們感興趣可去查相關資料，在這就不一一贅述。

確定不少人好奇是如何進行調度和進行定位的？其實也是經過 LDNS 的具體地址來進行的，如上圖所示。

假設網民是一個北京客戶，那他所使用的 DNS 服務器去作遞歸的時會訪問到CDN廠商的 GLB（Global Load Balance），它能夠看到所訪問的域名請求是來自於哪一個 LDNS，根據通常人的使用習慣，網民所在位置和 LDNS 所在位置是同樣的，所以 GLB 能夠間接知道網民來自什麼位置。

假如網民是一個北京聯通的用戶，它使用的 LDNS 地址也是北京聯通的，而 LDNS 訪問 GLB 也是北京聯通的，則 GLB 則認爲網民的位置在北京聯通，那麼會分配一個北京聯通的 CDN 服務器地址給 LDNS，LDNS 將http:www.a.com解析出的 IP 地址返回給最終網民，那麼在之後網民瀏覽器發起請求的時候，都會直接與北京聯通的 CDN 節點進行流量通訊，從而達到了加速的目的。

從這個調度理論上看，咱們能夠不難發現一個問題，就是重點標註出的「根據通常人的使用習慣」。假設網民所使用的 LDNS 地址和他本身在同一個區域，調度纔有多是準確的（後續篇章會重點描述爲何是「有可能」）。

可是舉個例子來講，若是網民是北京聯通的用戶，但他卻偏要使用深圳電信的 LDNS，LDNS 出口也一樣是深圳電信的 IP 地址，那麼 GLB 會誤判網民位於深圳電信，分配給網民的 CDN 服務器也都是深圳電信的，後續網民會從北京聯通訪問到深圳電信，不但沒加速，可能反而降速了。

 

如前文所述，因爲用戶使用習慣或一些其餘緣由，經過 LDNS 調度有多是不許確的，所以又出現了另外一種調度方式，HTTP 302 調度。

原理很簡單，不管網民最初拿到的 IP 地址是不是正確的，但最終都是要和這個 IP 地址的 CDN 服務器通訊的，所以 CDN 服務器能夠在這時知道網民的真實地址（DNS 調度時只能間接知道網民地址，雖然 EDNS-Client-Subnet 技術能夠解決問題，但還沒有大規模使用）。

HTTP 協議中有一個特殊的返回狀態：302。在 HTTP 服務器返回 302 狀態碼時，能夠攜帶一個新的 URL（使用的是正確 IP），瀏覽器在拿到 302 返回狀態碼時，會提取其中新的 URL 地址發起請求，這樣就能夠作到從新調度了。

 

除了 DNS 調度、HTTP 302 調度，還有一種使用 HTTP 進行的 DNS 調度策略。

隨着網絡突飛猛進的發展和演進，也逐漸出現了不少不爲人知的技術和設備，例如劫持（具體在後面的篇章裏會單獨闡述）。劫持後，網民所訪問的目標有可能再也不是真實服務器，即便是真實服務器，內容也有多是虛假的、被替換過的，這對業務安全來講是十分危險的，這種劫持現象多出如今移動互聯網（手機上網）。

爲了規避這種問題，出現了一種 HTTP DNS 的調度方式，原理是經過 HTTP 報文傳輸 DNS 請求和應答信息。但這種方式沒有任何 RFC 的支持，因此沒有任何現成的操做系統直接支持，必須有本身的 HTTP DNS 客戶端，來與 HTTP DNS 服務端進行通訊，須要雙端支持。這種作法在 APP 中使用較多。

那 CDN 是如何將用戶的流量引入到 CDN 網絡中的呢？

在未作 CDN 時，咱們訪問某個域名，直接拿到的是一個真實的服務器 IP 地址，這個顯示 IP 地址的 DNS 記錄信息叫 A 記錄，通常是下圖這個樣子。

 

當業務須要接入到 CDN 時，用戶只需調整本身的 DNS 配置信息，將 A 記錄改成 CNAME 記錄，將內容改成 CDN 廠商所提供的接入域名便可。

原文連接

閱讀更多幹貨好文，請關注掃描如下二維碼：