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

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

什么是CDN?

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

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

User: 訪問者，也就是要訪問網站的網民;

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

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

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

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

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

DNS調度

肯定很多人好奇是如何進行調度和進行定位的?

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

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

從這個調度理論上看，我們可以發現一個問題，就是假設用戶所使用的LDNS地址和你是同一個區域，那么這個時候我們的調度才有可能是正確的。但是舉個例子來說，如果你是北京聯通的用戶，可是使用的是廣東電信的LDNS的話，就會讓GRB系統誤以為你是廣東電信的客戶，這樣就會錯誤的調度過去。

之前有一次我在小區里上網，由于我的路由器有問題，我設了202.106.0.20的北京聯通的DNS服務器地址，后來出差去深圳，訪問比較大的網站發現比較慢，經過分析，才發現原來我設的DNS地址是北京聯通的，而我在廣東和深圳使用的網絡都是電信接入的，但是分配給我的是北京聯通的地址，那我用電信的線路訪問北京聯通的地址，勢必就會很慢。

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

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

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

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

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

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

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

CDN的接入

可能會有人問，你講了這么多DNS和具體CDN的調度有什么關系呢?

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

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

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

Cache系統——緩存系統

除DNS調度以外，在CDN里還有一個非常大的重頭戲就是Cache系統,也就是緩存系統。它用于把那些可以緩存住的東西，緩存到CDN的邊緣節點，這樣當第二個人去訪問同一節點，同一具體電影或MP3時就不用再經過CDN鏈路回到真正的源站去拿數據，而是由邊緣節點直接給數據。

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

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

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

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

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

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

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

安全問題

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

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

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

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

第二部分主要是針對網絡層的優化、架構的優化、Cache的選型還有性能分析等等幾個方面，對整個CDN的基礎原理作很深入地剖析。

原始的CDN其實是Content Delivery Network這三個詞的縮寫，也就是內容分發網絡。但我認為應該是can do something on Network。CDN的理念是加速，所以，我們就盡一切可能去做各種優化，從一層到七層的優化來實現最終的優化效果。

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

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

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

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

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

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

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

傳輸層的優化剛才講到了是TCP優化，在現今的互聯網里，TCP優化是可以帶來最直接客戶體驗感的一種實現方式。

河南億恩科技股份有限公司(www.23lll.com)始創于2000年，專注服務器托管租用，是國家工信部認定的綜合電信服務運營商。億恩為近五十萬的用戶提供服務器托管、服務器租用、機柜租用、云服務器、網站建設、網站托管等網絡基礎服務，另有網總管、名片俠網絡推廣服務，使得客戶不斷的獲得更大的收益。
服務器/云主機 24小時售后服務電話：0371-60135900
虛擬主機/智能建站 24小時售后服務電話：0371-55621053
網絡版權侵權舉報電話：0371-60135995
服務熱線：0371-60135900