給大家分享下關(guān)于CDN的東西，總共分為 2個(gè)大部分：原理、詳解。

首先說一下 CDN 的基本原理部分，主要分 4 塊來描述：CDN 的由來、調(diào)度是怎么做的、緩存是什么、關(guān)于安全。

什么是CDN?

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

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

User: 訪問者，也就是要訪問網(wǎng)站的網(wǎng)民;

Edge Server: CDN 的服務(wù)器，不單只“邊緣服務(wù)器”，這個(gè)之后細(xì)說;s/(單)只/
指/;

Last Mile: 最后一公里，也就是網(wǎng)民到他所訪問到的 CDN 服務(wù)器之間的路徑。

我們平時(shí)所使用的DNS服務(wù)器，一般稱之為L(zhǎng)DNS，在解析一個(gè)域名的時(shí)候，一般有兩個(gè)情況，一種是域名在DNS上有記錄，另一種情況是沒有記錄，兩種情況的處理流程不一樣。

當(dāng)你訪問163這個(gè)域名時(shí)，如果LDNS上有緩存記錄，那它會(huì)直接將IP地址直接給你。如果沒有緩存記錄，它將會(huì)一步步向后面的服務(wù)器做請(qǐng)求，然后將所有數(shù)據(jù)進(jìn)行匯總交給最終的客戶。

當(dāng)你訪問163這個(gè)地址時(shí)，實(shí)際上如果本身沒有內(nèi)容的話，它要去后面拿數(shù)據(jù)，這個(gè)過程術(shù)語叫遞歸，它首先會(huì)向全球13個(gè)根域服務(wù)器請(qǐng)求，問com域名在哪，然后根域服務(wù)器作出回答，一步步往下，這個(gè)過程較復(fù)雜，如果大家感興趣可去查相關(guān)資料，在這就不一一贅述。

DNS調(diào)度

肯定很多人好奇是如何進(jìn)行調(diào)度和進(jìn)行定位的?

其實(shí)也是通過LDNS的具體地址來進(jìn)行的，比如，看圖，假設(shè)你是一個(gè)廣東電信客戶，那你所使用的DNS服務(wù)器去做遞歸的時(shí)會(huì)訪問到某一個(gè)CDN廠商的GRB，全球的一個(gè)調(diào)度系統(tǒng),他就能看到來自于哪個(gè)LDNS。假設(shè)如果用戶和LDNS使用同一個(gè)區(qū)域的服務(wù)器，他就會(huì)間接認(rèn)為用戶也是廣東電信的。

再舉個(gè)例子，比如說北京聯(lián)通的用戶，它使用DNS地址，一般自動(dòng)給它分配的是北京聯(lián)通的服務(wù)器，這個(gè)服務(wù)器去做遞歸的時(shí)候，調(diào)度服務(wù)器就會(huì)看到這個(gè)請(qǐng)求是來自北京聯(lián)通的LDNS服務(wù)器，就會(huì)給它分配一個(gè)北京聯(lián)通的服務(wù)器地址，然后讓來自北京聯(lián)通的用戶直接訪問北京聯(lián)通的服務(wù)器地址，這樣來實(shí)現(xiàn)精準(zhǔn)的區(qū)域性調(diào)度。

從這個(gè)調(diào)度理論上看，我們可以發(fā)現(xiàn)一個(gè)問題，就是假設(shè)用戶所使用的LDNS地址和你是同一個(gè)區(qū)域，那么這個(gè)時(shí)候我們的調(diào)度才有可能是正確的。但是舉個(gè)例子來說，如果你是北京聯(lián)通的用戶，可是使用的是廣東電信的LDNS的話，就會(huì)讓GRB系統(tǒng)誤以為你是廣東電信的客戶，這樣就會(huì)錯(cuò)誤的調(diào)度過去。

之前有一次我在小區(qū)里上網(wǎng)，由于我的路由器有問題，我設(shè)了202.106.0.20的北京聯(lián)通的DNS服務(wù)器地址，后來出差去深圳，訪問比較大的網(wǎng)站發(fā)現(xiàn)比較慢，經(jīng)過分析，才發(fā)現(xiàn)原來我設(shè)的DNS地址是北京聯(lián)通的，而我在廣東和深圳使用的網(wǎng)絡(luò)都是電信接入的，但是分配給我的是北京聯(lián)通的地址，那我用電信的線路訪問北京聯(lián)通的地址，勢(shì)必就會(huì)很慢。

因?yàn)閯偛胖v到的DNS調(diào)度機(jī)制存在一定問題，所以在某些場(chǎng)合下我們會(huì)使用第二種調(diào)度機(jī)制，叫HTTP的調(diào)度。

了解http協(xié)議的人知道，在http協(xié)議中有一個(gè)叫302跳轉(zhuǎn)的功能，它的實(shí)現(xiàn)并不是說你訪問一個(gè)URL，然后馬上吐給你想要的數(shù)據(jù)，而是吐給你一個(gè)302返回信令，這個(gè)信令頭部會(huì)告訴你，有一個(gè)location目標(biāo)，這個(gè)location就是告訴你下一步將要怎么做，而具體調(diào)度是通過location來實(shí)現(xiàn)的。

即便我所使用的DNS和我不在一個(gè)區(qū)域，但當(dāng)我訪問http server的時(shí)，這個(gè)server是由CDN公司提供的?？蛻粼L問server的時(shí)，雖說通過DNS方式無法拿到客戶的真正IP地址，但是如果你訪問的是http server，他一定能直接看到客戶的真實(shí)IP，利用這種方法可以進(jìn)行調(diào)度的糾偏，可以直接返回給你一個(gè)302，然后location里面攜帶一個(gè)真正離你最近的CDN server。

這種調(diào)度方式，優(yōu)勢(shì)是準(zhǔn)確，但是也存在弊端，它需要有一次TCP的三次握手建連，他不像DNS那樣直接請(qǐng)求一個(gè)數(shù)據(jù)包過去給一個(gè)反饋就OK了，他需要一次TCP的三次握手建連。

第二個(gè)是你如何訪問到http的服務(wù)器?如果你之前是通過DNS調(diào)度過去的，實(shí)際上前邊的那個(gè)DNS也是省不了，在國(guó)內(nèi)是沒有辦法做anycast的，也就是沒有辦法來直接訪問一個(gè)眾所周知的大的IP來進(jìn)行，所以，一般情況下都是通過DNS來進(jìn)行第一次調(diào)度，然后用http來進(jìn)行第二次糾偏。這種情況下大家可以想象，如果你下載一個(gè)大文件，比如說電影，但你訪問的是一個(gè)頁面小元素，比如說這個(gè)圖片只有幾k，那么，實(shí)際上你調(diào)度的時(shí)間就已占用了很大的成分。實(shí)際上，這種302調(diào)度是一種磨刀不誤砍柴工的方案，如果你后面有很多工作要做，比如要下載一個(gè)電影時(shí)間會(huì)很長(zhǎng)，那你調(diào)度準(zhǔn)確，即使花一點(diǎn)時(shí)間調(diào)度也是值得的。但是如果你后續(xù)訪問一下就完了，那么你這樣調(diào)度就沒有太大意義。

除了DNS調(diào)度和http的302調(diào)度以外，其實(shí)還有一種調(diào)度方式，叫http DNS調(diào)度，它的原理是通過一個(gè)正常的http請(qǐng)求，發(fā)一個(gè)get的請(qǐng)求，然后再請(qǐng)求里面以參數(shù)的形式攜帶一個(gè)我要解析的域名，然后服務(wù)器那邊去通過數(shù)據(jù)庫查詢，查詢之后又通過http的正常響應(yīng)，把這個(gè)你要請(qǐng)求的IP通過http協(xié)議給你，這種協(xié)議有一個(gè)特點(diǎn)就是必須雙端都支持，因?yàn)檫@種模式是非標(biāo)準(zhǔn)的。沒有任何一個(gè)RFC文檔說，你的客戶端或者你的操作系統(tǒng)天生就支持這種機(jī)制。這有點(diǎn)類似是一種API的這種方式，那如果要實(shí)現(xiàn)的話就必須雙端都支持。

一般，第三種調(diào)度的應(yīng)用場(chǎng)景是在手機(jī)的APP端，在APP軟件里面，你要訪問某些東西很有可能被運(yùn)營(yíng)商劫持等問題，這個(gè)劫持問題后面還有很大的篇幅去講。那為了避免這種劫持，可能會(huì)用到這種http DNS的調(diào)度方式。既然APP的程序都是你自己寫的，所以說實(shí)現(xiàn)這么簡(jiǎn)單一個(gè)API的借口是很容易的。

CDN的接入

可能會(huì)有人問，你講了這么多DNS和具體CDN的調(diào)度有什么關(guān)系呢?

因?yàn)樵谥v你獲得一個(gè)具體的DNS域名地址的時(shí)，他給你的就是一個(gè)IP地址。那在沒有CDN之前，他給你的IP地址就是在原來沒做CDN時(shí)的原始服務(wù)器地址。但如果你做過CDN的話，你會(huì)發(fā)現(xiàn)最終拿到的這個(gè)IP地址是CDN的節(jié)點(diǎn)，而并不是真正的原始服務(wù)器。

我們通常說的拿到一個(gè)IP地址，這實(shí)際上是DNS的A記錄。DNS里面有很多不同的記錄，比如像A記錄負(fù)責(zé)給你一個(gè)IP地址;比如像CNAME記錄給你的是一個(gè)域名的別名。當(dāng)然還有很多其他記錄，比如TXT的記錄、MX記錄等等。這個(gè)跟CDN無關(guān)，這里就不細(xì)說了，有興趣去查一下DNS相關(guān)的文檔。

上圖就是一個(gè)很明顯的CDN介入后的效果圖。linux里有一個(gè)命令叫dig，它可直接把要訪問域名的具體的解析情況列出來。那么，通過這個(gè)圖可看出，當(dāng)你要訪問www.163.com時(shí)，他最終雖給出的是一個(gè)IP地址，但實(shí)際上，它經(jīng)過了兩次CNAME記錄。第一次CNAEM記錄就是我們之前說得CDN的GRB，他拿到了這個(gè)數(shù)據(jù)，就可以間接知道你的這個(gè)LOCODNS是從哪里來的，然后間接給你進(jìn)行一個(gè)定位。以這個(gè)圖為例，他實(shí)際上第一跳是跳到網(wǎng)速地址，第二跳是分配了網(wǎng)速的一個(gè)平臺(tái)，這個(gè)平臺(tái)又分開其他的IP給最終的客戶。

Cache系統(tǒng)——緩存系統(tǒng)

除DNS調(diào)度以外，在CDN里還有一個(gè)非常大的重頭戲就是Cache系統(tǒng),也就是緩存系統(tǒng)。它用于把那些可以緩存住的東西，緩存到CDN的邊緣節(jié)點(diǎn)，這樣當(dāng)?shù)诙€(gè)人去訪問同一節(jié)點(diǎn)，同一具體電影或MP3時(shí)就不用再經(jīng)過CDN鏈路回到真正的源站去拿數(shù)據(jù)，而是由邊緣節(jié)點(diǎn)直接給數(shù)據(jù)。

在Cache系統(tǒng)里囊括了很多的技術(shù)，比如，用空間換時(shí)間的這種高效的數(shù)據(jù)結(jié)構(gòu)和算法，多級(jí)緩存以熱度來區(qū)分，前端是SSD后面是機(jī)械硬盤等等。很多的細(xì)節(jié)就不說了，如感興趣的可之后交流。

對(duì)于Cache系統(tǒng)來說，有兩種不同的工作狀態(tài)。第一種工作狀態(tài)就是所謂的命中(hit)，第二種就是沒有命中(miss)。如果命中了，直接通過檢索找到磁盤或內(nèi)存上的數(shù)據(jù)，把這個(gè)數(shù)據(jù)直接吐給客戶，而不是從后面去拿數(shù)據(jù)。這樣的話就起到一個(gè)很完美的加速效果。

第二種是在miss時(shí)，其實(shí)，miss的時(shí)候跟hit唯一的區(qū)別就是，當(dāng)我發(fā)現(xiàn)我的本機(jī)上沒有這個(gè)資源，我會(huì)去我的upstream(上游)去拿數(shù)據(jù)。拿完這個(gè)數(shù)據(jù)，除了第一時(shí)間給客戶，同時(shí)還會(huì)在硬盤上緩存一份。如果這個(gè)硬盤空間滿了，會(huì)通過一系列置換方法，把最老的數(shù)據(jù)、最冷的數(shù)據(jù)替換出去。

提到了upstream，不是原始服務(wù)器，原因是因?yàn)楫?dāng)客戶訪問到CDN節(jié)點(diǎn)的時(shí)，他發(fā)現(xiàn)上面沒有數(shù)據(jù)，并不是直接從原始服務(wù)器上去拿，而是經(jīng)過他的另一個(gè)CDN節(jié)點(diǎn)，然后通過middlemell的方式去進(jìn)行一些數(shù)據(jù)傳輸。然后upstream這一層，從原始服務(wù)器拿數(shù)據(jù)，通過一系列的加速手段，快速的把數(shù)據(jù)投遞給我們的邊緣節(jié)點(diǎn)，再把這個(gè)數(shù)據(jù)給最終客戶。在過程當(dāng)中upstream和downstream這兩層都會(huì)把數(shù)據(jù)緩存一份。通過這種樹形結(jié)構(gòu)，比如說多個(gè)邊緣節(jié)點(diǎn)，然后匯總到一個(gè)或者幾個(gè)副層結(jié)點(diǎn)，這樣的話可以逐漸的實(shí)現(xiàn)流量的收斂。

提到Cache的具體技術(shù)，我相信這里的很多朋友都是同行業(yè)的，有人會(huì)說其實(shí)這沒有什么難的，你只要有網(wǎng)絡(luò)、有運(yùn)維人員就可以了。其實(shí)我并不這樣認(rèn)為，因?yàn)槟闳绻氚阉龊玫脑捚鋵?shí)很難，比如，我列出的很多技術(shù)你有沒有在考慮?

舉幾個(gè)例子來說，你有沒有做網(wǎng)卡的的多隊(duì)列和CPU的親和性綁定?你有沒有做磁盤的調(diào)度算法改進(jìn)?另外，你存儲(chǔ)的時(shí)候還是用還是?等等都是有講究的。包括內(nèi)核的調(diào)優(yōu)包括架構(gòu)和CPU的綁定，CPU的多級(jí)緩存的使用，然后你的處理你使用，還是用標(biāo)準(zhǔn)的的這種機(jī)制。再比如說編譯的程序時(shí)使用的去編譯還是用英特爾的，然后你再做很多的調(diào)用。比如說一個(gè)很簡(jiǎn)單的字符串拷貝，那你是用，你還是用匯編去寫，你還是用什么方式等等很多細(xì)節(jié)。

關(guān)于高性能這一塊，還有很多的研究，如大家感興趣的話，可以之后跟我進(jìn)行進(jìn)一步的溝通。我想表達(dá)的一個(gè)觀點(diǎn)就是說，看上去做CDN很簡(jiǎn)單，入門確實(shí)也簡(jiǎn)單，但是要真正想做好很難。

安全問題

在沒有做CDN之前你的網(wǎng)站很有可能會(huì)遭受到各種各樣的攻擊。那么攻擊一般分成兩種,第一種叫蠻力型攻擊，量大的讓你的帶寬無法抗住最后導(dǎo)致拒絕服務(wù)，另外一種是技巧性攻擊。

作為CDN來講，就已經(jīng)將你的原始服務(wù)器的IP進(jìn)行了隱藏。這樣當(dāng)一個(gè)攻擊者去訪問你的域名的時(shí)，實(shí)際上訪問的并不是你真正的服務(wù)器。當(dāng)他訪問的是CDN的節(jié)點(diǎn)，就沒有辦法把CDN的節(jié)點(diǎn)打倒，換句話說，即使有能力把CDN的比如10g的節(jié)點(diǎn)或者是40g的大節(jié)點(diǎn)全部打倒，但由于CDN天然的分布式的部署方式，他也很難在同一時(shí)間之內(nèi)迅速的把全國(guó)所有CDN的邊緣節(jié)點(diǎn)全都打癱。

另外，還有一種攻擊是針對(duì)你的DNS地址的。如果你的GRB癱了的話，會(huì)導(dǎo)致整個(gè)調(diào)度系統(tǒng)失靈。如果調(diào)動(dòng)系統(tǒng)失靈，即使你的CDN的Cache server還是能夠正常接受請(qǐng)求，但由于流量調(diào)度不了。因此，你需要在DNS層做很多防護(hù)機(jī)制，比如說用高性能的DNS或用分布式的部署方式等等。

技巧型攻擊不需要很大的流量，就可以把你的原針打倒或是讓你的網(wǎng)頁出現(xiàn)錯(cuò)誤的情況。比如說，像注入、掛馬甚至說更嚴(yán)重的會(huì)直接拖走你的數(shù)據(jù)庫等等。那么作為CDN來說，有很多廠商實(shí)際上已經(jīng)開始具備這樣的技巧性的防護(hù)能力了，比如說WAF(Web Application Fierwall),就是應(yīng)用層防火墻，他可以直接去解析你的請(qǐng)求內(nèi)容，分析內(nèi)容是否有惡意性，如有惡意性的話去進(jìn)行過濾，報(bào)警等一系列措施來保證你的原始服務(wù)器的安全。

第二部分主要是針對(duì)網(wǎng)絡(luò)層的優(yōu)化、架構(gòu)的優(yōu)化、Cache的選型還有性能分析等等幾個(gè)方面，對(duì)整個(gè)CDN的基礎(chǔ)原理作很深入地剖析。

原始的CDN其實(shí)是Content Delivery Network這三個(gè)詞的縮寫，也就是內(nèi)容分發(fā)網(wǎng)絡(luò)。但我認(rèn)為應(yīng)該是can do something on Network。CDN的理念是加速，所以，我們就盡一切可能去做各種優(yōu)化，從一層到七層的優(yōu)化來實(shí)現(xiàn)最終的優(yōu)化效果。

為什么說一層是優(yōu)化，實(shí)際上也是硬件，你的服務(wù)器選型就是一種優(yōu)化。你是用ssd，還是用saker硬盤，你是該用pce卡，還是應(yīng)該用ssd。你的CPU應(yīng)該用至強(qiáng)還是應(yīng)該用阿童木的等等，都是需要去斟酌。

至于二層，鏈路層的優(yōu)化指的就是資源方面。比如機(jī)房如何去選擇。

三層路由層是指你在middlemell這塊真正選路的具體的細(xì)節(jié)，后面會(huì)有一個(gè)圖來具體講一下。

四層是指?jìng)鬏攲拥膬?yōu)化，我們一般的業(yè)務(wù)全都是TCP，所以說這里面就可以明確的說這里是指TCP的優(yōu)化。還有一個(gè)就是七層也是可以優(yōu)化的。比如說你強(qiáng)行對(duì)內(nèi)容進(jìn)行壓縮，甚至你改變壓縮級(jí)別去壓縮。

作為CDN來說，基本上我羅列了一下可能會(huì)用到的一些技術(shù)，大概10個(gè)。比如說就近分布、策略性的緩存、傳輸?shù)膬?yōu)化、鏈路層的優(yōu)化、包括內(nèi)容的預(yù)取、合并回源。然后持久連接池、主動(dòng)壓縮，還有當(dāng)你原始服務(wù)器掛了的話你怎么樣能夠保證讓客戶看到數(shù)據(jù)等很多的細(xì)節(jié)。

路徑的優(yōu)化，實(shí)際上，我們可以把它抽象成是一個(gè)求最短路徑最優(yōu)解的思路去解決真實(shí)的問題。當(dāng)你從a點(diǎn)到b點(diǎn)需要傳輸數(shù)據(jù)的時(shí)，往往會(huì)經(jīng)過一個(gè)c點(diǎn)，比直接從a到b更快。在互聯(lián)網(wǎng)里有個(gè)三角原理，和地理位置的原理有一定區(qū)別的。雖說有一定的相關(guān)性，但還是有區(qū)別的，有可能從a經(jīng)過c到b會(huì)比a直接到b更快。

在數(shù)據(jù)傳輸?shù)臅r(shí)，需要去考慮很多綜合因素，目前為止，包括阿克麥也很難做到完全系統(tǒng)自動(dòng)化去做鏈路選擇和切換。在調(diào)度的時(shí)，很多公司都有專門的團(tuán)隊(duì)管流量調(diào)度的。很多的系統(tǒng)可能只起到支撐和參考的作用，而真正需要決策的還是人。因?yàn)槟阈枰紤]的元素太多了，比如說要考慮你的帶寬成本、帶寬節(jié)點(diǎn)冗余量、服務(wù)器承載能力，要考慮你的客戶敏感度哪些該切哪些不該切等很多細(xì)節(jié)。

傳輸層的優(yōu)化剛才講到了是TCP優(yōu)化，在現(xiàn)今的互聯(lián)網(wǎng)里，TCP優(yōu)化是可以帶來最直接客戶體驗(yàn)感的一種實(shí)現(xiàn)方式。

河南億恩科技股份有限公司(xuefeilisp.com)始創(chuàng)于2000年，專注服務(wù)器托管租用，是國(guó)家工信部認(rèn)定的綜合電信服務(wù)運(yùn)營(yíng)商。億恩為近五十萬的用戶提供服務(wù)器托管、服務(wù)器租用、機(jī)柜租用、云服務(wù)器、網(wǎng)站建設(shè)、網(wǎng)站托管等網(wǎng)絡(luò)基礎(chǔ)服務(wù)，另有網(wǎng)總管、名片俠網(wǎng)絡(luò)推廣服務(wù)，使得客戶不斷的獲得更大的收益。
服務(wù)器/云主機(jī) 24小時(shí)售后服務(wù)電話：0371-60135900
虛擬主機(jī)/智能建站 24小時(shí)售后服務(wù)電話：0371-55621053
網(wǎng)絡(luò)版權(quán)侵權(quán)舉報(bào)電話：0371-60135995
服務(wù)熱線：0371-60135900