怎樣分析CDN的由來(lái)與調(diào)度

這篇文章給大家介紹怎樣分析CDN的由來(lái)與調(diào)度，內(nèi)容非常詳細(xì)，感興趣的小伙伴們可以參考借鑒，希望對(duì)大家能有所幫助。

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

下面我們進(jìn)入分享正文：

主要分成 4 個(gè)小部分來(lái)和大家做一下簡(jiǎn)單的介紹和分享。

CDN的起源

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

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

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

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

那什么是 CDN 呢？

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

上圖是一個(gè)做過(guò) CDN 之后的拓?fù)鋱D，里面有幾個(gè)概念需要明確一下:

• Origin Server：源站，也就是做 CDN 之前的客戶(hù)真正的服務(wù)器。

• User：訪問(wèn)者，也就是問(wèn)網(wǎng)站的網(wǎng)民。

• Edge Server：CDN 的服務(wù)器，不單指“邊緣服務(wù)器”，這個(gè)之后細(xì)說(shuō)。

在 CDN 中，還有 3 個(gè)”一英里“的概念，即 First Mile、Middle Mile 和 Last Mile。

• First Mile：和 CDN 客戶(hù)的服務(wù)器越近越好的 CDN 設(shè)備，即第一英里。

• Last Mile：訪問(wèn)者（網(wǎng)民）到離他最近的 CDN 服務(wù)器，即最后一英里。

• Middle Mile：數(shù)據(jù)從進(jìn)入 CDN 網(wǎng)絡(luò)，到出 CDN 網(wǎng)絡(luò)之前的所有環(huán)節(jié)，即中間一英里。

為什么要用 CDN 呢？

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

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

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

接下來(lái)說(shuō)一下調(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ù)器地址，我們稱(chēng)之為”本地 DNS“，也叫 Local DNS，簡(jiǎn)稱(chēng) LDNS。在解析一個(gè)域名的時(shí)候，實(shí)際訪問(wèn)的不是”域名“而是 IP 地址，則 LDNS 服務(wù)器的用途就是負(fù)責(zé)將域名翻譯成 Internet 可以識(shí)別的 IP 地址。

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

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

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

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

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

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

以上圖為例，假如網(wǎng)民是一個(gè)北京聯(lián)通的用戶(hù)，它使用的 LDNS 地址也是北京聯(lián)通的，而 LDNS 訪問(wèn) 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è)問(wèn)題，就是重點(diǎn)標(biāo)注出的“根據(jù)一般人的使用習(xí)慣”。假設(shè)網(wǎng)民所使用的 LDNS 地址和他自己在同一個(gè)區(qū)域，調(diào)度才有可能是準(zhǔn)確的（后續(xù)篇章會(huì)重點(diǎn)描述為什么是“有可能”）。

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

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

原理很簡(jiǎn)單，無(wú)論網(wǎng)民最初拿到的 IP 地址是否是正確的，但最終都是要和這個(gè) IP 地址的 CDN 服務(wù)器通信的，因此 CDN 服務(wù)器可以在這時(shí)知道網(wǎng)民的真實(shí)地址（DNS 調(diào)度時(shí)只能間接知道網(wǎng)民地址，雖然 EDNS-Client-Subnet 技術(shù)可以解決問(wèn)題，但尚未大規(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ì)單獨(dú)闡述）。劫持后，網(wǎng)民所訪問(wèn)的目標(biāo)有可能不再是真實(shí)服務(wù)器，即使是真實(shí)服務(wù)器，內(nèi)容也有可能是虛假的、被替換過(guò)的，這對(duì)業(yè)務(wù)安全來(lái)說(shuō)是十分危險(xiǎn)的，這種劫持現(xiàn)象多出現(xiàn)在移動(dòng)互聯(lián)網(wǎng)（手機(jī)上網(wǎng)）。

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

那 CDN 是如何將用戶(hù)的流量引入到 CDN 網(wǎng)絡(luò)中的呢？

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

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

關(guān)于怎樣分析CDN的由來(lái)與調(diào)度就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，可以學(xué)到更多知識(shí)。如果覺(jué)得文章不錯(cuò)，可以把它分享出去讓更多的人看到。