到底什么是CDN？

如今這個(gè)移動(dòng)互聯(lián)網(wǎng)時(shí)代，越來越多的人使用手機(jī)觀看視頻，豐富自己的娛樂生活。

可是，大家在追劇的時(shí)候，有沒有想過一個(gè)問題——為什么有時(shí)候明明自己的網(wǎng)速很快，但觀看視頻時(shí)，仍然卡頓？

回答這個(gè)問題之前，我們先來做一道算術(shù)題。

以之前很火的“延禧攻略”為例，當(dāng)時(shí)曾經(jīng)在某視頻 APP 實(shí)現(xiàn)了 1 千萬用戶同時(shí)在線觀看。

如果大家觀看的是 1080p 清晰度的視頻（理論上需要 4Mbps 帶寬），那么，累計(jì)需要的流量帶寬是 10,000,000×4Mbps=40,000,000Mbps≈40Tbps。

對(duì)于優(yōu)酷、愛奇藝這樣的互聯(lián)網(wǎng)視頻內(nèi)容提供商來說，這無疑是非常巨大的流量壓力。

我們普通計(jì)算機(jī)的網(wǎng)卡，是 1Gbps 的帶寬。如果是服務(wù)器，現(xiàn)在有 10Gbps 的網(wǎng)卡（萬兆網(wǎng)卡）。

如果優(yōu)酷有一臺(tái)超級(jí)服務(wù)器，那么，這臺(tái)超級(jí)服務(wù)器就需要 4000 塊萬兆網(wǎng)卡，而且必須百分之百跑滿速度，才能夠?qū)崿F(xiàn)這 1 千萬用戶的流暢觀看。

對(duì)于一些實(shí)力不夠的服務(wù)商，或者突發(fā)流量陡增的情況，就會(huì)造成擁塞，從而導(dǎo)致卡頓和延時(shí)。

有這么一個(gè)說法：當(dāng)用戶打開一個(gè)頁面，等待超過 4 秒，他就會(huì)關(guān)閉這個(gè)頁面。也就是說，這個(gè)用戶就會(huì)流失。

這應(yīng)該是大家最討厭的符號(hào)：

用戶的流失，就意味著金錢的流失。沒有任何一家互聯(lián)網(wǎng)服務(wù)提供商希望這樣的情況發(fā)生。所以，它們必須想方設(shè)法讓自己的內(nèi)容盡快呈現(xiàn)，縮短用戶的等待時(shí)間，提升用戶的體驗(yàn)。

而 CDN，就是一項(xiàng)非常有效的縮短時(shí)延的技術(shù)。

CDN 的誕生

上世紀(jì) 80 年代，互聯(lián)網(wǎng)技術(shù)剛剛走入民用領(lǐng)域。

人們主要通過撥號(hào)來訪問網(wǎng)絡(luò)，帶寬很低，用戶也很少，所以，沒有對(duì)骨干網(wǎng)以及服務(wù)器帶來壓力。

隨著互聯(lián)網(wǎng)的爆炸式發(fā)展，用戶越來越多，加上寬帶接入網(wǎng)的出現(xiàn)，內(nèi)容源服務(wù)器和骨干網(wǎng)絡(luò)的壓力越來越大，無法及時(shí)響應(yīng)用戶的訪問需求。

1995 年，麻省理工學(xué)院教授、互聯(lián)網(wǎng)的發(fā)明者之一，Tim Berners-Lee 博士發(fā)現(xiàn)，網(wǎng)絡(luò)擁塞越來越嚴(yán)重，將會(huì)成為互聯(lián)網(wǎng)發(fā)展的最大障礙。

Tim Berners-Lee

于是，他提出一個(gè)學(xué)術(shù)難題，希望有人能發(fā)明一種全新的、從根本上解決問題的方法，來實(shí)現(xiàn)互聯(lián)網(wǎng)內(nèi)容的無擁塞分發(fā)。

當(dāng)時(shí) Tim?Berners-Lee 博士的隔壁，是 Tom Leighton 教授的辦公室。他是一位麻省理工學(xué)院應(yīng)用數(shù)學(xué)教授。

Tom Leighton

他被 Berners-Lee 的挑戰(zhàn)激起了興趣，于是他請(qǐng)研究生 Danny C. Lewin 和其他幾位頂級(jí)研究人員一起破解這個(gè)技術(shù)難題。

Danny C. Lewin

最終，他們開發(fā)了利用數(shù)學(xué)運(yùn)算法則來處理內(nèi)容的動(dòng)態(tài)路由算法技術(shù)，有效地解決了這個(gè)難題。這個(gè)技術(shù)，就是 CDN。

他們還為此專門成立了公司，發(fā)揮其商業(yè)價(jià)值。這個(gè)公司，就是后來鼎鼎大名的 CDN 服務(wù)鼻祖——Akamai 公司。

CDN 的原理

CDN 這個(gè)技術(shù)其實(shí)說起來并不復(fù)雜。它最初的核心理念，就是將內(nèi)容緩存在終端用戶附近。

內(nèi)容源不是遠(yuǎn)么？那么，我們就在靠近用戶的地方，建一個(gè)緩存服務(wù)器，把遠(yuǎn)端的內(nèi)容，復(fù)制一份，放在這里，不就 OK 了？

因?yàn)檫@項(xiàng)技術(shù)是把內(nèi)容進(jìn)行了分發(fā)，所以，它的名字就叫做 CDN——Content Delivery Network，內(nèi)容分發(fā)網(wǎng)絡(luò)。

具體來說，CDN 就是采用更多的緩存服務(wù)器（CDN 邊緣節(jié)點(diǎn)），布放在用戶訪問相對(duì)集中的地區(qū)或網(wǎng)絡(luò)中。當(dāng)用戶訪問網(wǎng)站時(shí)，利用全局負(fù)載技術(shù)，將用戶的訪問指向距離最近的緩存服務(wù)器上，由緩存服務(wù)器響應(yīng)用戶請(qǐng)求。（有點(diǎn)像電商的本地倉(cāng)吧？）

大家可能覺得，這個(gè)不就是“鏡像服務(wù)器”嘛？其實(shí)不一樣。鏡像服務(wù)器是源內(nèi)容服務(wù)器的完整復(fù)制。而 CDN，是部分內(nèi)容的緩存，智能程度更高。

確切地說，CDN=更智能的鏡像+緩存+流量導(dǎo)流。

而且還需要注意的是，CDN 并不是只能緩存視頻內(nèi)容，它還可以對(duì)網(wǎng)站的靜態(tài)資源（例如各類型圖片、html、css、js 等）進(jìn)行分發(fā)，對(duì)移動(dòng)應(yīng)用 APP 的靜態(tài)內(nèi)容（例如安裝包 apk 文件、APP 內(nèi)的圖片視頻等）進(jìn)行分發(fā)。

我們來舉個(gè)例子，看看 CDN 的具體工作流程。

如果某個(gè)用戶想要訪問優(yōu)酷的視頻點(diǎn)播內(nèi)容，那么：

具體步驟：

①、當(dāng)用戶點(diǎn)擊 APP 上的內(nèi)容，APP 會(huì)根據(jù) URL 地址去本地 DNS（域名解析系統(tǒng)）尋求 IP 地址解析。

②、本地 DNS 系統(tǒng)會(huì)將域名的解析權(quán)交給 CDN 專用 DNS 服務(wù)器。

③、CDN 專用 DNS 服務(wù)器，將 CDN 的全局負(fù)載均衡設(shè)備 IP 地址返回用戶。

④、用戶向 CDN 的負(fù)載均衡設(shè)備發(fā)起內(nèi)容 URL 訪問請(qǐng)求。

⑤、CDN 負(fù)載均衡設(shè)備根據(jù)用戶 IP 地址，以及用戶請(qǐng)求的內(nèi)容 URL，選擇一臺(tái)用戶所屬區(qū)域的緩存服務(wù)器。

⑥、負(fù)載均衡設(shè)備告訴用戶這臺(tái)緩存服務(wù)器的 IP 地址，讓用戶向所選擇的緩存服務(wù)器發(fā)起請(qǐng)求。

⑦、用戶向緩存服務(wù)器發(fā)起請(qǐng)求，緩存服務(wù)器響應(yīng)用戶請(qǐng)求，將用戶所需內(nèi)容傳送到用戶終端。

⑧、如果這臺(tái)緩存服務(wù)器上并沒有用戶想要的內(nèi)容，那么這臺(tái)緩存服務(wù)器就要網(wǎng)站的源服務(wù)器請(qǐng)求內(nèi)容。

⑨、源服務(wù)器返回內(nèi)容給緩存服務(wù)器，緩存服務(wù)器發(fā)給用戶，并根據(jù)用戶自定義的緩存策略，判斷要不要把內(nèi)容緩存到緩存服務(wù)器上。

CDN 的好處

采用 CDN 技術(shù)，最大的好處，就是加速了內(nèi)容的訪問——用戶與內(nèi)容之間的物理距離縮短，用戶的等待時(shí)間也得以縮短。

而且，分發(fā)至不同線路的緩存服務(wù)器，也讓跨運(yùn)營(yíng)商之間的訪問得以加速。

例如中國(guó)移動(dòng)手機(jī)用戶訪問中國(guó)電信網(wǎng)絡(luò)的內(nèi)容源，可以通過在中國(guó)移動(dòng)架設(shè) CDN 服務(wù)器，進(jìn)行加速。效果是非常明顯的。

此外，CDN 還有安全方面的好處。內(nèi)容進(jìn)行分發(fā)后，源服務(wù)器的 IP 被隱藏，受到攻擊的概率會(huì)大幅下降。而且，當(dāng)某個(gè)服務(wù)器故障時(shí)，系統(tǒng)會(huì)調(diào)用臨近的健康服務(wù)器?進(jìn)行服務(wù)，避免對(duì)用戶造成影響。

正因?yàn)?CDN 的好處很多，所以，目前所有主流的互聯(lián)網(wǎng)服務(wù)提供商，都采用了 CDN 技術(shù)。所有的云服務(wù)提供商，也都提供了 CDN 服務(wù)（價(jià)格也不算貴，按流量計(jì)費(fèi)）。

某某云的 CDN 服務(wù)

CDN 的弱點(diǎn)

CDN 雖然有很多的優(yōu)點(diǎn)，但它并不是萬能的。在部分場(chǎng)景下，CDN 并不是適用。

首先，CDN 適用于靜態(tài)的內(nèi)容，不適用動(dòng)態(tài)的內(nèi)容。用戶動(dòng)態(tài)的實(shí)時(shí)交互數(shù)據(jù)，是難以緩存的。例如一些頻繁修改的數(shù)據(jù)庫表單內(nèi)容等。（大家可能沒想到，直播其實(shí)也是可以使用 CDN 的。感興趣的同學(xué)可以搜一下“直播 CDN”。）

其次，很多應(yīng)用提供商和內(nèi)容服務(wù)商，為了保護(hù)自身的數(shù)據(jù)私密，不允許第三方公司 CDN 緩存他們的數(shù)據(jù)，只允許自家 CDN 緩存自家的數(shù)據(jù)。這個(gè)對(duì)用戶體驗(yàn)會(huì)造成一定影響。

第三，建設(shè) CDN 意味著不菲的資金投入。不管是自己買服務(wù)器搭建 CDN，還是租用云服務(wù)提供商的 CDN 服務(wù)，都需要花錢。而且，區(qū)域越多，花的錢越多。這些 CDN 到底有沒有人用，利用率是多少，很難精準(zhǔn)預(yù)測(cè)。也許大部分時(shí)間里，利用率很低，就造成了資源浪費(fèi)。

CDN 和通信

CDN 是從傳統(tǒng) IT 行業(yè)發(fā)展起來的一項(xiàng)服務(wù)。但是，對(duì)于我們通信行業(yè)來說，CDN 也有非常大的商業(yè)價(jià)值。

互聯(lián)網(wǎng)服務(wù)提供商采用 CDN，是以存儲(chǔ)換時(shí)延?；ㄥX購(gòu)置 CDN 服務(wù)器或云計(jì)算服務(wù)，以此換取更好的用戶體驗(yàn)。

通信運(yùn)營(yíng)商也追捧 CDN，但它們的目的，是以存儲(chǔ)換帶寬——通過服務(wù)“下沉”，減輕上層骨干網(wǎng)絡(luò)的流量壓力，避免硬件擴(kuò)容，降低網(wǎng)絡(luò)建設(shè)成本。

這個(gè)很好理解啊，如果大量的業(yè)務(wù)流量數(shù)據(jù)在骨干網(wǎng)跑來跑去，骨干網(wǎng)肯定吃不消，要拼命擴(kuò)容。如果這些業(yè)務(wù)流量數(shù)據(jù)在底層就被解決了，那么，骨干網(wǎng)的帶寬壓力自然就減輕了。不是么？

很多運(yùn)營(yíng)商已經(jīng)將 CDN 下沉到地市級(jí)，以此減輕壓力，同時(shí)可以提升用戶體驗(yàn)。

講到這里，廣大通信汪們是不是想到了什么？

沒錯(cuò)，這個(gè)和現(xiàn)在非常熱門的移動(dòng)邊緣計(jì)算，有異曲同工之妙。

一直以來，隨著網(wǎng)絡(luò)能力的不斷提升，內(nèi)容資源和計(jì)算能力都在不斷“往上走”，走到云計(jì)算中心。由一個(gè)核心云計(jì)算中心，對(duì)所有終端節(jié)點(diǎn)提供服務(wù)。

結(jié)果，人們回過頭來發(fā)現(xiàn)，對(duì)于非常大的面積區(qū)域，非常多的用戶數(shù)量，尤其是國(guó)家級(jí)或世界級(jí)的服務(wù)，不管你把這個(gè)中心設(shè)在哪里，也不管你這個(gè)中心的能力有多強(qiáng)大，都無法克服物理距離上的障礙，會(huì)導(dǎo)致無法忍受的延時(shí)和網(wǎng)絡(luò)擁塞。

于是乎，人們就開始把云計(jì)算中心進(jìn)行部分“下沉”，這才有了霧計(jì)算、霾計(jì)算。甚至人們開始質(zhì)疑，集中式計(jì)算是否會(huì)最終被分布式計(jì)算所取代？

區(qū)塊鏈，就是分布式計(jì)算的代表

在小棗君看來，不存在誰完全取代誰的問題。不同的場(chǎng)景帶來不同的需求，不同的需求需要不同的網(wǎng)絡(luò)架構(gòu)。場(chǎng)景的多樣化是現(xiàn)實(shí)存在的，所以，網(wǎng)絡(luò)架構(gòu)的靈活化，也是必然的選擇。

CDN 和邊緣計(jì)算到底是什么關(guān)系呢？

其實(shí)，我個(gè)人認(rèn)為，CDN 可以算是邊緣計(jì)算的一種特殊形式。CDN 主要是存儲(chǔ)能力和少部分計(jì)算能力的下沉，功能較為有限。真正的 MEC 邊緣計(jì)算，能力更強(qiáng)大，功能更全面，更加偏向算力下沉，而非內(nèi)容下沉。

好啦，以上就是關(guān)于 CDN 的介紹，希望對(duì)大家有所幫助！感謝大家的耐心閱讀，我們下期再見！