摘要：接下來說一下調(diào)度。調(diào)度是中的重中之重，流量接入流量牽引選擇合適的節(jié)點(diǎn)服務(wù)器等工作，都是在調(diào)度環(huán)節(jié)完成的。協(xié)議中有一個(gè)特殊的返回狀態(tài)。由于篇幅的關(guān)系，系列一先把的歷史由來，以及調(diào)度相關(guān)的知識(shí)和大家分享。

CDN是將源站內(nèi)容分發(fā)至全國所有的節(jié)點(diǎn)，從而縮短用戶查看對(duì)象的延遲，提高用戶訪問網(wǎng)站的響應(yīng)速度與網(wǎng)站的可用性的技術(shù)。它能夠有效解決網(wǎng)絡(luò)帶寬小、用戶訪問量大、網(wǎng)點(diǎn)分布不均等問題。

為了讓大家更全面的了解CDN的原理、調(diào)度、緩存和安全等關(guān)鍵技術(shù)點(diǎn)，阿里云高級(jí)技術(shù)專家白金將自己從事 CDN 相關(guān)領(lǐng)域工作 8 年來的一些經(jīng)驗(yàn)、收獲和個(gè)人認(rèn)知撰寫成《CDN之我見》系列文章，分享給大家。

成多個(gè)部分，分為原理篇、詳解篇和隕坑篇，因?yàn)槠鶈栴}這里先講第一部分。本篇章適合那些從未接觸過、或僅了解一些 CDN 專業(yè)術(shù)語，想深入了解和感受 CDN 究竟是什么的同學(xué)。下面我們進(jìn)入分享正文：

這個(gè)篇章，主要分成 4 個(gè)小部分來和大家做一下簡單的介紹和分享。

CDN 誕生于二十多年前，隨著骨干網(wǎng)壓力的逐漸增大，以及長傳需求的逐漸增多，使得骨干網(wǎng)的壓力越來越大，長傳效果越來越差。于是在 1995 年，MIT 的應(yīng)用數(shù)學(xué)教授 Tom Leighton 帶領(lǐng)著研究生 Danny Lewin 和其他幾位頂級(jí)研究人員一起嘗試用數(shù)學(xué)問題解決網(wǎng)絡(luò)擁堵問題。

他們使用數(shù)學(xué)算法，處理內(nèi)容的動(dòng)態(tài)路由安排，并最終解決了困擾 Internet 使用者的難題。后來，史隆管理學(xué)院的 MBA 學(xué)生 Jonathan Seelig 加入了 Leighton 的隊(duì)伍中，從那以后他們開始實(shí)施自己的商業(yè)計(jì)劃，最終于 1998 年 8 月 20 日正式成立公司，命名為 Akamai。

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

在接下來的20年中，CDN行業(yè)歷經(jīng)變革和持續(xù)發(fā)展，行業(yè)也涌現(xiàn)出很多云CDN廠商。阿里云CDN是2008年從淘寶CDN起家，在2014年正式發(fā)展成為阿里云CDN的，它不僅為阿里巴巴集團(tuán)所有子公司提供服務(wù)，同時(shí)也將自身的資源、技術(shù)以云計(jì)算的方式輸出。

CDN 其實(shí)是 Content Delivery Network 的縮寫，即“內(nèi)容分發(fā)網(wǎng)絡(luò)”。

之后的拓?fù)鋱D，里面有幾個(gè)概念需要明確一下:

Origin Server：源站，也就是做 CDN 之前的客戶真正的服務(wù)器。
User：訪問者，也就是問網(wǎng)站的網(wǎng)民。
Edge Server：CDN 的服務(wù)器，不單指“邊緣服務(wù)器”，這個(gè)之后細(xì)說。
在 CDN 中，還有 3 個(gè)”一英里“的概念，即 First Mile、Middle Mile 和 Last Mile。

First Mile：和 CDN 客戶的服務(wù)器越近越好的 CDN 設(shè)備，即第一英里。
Last Mile：訪問者（網(wǎng)民）到離他最近的 CDN 服務(wù)器，即最后一英里。
Middle Mile：數(shù)據(jù)從進(jìn)入 CDN 網(wǎng)絡(luò)，到出 CDN 網(wǎng)絡(luò)之前的所有環(huán)節(jié)，即中間一英里。

從上圖可以看到，左圖是未做 CDN 之前跨洋跨國的長傳業(yè)務(wù)，用戶從西班牙訪問到美國紐約要經(jīng)過北大西洋，直線距離6,000km 左右，按照光速300,000km/s 的傳輸速度，一束光從西班牙到紐約也至少需要 20ms 時(shí)間，一個(gè)往返就需要 40ms。如果是光纖傳輸數(shù)據(jù)，加上傳輸損耗、傳輸設(shè)備延時(shí)引入等，可能上百毫秒就出去了，即使用瀏覽器訪問一個(gè)再小不過的圖片，也會(huì)等個(gè)上百毫秒，積少成多，訪問一個(gè)美國購物網(wǎng)站會(huì)讓用戶無法接受。

右側(cè)這張圖是做過 CDN 之后的示意圖。從圖上可以看出，網(wǎng)民實(shí)際訪問到的服務(wù)器不是位于美國的真實(shí)服務(wù)器，而是位于英國的 CDN 服務(wù)器。而 CDN 本身有緩存功能，把那些網(wǎng)頁里一成不變的內(nèi)容，例如圖片、音樂、視頻等，都分發(fā)并緩存到了各個(gè) CDN 服務(wù)節(jié)點(diǎn)上，這樣網(wǎng)民就不必從西班牙訪問到紐約，而是訪問距離自己較近的英國節(jié)點(diǎn)即可，從而節(jié)省了 80% 以上的時(shí)間。

當(dāng)然，這是一個(gè)西班牙訪問英國 CDN 節(jié)點(diǎn)的例子，如果 CDN 節(jié)點(diǎn)也位于西班牙本地，則效果會(huì)更加明顯，具體細(xì)節(jié)后續(xù)會(huì)有更詳細(xì)的說明。

接下來說一下調(diào)度。調(diào)度是 CDN 中的重中之重，流量接入、流量牽引、選擇合適的 CDN 節(jié)點(diǎn)服務(wù)器等工作，都是在調(diào)度環(huán)節(jié)完成的。

要理解調(diào)度策略和原理，必須先了解 DNS 協(xié)議及其工作原理。

我們平時(shí)所工作的電腦里，都會(huì)配置（人為或自動(dòng)）一個(gè) DNS 服務(wù)器地址，我們稱之為”本地 DNS“，也叫 Local DNS，簡稱 LDNS。在解析一個(gè)域名的時(shí)候，實(shí)際訪問的不是”域名“而是 IP 地址，則 LDNS 服務(wù)器的用途就是負(fù)責(zé)將域名翻譯成 Internet 可以識(shí)別的 IP 地址。

在請(qǐng)求某個(gè)域名時(shí)，LDNS 一般有兩個(gè)情況：一種是域名在 LDNS 上有記錄，另一種情況是沒有記錄，兩種情況的處理流程不一樣。

假設(shè)當(dāng)訪問 163 這個(gè)域名時(shí)，如果 LDNS 上有緩存記錄，那它會(huì)直接將 IP 地址吐出來。

如果沒有緩存記錄，它將會(huì)一步步向后面的服務(wù)器做請(qǐng)求，然后將所有數(shù)據(jù)進(jìn)行匯總后交給最終的客戶，這個(gè)環(huán)節(jié)術(shù)語叫”遞歸“。

在完全不命中情況，LDNS 首先會(huì)向全球13個(gè)根域服務(wù)器發(fā)起請(qǐng)求，詢問 .com 域名在哪里，然后根域服務(wù)器作出回答，然后去向 .com 的服務(wù)器詢問 .163.com 在哪里，一步步往下，最后拿到 www.163.com 這個(gè)域名所對(duì)應(yīng)的 IP 地址。這個(gè)過程較復(fù)雜，如果大家感興趣可去查相關(guān)資料，在這就不一一贅述。

肯定很多人好奇是如何進(jìn)行調(diào)度和進(jìn)行定位的？其實(shí)也是通過 LDNS 的具體地址來進(jìn)行的，如上圖所示。

假設(shè)網(wǎng)民是一個(gè)北京客戶，那他所使用的 DNS 服務(wù)器去做遞歸的時(shí)會(huì)訪問到CDN廠商的 GLB（Global Load Balance），它可以看到所訪問的域名請(qǐng)求是來自于哪個(gè) LDNS，根據(jù)一般人的使用習(xí)慣，網(wǎng)民所在位置和 LDNS 所在位置是一樣的，因此 GLB 可以間接知道網(wǎng)民來自什么位置。

以上圖為例，假如網(wǎng)民是一個(gè)北京聯(lián)通的用戶，它使用的 LDNS 地址也是北京聯(lián)通的，而 LDNS 訪問 GLB 也是北京聯(lián)通的，則 GLB 則認(rèn)為網(wǎng)民的位置在北京聯(lián)通，那么會(huì)分配一個(gè)北京聯(lián)通的 CDN 服務(wù)器地址給 LDNS，LDNS 將http:www.a.com解析出的 IP 地址返回給最終網(wǎng)民，那么在以后網(wǎng)民瀏覽器發(fā)起請(qǐng)求的時(shí)候，都會(huì)直接與北京聯(lián)通的 CDN 節(jié)點(diǎn)進(jìn)行流量通信，從而達(dá)到了加速的目的。

從這個(gè)調(diào)度理論上看，我們可以不難發(fā)現(xiàn)一個(gè)問題，就是重點(diǎn)標(biāo)注出的“根據(jù)一般人的使用習(xí)慣”。假設(shè)網(wǎng)民所使用的 LDNS 地址和他自己在同一個(gè)區(qū)域，調(diào)度才有可能是準(zhǔn)確的（后續(xù)篇章會(huì)重點(diǎn)描述為什么是“有可能”）。

但是舉個(gè)例子來說，如果網(wǎng)民是北京聯(lián)通的用戶，但他卻偏要使用深圳電信的 LDNS，LDNS 出口也同樣是深圳電信的 IP 地址，那么 GLB 會(huì)誤判網(wǎng)民位于深圳電信，分配給網(wǎng)民的 CDN 服務(wù)器也都是深圳電信的，后續(xù)網(wǎng)民會(huì)從北京聯(lián)通訪問到深圳電信，不但沒加速，可能反而降速了。

如前文所述，由于用戶使用習(xí)慣或一些其他原因，通過 LDNS 調(diào)度有可能是不準(zhǔn)確的，因此又出現(xiàn)了另一種調(diào)度方式，HTTP 302 調(diào)度。

原理很簡單，無論網(wǎng)民最初拿到的 IP 地址是否是正確的，但最終都是要和這個(gè) IP 地址的 CDN 服務(wù)器通信的，因此 CDN 服務(wù)器可以在這時(shí)知道網(wǎng)民的真實(shí)地址（DNS 調(diào)度時(shí)只能間接知道網(wǎng)民地址，雖然 EDNS-Client-Subnet 技術(shù)可以解決問題，但尚未大規(guī)模使用）。

HTTP 協(xié)議中有一個(gè)特殊的返回狀態(tài)：302。在 HTTP 服務(wù)器返回 302 狀態(tài)碼時(shí)，可以攜帶一個(gè)新的 URL（使用的是正確 IP），瀏覽器在拿到 302 返回狀態(tài)碼時(shí)，會(huì)提取其中新的 URL 地址發(fā)起請(qǐng)求，這樣就可以做到重新調(diào)度了。

除了 DNS 調(diào)度、HTTP 302 調(diào)度，還有一種使用 HTTP 進(jìn)行的 DNS 調(diào)度策略。

隨著網(wǎng)絡(luò)日新月異的發(fā)展和演進(jìn)，也逐漸出現(xiàn)了很多鮮為人知的技術(shù)和設(shè)備，例如劫持（具體在后面的篇章里會(huì)多帶帶闡述）。劫持后，網(wǎng)民所訪問的目標(biāo)有可能不再是真實(shí)服務(wù)器，即使是真實(shí)服務(wù)器，內(nèi)容也有可能是虛假的、被替換過的，這對(duì)業(yè)務(wù)安全來說是十分危險(xiǎn)的，這種劫持現(xiàn)象多出現(xiàn)在移動(dòng)互聯(lián)網(wǎng)（手機(jī)上網(wǎng)）。

為了規(guī)避這種問題，出現(xiàn)了一種 HTTP DNS 的調(diào)度方式，原理是通過 HTTP 報(bào)文傳輸 DNS 請(qǐng)求和應(yīng)答信息。但這種方式?jīng)]有任何 RFC 的支持，所以沒有任何現(xiàn)成的操作系統(tǒng)直接支持，必須有自己的 HTTP DNS 客戶端，來與 HTTP DNS 服務(wù)端進(jìn)行通信，需要雙端支持。這種做法在 APP 中使用較多。

在未做 CDN 時(shí)，我們?cè)L問某個(gè)域名，直接拿到的是一個(gè)真實(shí)的服務(wù)器 IP 地址，這個(gè)顯示 IP 地址的 DNS 記錄信息叫 A 記錄，一般是下圖這個(gè)樣子。

當(dāng)業(yè)務(wù)需要接入到 CDN 時(shí)，用戶只需調(diào)整自己的 DNS 配置信息，將 A 記錄改為 CNAME 記錄，將內(nèi)容改為 CDN 廠商所提供的接入域名即可。

由于篇幅的關(guān)系，系列一先把 CDN 的歷史由來，以及調(diào)度相關(guān)的知識(shí)和大家分享。在“系列二”中白金將會(huì)和大家分享 CDN 的緩存及安全。

詳情請(qǐng)閱讀原文