[[423099]]

1. 前言

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

今天和大家聊聊內容分發(fā)網絡的那些事兒，希望大家有所收獲。

2. 為什么需要CDN

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

CDN的全稱是Content Delivery Network，即內容分發(fā)網絡。

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

原來CDN并非網絡基礎設施，而是構建在實體網絡基礎設施之上的一個"應用層"，并且是部署在各地的一個龐大的分布式網絡系統(tǒng)。

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

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

第一公里

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

中間一公里

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

最后一公里

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

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

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

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

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

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

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

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

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

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

2.3 用戶&網站&運營商的共同苦惱

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

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

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

可見，如果沒有CDN這一層Cache應用，網站、用戶、運營商都會很崩潰。

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

3. CDN的基本原理

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

3.1 CDN和DNS的調度

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

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

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

• 有CDN參與的DNS調度過程

前面我們曾經提到CDN是構建在承載網上的一個Cache應用層，也就是CDN作為用戶和網站服務器之間的Cache來參與整個過程。

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

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

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

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

3.2 域名加速和CDN專用調度過程

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

• 網站去CDN服務商進行域名加速

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

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

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

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

由于加速域名已經進行了CDN的CNAME配置，在權威DNS服務器的解析下得到的并不是IP地址而是CNAME，這一步非常關鍵。

• 權威DNS服務器的請求轉發(fā)

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

3.3 httpDNS調度和302調度

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

• httpDNS調度

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

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

• 302調度

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

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

該方式也存在著一些不足：僅限HTTP的應用，可拓展性不足，調度過程多了302跳轉的重定向過程，相對DNS調度時延較長

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

3.4 CDN內部架構簡介

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

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

• 調度系統(tǒng)

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

• 質量系統(tǒng)

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

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

• 緩存系統(tǒng)

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

• 支撐系統(tǒng)

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

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

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

• 靜態(tài)資源

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

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

• 動態(tài)資源

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

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

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

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

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

4.1 Akamai的誕生

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

[[423106]]

Tim Berners Lee教授

在意識到這問題的重大意義后，Tom Leighton教授帶領著研究生 Danny Lewin 和其他幾位頂級研究人員一起嘗試用數學問題解決網絡擁堵問題。

[[423107]]

Tom Leighton教授

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

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

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

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

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

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

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

圖片來自網絡

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

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

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

5.總結

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

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

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

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

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