[[423099]]

1. 前言

大家好，我是所長大白(●—●)。

今天和大家聊聊內(nèi)容分發(fā)網(wǎng)絡(luò)的那些事兒，希望大家有所收獲。

2. 為什么需要CDN

今天的主角是CDN，我們先看下百度百科對CDN的定義：

CDN的全稱是Content Delivery Network，即內(nèi)容分發(fā)網(wǎng)絡(luò)。

CDN是構(gòu)建在現(xiàn)有網(wǎng)絡(luò)基礎(chǔ)之上的智能虛擬網(wǎng)絡(luò)，依靠部署在各地的邊緣服務(wù)器，通過中心平臺的負載均衡、內(nèi)容分發(fā)、調(diào)度等功能模塊，使用戶就近獲取所需內(nèi)容，降低網(wǎng)絡(luò)擁塞，提高用戶訪問響應(yīng)速度和命中率。

原來CDN并非網(wǎng)絡(luò)基礎(chǔ)設(shè)施，而是構(gòu)建在實體網(wǎng)絡(luò)基礎(chǔ)設(shè)施之上的一個"應(yīng)用層"，并且是部署在各地的一個龐大的分布式網(wǎng)絡(luò)系統(tǒng)。

2.1 互聯(lián)網(wǎng)中的三個一公里

互聯(lián)網(wǎng)數(shù)據(jù)傳輸是個復(fù)雜的過程，整體來看可以分為三個一公里，如圖展示了互聯(lián)網(wǎng)數(shù)據(jù)流動的三個主要階段：

第一公里

網(wǎng)站服務(wù)器接入互聯(lián)網(wǎng)公網(wǎng)的鏈路，這里的帶寬也決定了網(wǎng)站的負載能力，也稱為網(wǎng)站的接入帶寬，也就小破站和大站的區(qū)別。

中間一公里

中間一公里主要是接入網(wǎng)、城域網(wǎng)、骨干網(wǎng)組成的鏈路實體，其中會涉及多家運營商，也就出現(xiàn)了運營商之間互聯(lián)互通的數(shù)據(jù)交換問題，是影響比較大的一個環(huán)節(jié)。

最后一公里

這是用戶接入互聯(lián)網(wǎng)獲取信息的最后環(huán)節(jié)，換句話說就是你們小區(qū)的網(wǎng)絡(luò)、你們家樓的網(wǎng)，往往這部分的帶寬不高，高速路很寬很長，可是到你家還是泥土路，也很糟糕。

2.2 運營商的互聯(lián)互通問題

運營商之間數(shù)據(jù)的互聯(lián)互通問題，比如A市聯(lián)通要訪問A市電信的數(shù)據(jù)資源，按照互聯(lián)互通的規(guī)則限制，不同運營商的數(shù)據(jù)要在指定的交換中心進行數(shù)據(jù)交換，假如交換中心位于較遠的B市，那么就存在如下圖的關(guān)系：

換句話說，本來兩個運營商是同一個城市的，但由于運營商的網(wǎng)絡(luò)差異需要到幾百公里之外的交換中心所在的城市進行數(shù)據(jù)交換，實現(xiàn)資源的訪問。

對于不同運營商間的互聯(lián)互通，一般是采用BGP peering對等的方式進行，兩家運營商相互協(xié)商，在特定地點建立連接和交換，從而實現(xiàn)運營商A的用戶對于運營商B的網(wǎng)絡(luò)中資源的訪問。

在中國，運營商之間通過“國家級互聯(lián)網(wǎng)骨干直聯(lián)點”進行連接，2001到2014年國內(nèi)只有北上廣三個直聯(lián)點，導(dǎo)致跨網(wǎng)訪問體驗極差，流量無法本地中轉(zhuǎn)需要長途迂回，大大增加了延遲。

三批國家級互聯(lián)網(wǎng)骨干直聯(lián)點：

第一批2001年投入使用：北京、上海、廣州

第二批2014年投入使用：成都、鄭州、武漢、西安、沈陽、南京、重慶

第三批2017年投入使用：杭州、貴陽、福州

2.3 用戶&網(wǎng)站&運營商的共同苦惱

試想北美的海外用戶要訪問在服務(wù)器在深圳的資源，物理距離就有幾萬公里，算上三個一公里的消耗，恐怕用戶的體驗會非常糟糕。

同樣的，網(wǎng)站服務(wù)器的接入帶寬是有限的，對于海量用戶的接入訪問非常容易出現(xiàn)擁塞，這樣很容易把網(wǎng)站服務(wù)器壓垮。

同時，對于運營商來說也很糟糕，骨干網(wǎng)充斥著大量相同的請求，網(wǎng)絡(luò)基建壓力很大，如果把這些請求在本地處理掉該多好!

可見，如果沒有CDN這一層Cache應(yīng)用，網(wǎng)站、用戶、運營商都會很崩潰。

CDN的思想和電商物流建立的區(qū)域倉庫、前置倉庫很像，用戶下單后優(yōu)先在最近的倉庫配貨，極限情況下幾小時就可以送到用戶手里，用戶體驗好、物流壓力小。

3. CDN的基本原理

CDN是個非常復(fù)雜的大系統(tǒng)，作為普通的開發(fā)人員，我們抓住重點理解精髓就好。

3.1 CDN和DNS的調(diào)度

我們訪問資源時會使用DNS進行解析獲取資源服務(wù)器的IP地址進行數(shù)據(jù)交互，那么在使用CDN之后會發(fā)生什么變化呢?

• 傳統(tǒng)模式下DNS的調(diào)度過程

圖中我們看到用戶從LocalDNS開始查詢，如果找不到就到根權(quán)威DNS服務(wù)器，再向頂級權(quán)威DNS服務(wù)器訪問，依次迭代最終獲取待訪問域名的IP地址。

• 有CDN參與的DNS調(diào)度過程

前面我們曾經(jīng)提到CDN是構(gòu)建在承載網(wǎng)上的一個Cache應(yīng)用層，也就是CDN作為用戶和網(wǎng)站服務(wù)器之間的Cache來參與整個過程。

這樣就出現(xiàn)一個問題：用戶如何獲取CDN資源節(jié)點的IP地址呢?

沒錯，其中一種常見的調(diào)度方案就是DNS調(diào)度，如圖所示：

前半部分和傳統(tǒng)模式類似，重要的區(qū)別在于專用DNS調(diào)度服務(wù)器的出現(xiàn)。

就是圖中的TenCent DNS Server，這臺專用DNS調(diào)度服務(wù)器根據(jù)CDN系統(tǒng)內(nèi)部節(jié)點的位置、負載情況、資源分配等因素選出最優(yōu)的CDN資源節(jié)點IP地址返回給用戶。

3.2 域名加速和CDN專用調(diào)度過程

要實現(xiàn)CDN資源節(jié)點的調(diào)度，需要網(wǎng)站做一些準備工作：

• 網(wǎng)站去CDN服務(wù)商進行域名加速

比如為源站abc.com到阿里云進行域名加速，配置完成后阿里云會自動關(guān)聯(lián)生成加速域名的別名如abc.com.aliyuncdn.net，這個別名也稱為CNAME。

這里我們提兩個重要的概念:CNAME和A記錄，它們是理解CDN的基礎(chǔ)概念。

CNAME記錄，也叫別名記錄，比如www.xx.com的別名是www.yy.com，CNAME記錄是一種指向關(guān)系，把www.yy.com指向了www.xx.com，一個域名可以有多個別名，存在多對一的關(guān)系。

A記錄，即Address記錄，我們可以把它理解為一種域名和IP地址的映射關(guān)系，比如www.abc.com對應(yīng)的IP地址是1.1.1.1。

由于加速域名已經(jīng)進行了CDN的CNAME配置，在權(quán)威DNS服務(wù)器的解析下得到的并不是IP地址而是CNAME，這一步非常關(guān)鍵。

• 權(quán)威DNS服務(wù)器的請求轉(zhuǎn)發(fā)

當(dāng)用戶訪問abc.com時，傳統(tǒng)的權(quán)威DNS服務(wù)器對abc.com進行解析時得到的是abc.com.aliyuncdn.net這個配置的CNAME，從而通過CNAME順利將請求轉(zhuǎn)到CDN服務(wù)商專用的DNS服務(wù)器，由該服務(wù)器返回CDN的資源節(jié)點。

3.3 httpDNS調(diào)度和302調(diào)度

除了DNS調(diào)度，還有httpDNS調(diào)度、302調(diào)度等場景，來簡單看一下。

• httpDNS調(diào)度

HTTPDNS技術(shù)是一種針對DNS防劫持的有效手段，以HTTP的方式代替?zhèn)鹘y(tǒng)DNS協(xié)議傳遞解析結(jié)果，能夠有效避開DNS層面的攔截和故障。該方案可以根據(jù)客戶端的來訪IP，直接通過Httpdns服務(wù)器獲取最精準的解析結(jié)果，避免因為DNS多出口，DNS攻擊導(dǎo)致的DNS解析失敗的問題。

客戶端直接調(diào)用HttpDNS接口獲取緩存服務(wù)器IP組，再擇優(yōu)向IP組中的緩存服務(wù)器發(fā)送請求，替代常規(guī)DNS調(diào)度策略，適用于客戶端，且客戶端需稍作修改進行HttpDNS接口調(diào)用。

• 302調(diào)度

基于終端用戶的IP，做HTTP的精確重定向，需要協(xié)議支持、具有相當(dāng)?shù)臅r延，一般用于流媒體類加速場景。

該調(diào)度方式是通過DNS解析獲得CDN的GLSB集群的IP地址，用戶發(fā)送HTTP請求，GLSB服務(wù)器返回302 Found，將訪問重定向到合適的服務(wù)節(jié)點。

該方式也存在著一些不足：僅限HTTP的應(yīng)用，可拓展性不足，調(diào)度過程多了302跳轉(zhuǎn)的重定向過程，相對DNS調(diào)度時延較長

httpsDNS和302調(diào)度都有自己的優(yōu)勢和使用場景，不同的網(wǎng)站可以采用一種或者多種調(diào)度方案來綜合實施加速，三種方案并不對立，而是相互補充。

3.4 CDN內(nèi)部架構(gòu)簡介

有了CDN的加速，用戶就可以訪問近距離的服務(wù)器節(jié)點，大大提升了用戶體驗，同時源站的帶寬壓力也得到了分流，運營商骨干網(wǎng)壓力也隨之降低，看起來確實是個win-win-win的方案呀。

我們以阿里云官方文檔為藍本進行展開：

• 調(diào)度系統(tǒng)

支持DNS、HTTPDNS和302調(diào)度模式，當(dāng)終端用戶發(fā)起訪問請求時，用戶的訪問請求會先進行域名DNS解析，然后通過CDN的調(diào)度系統(tǒng)處理用戶的解析請求，就是我們前面介紹的CDN參與下的DNS調(diào)度過程。

• 質(zhì)量系統(tǒng)

實時監(jiān)測緩存系統(tǒng)中的所有節(jié)點和鏈路的實時負載以及健康狀況，根據(jù)用戶請求中攜帶的IP地址解析用戶的運營商和區(qū)域歸屬，綜合鏈路質(zhì)量信息為用戶分配一個最佳接入節(jié)點。

這里算是進行CDN節(jié)點選擇的一個策略和質(zhì)量監(jiān)控的閉環(huán)系統(tǒng)。

• 緩存系統(tǒng)

用戶在最佳接入節(jié)點訪問數(shù)據(jù)，如果節(jié)點已經(jīng)緩存了資源，會直接將資源返回給用戶，如果L1和L2節(jié)點都沒有緩存請求的資源，此時回源站去獲取資源并存儲到緩存系統(tǒng)。

• 支撐系統(tǒng)

支撐服務(wù)系統(tǒng)包括數(shù)據(jù)智能和配置管理系統(tǒng)，實現(xiàn)資源監(jiān)測和數(shù)據(jù)分析，例如對CDN加速域名的QPS、帶寬、HTTP狀態(tài)碼、PV、UV等數(shù)據(jù)進行監(jiān)控。

3.5 靜態(tài)資源和動態(tài)資源的加速

CDN本質(zhì)上就是一層Cache，有緩存就一定會有數(shù)據(jù)不一致問題，以及哪些資源適合做緩存，哪些不適合的問題。

• 靜態(tài)資源

如果每個用戶訪問得到的資源一樣，就像電視臺播放節(jié)目，大家看到的都一樣，并非個性化的結(jié)果，這類資源就可以稱為靜態(tài)資源，比如網(wǎng)站的圖片、視頻、軟件安裝包等。

這些資源變化很小，因此非常使用CDN加速，對改善網(wǎng)站性能效果明顯。

• 動態(tài)資源

區(qū)別于靜態(tài)資源，動態(tài)資源則更傾向于接口、個性化內(nèi)容，用戶每次請求得到的結(jié)果可能不同，這些資源并不適合CDN場景，如果強行使用會帶來數(shù)據(jù)更新緩慢和不一致問題，但是動態(tài)資源有其特有的加速方法。

動態(tài)資源就意味著回源站進行數(shù)據(jù)請求，這其中就涉及到最優(yōu)回源路徑的選擇，讓路更好走，數(shù)據(jù)獲取更快捷，實現(xiàn)動態(tài)資源的加速。

所以CDN也并非萬金油，我們要合理使用。

4. CDN的商業(yè)簡史

鏡頭拉回到20世紀90年代，當(dāng)時全球范圍內(nèi)網(wǎng)絡(luò)基礎(chǔ)設(shè)施還很薄弱，尤其在骨干網(wǎng)接入用戶越來越多，數(shù)據(jù)的長距離傳輸效果很差，已經(jīng)阻礙了新興網(wǎng)絡(luò)科學(xué)的發(fā)展。

4.1 Akamai的誕生

這個現(xiàn)象很快被萬維網(wǎng)的發(fā)明人Tim Berners Lee注意并提出來，隨后他和麻省理工學(xué)院應(yīng)用數(shù)學(xué)專家 Tom Leighton 教授討論該問題。

[[423106]]

Tim Berners Lee教授

在意識到這問題的重大意義后，Tom Leighton教授帶領(lǐng)著研究生 Danny Lewin 和其他幾位頂級研究人員一起嘗試用數(shù)學(xué)問題解決網(wǎng)絡(luò)擁堵問題。

[[423107]]

Tom Leighton教授

最終他們使用數(shù)學(xué)算法，處理內(nèi)容的動態(tài)路由安排，解決了這個難題。

故事還沒有完，史隆管理學(xué)院的 MBA 學(xué)生 Jonathan Seelig 加入了 Leighton 的隊伍中，為這支技術(shù)隊伍插上了商業(yè)的翅膀，最終于 1998 年 8 月 20 日正式成立公司，命名為 Akamai。

時至今日，Akamai仍然是一家承載全球15%-30%網(wǎng)絡(luò)流量，客戶涉及谷歌、臉書、微軟等知名互聯(lián)網(wǎng)公司。

Akamai在全球部署150000多臺服務(wù)器，這些服務(wù)器部署在全球90多個國家，800多個城市，1000多個運營商的2500多個節(jié)點上。

4.2 CDN在中國的發(fā)展

和Akamai同一年誕生的還有中國第一家CDN公司藍汛ChinaCache。

隨著互聯(lián)網(wǎng)的發(fā)展，后續(xù)又出現(xiàn)了網(wǎng)宿科技、帝聯(lián)、快網(wǎng)等公司，在2014年之后各大互聯(lián)網(wǎng)公司紛紛推出了自己的云服務(wù)，其中佼佼者便是阿里云、騰訊云、金山云、七牛云等云服務(wù)商CDN公司。

圖片來自網(wǎng)絡(luò)

其中阿里云目前在國內(nèi)市場份額第一，大約覆蓋了1/3的市場需求。

阿里云在全球擁有2800+節(jié)點。中國內(nèi)地擁有2300+節(jié)點，覆蓋31個省級區(qū)域;海外、中國香港、中國澳門和中國臺灣擁有500+節(jié)點，覆蓋70多個國家和地區(qū)。全網(wǎng)帶寬輸出能力達150 Tbps。

目前在用戶需求、技術(shù)革新、市場競爭等多因素影響下，各大CDN服務(wù)商都開始進行轉(zhuǎn)型和技術(shù)優(yōu)化，給用戶更好的體驗、更安全、更靈活的產(chǎn)品方案，前景廣闊發(fā)展迅猛。

5.總結(jié)

本文通過介紹CDN的定義和功能、互聯(lián)網(wǎng)三個一公里的數(shù)據(jù)流動等問題，讓我們對CDN要解決什么問題及其重要意義有了初步認識。

進一步，通過傳統(tǒng)DNS調(diào)度和使用CDN加速后的調(diào)度過程，闡述了CDN資源節(jié)點是如何被用戶端感知的。

同時以阿里云為藍本介紹了CDN網(wǎng)絡(luò)架構(gòu)的基本組成部分，以及靜態(tài)資源和動態(tài)資源不同的加速方式。

最后從商業(yè)的角度介紹了互聯(lián)網(wǎng)之父提出的長距離傳輸帶來的網(wǎng)絡(luò)擁塞問題、麻省理工教授創(chuàng)辦第一家CDN公司、再到中國CDN的發(fā)展情況。

CDN是個復(fù)雜的工程，文章篇幅和筆者能力所限，只能和大家分享這么多了，希望對朋友們有所幫助，我們下期再見!