[[247974]]

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

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

什么是CDN?

這是一個做過 CDN 之后的拓撲圖，里面有幾個概念需要明確一下:

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

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

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

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

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

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

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

DNS調(diào)度

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

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

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

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

因為剛才講到的DNS調(diào)度機制存在一定問題，所以在某些場合下我們會使用第二種調(diào)度機制，叫HTTP的調(diào)度。

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

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

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

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

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

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

CDN的接入

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

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

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

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

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

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

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

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

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

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

提到Cache的具體技術(shù)，我相信這里的很多朋友都是同行業(yè)的，有人會說其實這沒有什么難的，你只要有網(wǎng)絡(luò)、有運維人員就可以了。其實我并不這樣認為，因為你如果想把它做好的話其實很難，比如，我列出的很多技術(shù)你有沒有在考慮?

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

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

安全問題

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

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

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

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

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

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

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

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

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

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

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

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

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

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