CDN的原理以及其中的一些技術

本質：DNS解析CNAME時最終會請求到阿里CDN的DNS服務器上，阿里CDN的DNS服務器會判斷請求ip的物理區域是哪裏，同時根據各CDN節點的壓力作全局的負載均衡

         返回合適CDN節點的ip。

http://cstdlib.com/tech/2015/08/18/what-is-cdn/

需求

CDN，全稱Content Delivery Network，主要做用是爲源站減小訪問壓力的同時，爲客戶端提供更快速的內容響應。除此以外，CDN還能對源站進行安全防禦。 其實真正爲CDN付費的是源站，因此CDN的用戶實際上是源站，例如新浪微博，youku視頻，淘寶網啊之類的。而客戶端，是CDN的用戶的用戶。 因此CDN是夾在源站和源站的用戶之間的，如下稱客戶端均指源站的用戶。

工做原理

傳統網站訪問過程

要說CDN的工做原理，就得先說說Internet資源的訪問過程。傳統的來講，在瀏覽器訪問網站應當有這麼一些步驟：

1. 在瀏覽器鍵入網址www.taobao.com
2. 瀏覽器請求dns服務器，查詢到www.taobao.com對應的IP
3. 瀏覽器向服務器發起TCP鏈接
4. 瀏覽器經過創建的TCP鏈接發送HTTP協議報文
5. 服務器向瀏覽器發送頁面內容
6. 瀏覽器將頁面展示出來

對於上面提到的第2步，其實仍是有須要來更加詳細的說明一下dns的解析過程，由於它是CDN能工做的基本條件。

DNS工做過程

DNS的工做過程容易被人忽略，通常只知道DNS的輸入是一個網址，輸出的是一個IP，在這裏我也正好給本身總結記錄一下。 DNS的協議主要是基於UDP的，因此dns server的qps通常都是很驚人的，比web server（http是基於tcp的）的qps是高出幾個量級的。有個基本概念就是dns的記錄類型，常見的dns記錄類型有A，AAAA，CNAME等。中A記錄是域名到IPV4地址的；AAAA記錄是域名到IPV6地址的；CNAME記錄相似於查詢過程當中的轉發，意思是你去問問這個我的，他管這事。好的，下面繼續說說DNS的工做過程。

1. 在瀏覽器鍵入www.taobao.com,其實真正dns協議裏用到的是www.taobao.com.最後還有一個點，多是由於美觀等緣由，通常都不顯示
2. 查詢本地緩存（host文件或者是瀏覽器的緩存）中有沒有該域名對應的記錄，有的話就直接用了
3. 向運營商的DNS服務器發起dns解析的請求，通常稱運營商的DNS服務器爲local dns
4. local dns會查詢本地的緩存，local dns設置的緩存時間是有講究的，過長太短都很差。另外local dns的查詢是運營商的事，這裏面水很深，外部不可控
5. local dns若是沒有緩存，會把域名從右往左掃描，依次請求對應的服務器，例如對於域名www.taobao.com.，先去問負責.的根域名服務器，就是傳說中全球只有幾臺的那些服務器，他們會答覆.com是誰管理的，而後local dns又去找管理.com的服務器（假設名字爲S1），去問問taobao.com是誰管，通常來講，在S1查到的記錄是一條cname記錄（阿里畢竟大公司，本身管理本身旗下的域名），而後就轉到了阿里本身的DNS服務器上來了，通常稱之爲權威服務器
6. 權威服務器是阿里本身建的，而後根據公司內部的一些配置啊，調整啊，查到www.taobao.com.對應的服務器是誰，返回一個IP地址
7. local dns緩存這個IP地址，而且回覆瀏覽器
8. 瀏覽器和對應的IP地址的服務器簡歷TCP鏈接，發送HTTP報文

買過域名的朋友都知道，假如你在萬網買了cstdlib.com，而後你想啓用一個二級域名go.cstdlib.com，那麼你要去萬網的控制檯（已經和阿里雲合併）設置一條A記錄的解析，將go.cstdlib.com指向你想要的IP。每次增長二級域名的過程都是這樣子。那麼，若是你知道了DNS的解析過程，你能夠這麼作：

1. 在服務器D1上起一個dns server，做爲cstdlib.com的dns權威服務器
2. 在萬網的控制檯新增一條CNAME記錄，將cstdlib.com的解析轉到D1來
3. D1想返回什麼IP就返回什麼IP

這樣一來，一切盡在掌控，畢竟D1是你的，並且之後你不再用去萬網的控制檯了，這就是自建DNS服務器。

CDN選擇優質節點

回到正題，CDN如何爲用戶選擇時延更小的源站。此次不以訪問淘寶爲例了，由於阿里有本身的CDN，要是以訪問淘寶爲例，容易混淆CDN的提供者和源站。 此次舉例以新浪微博爲源站，假設微博使用了阿里的CDN（並非假設，新聞在這裏），那麼阿里CDN會告訴微博，你要我給你加速一張圖片是吧，那你就把這個圖片解析到個人服務器來（能夠CNAME，也能夠直接寫阿里CDN的url），那麼，阿里CDN的dns權威服務器，會收到這麼一個解析請求，「請告訴我，新浪微博的1.png的源站在哪」。這時CDN系統就要大展身手了。

假設咱們如今是阿里CDN的dns權威服務器，有人問咱們「新浪微博的1.png的源站在哪」，那我會這麼作：先看看問個人這我的IP是多少（回憶一下dns解析的過程，咱們看到的應該是local dns的IP），而後根據這個IP查到他是哪裏的，北京仍是廣州，上海仍是深圳。若是是北京，那好，我就給你返回北京的源站的地址；若是是上海，那我就給你返回上海的源站的地址，這樣就實現了就近訪問。

在把IP地址對應到地理位置的過程當中，須要用到IP庫，阿里CDN的IP地址庫賤賤的，由於阿里CDN的負責人叔度在ArchSummit架構師峯會上說，他們能夠用淘寶的包裹記錄來校準，真是機智。

固然，就近只是一個要考慮的因素之一，還有不少因素須要考慮的，例如網絡成本，流量分佈，源站負載等。這是個很複雜的過程，我只是舉了一個直觀的方面來講。

CDN減小源站壓力

剛纔說了CDN是如何選擇優質節點的，那麼對於客戶端，算是有個交代了。因此接下來考慮怎麼給源站一個交代：減少源站壓力。若是每個用戶請求都讓他直接去源站拿的話，那源站將會承受巨大的壓力，因此要考慮爲源站提供一個HTTP的緩存，經過提高緩存的命中率來減少源站的壓力。

好比剛纔第一個用戶請求了1.png，那麼CDN先把這張圖片緩存（緩存簡單能夠認爲是一個哈希表，key是url，value是response）起來，下次再有人要1.png，就直接返回給他，從而減小回源流量。

HTTP緩存服務器是一個很複雜的功能。下面仍是貼一張叔度在ArchSummit架構師峯會上用到的PPT吧，來講一下這裏面大概的技術，阿里的HTTP緩存服務器叫Swfit，正好和蘋果的那個語言重名了。

圖中是一個CDN節點，用戶的請求從LVS（LVS是一個四層的負載均衡組件，做者是章文嵩博士，現任阿里雲CTO）的入口來，先由LVS作一次4層的負載均衡，而後轉到一臺Tengine（阿里在nginx的基礎上開發的服務器）上，Tengine作一致性hash，選擇一臺Swift（阿里使用的HTTP緩存服務器），而後Swift去作緩存回源。接下來仍然貼一張叔度在ArchSummit架構師峯會上用到的PPT，一塊兒看看Swift的架構。

首先能夠看到，Swift是一個多線程的程序，每一個線程起一個epoll來充分發揮多核的處理能力。而且儘可能減小線程間的上下文切換，一個請求儘可能在一個線程處理。而後圖裏面還能看到內存緩存，SSD緩存，SATA緩存。據叔度說，Swift會有熱點淘汰的機制，將熱文件放在內存裏，次熱文件放在SSD上，最後纔是SATA盤，而後會有熱點淘汰和提高機制。

同時叔度在ArchSummit峯會上還提出，Tengine和Swift是經過Spdy協議來通訊的，從而優化HTTP的效率。因此，CDN在技術上仍是頗有深度的，網絡，IO，多線程，TCP/IP，HTTP這些後臺常見的名詞在這裏面體現的淋漓盡致。

邊邊角角

其實在DNS查詢過程有一個這樣的問題，權威服務器接收請求的時候，只能獲得local DNS的IP，並不知道client IP。這是個很蛋疼的東西，因此google提出了EDNS的協議，會帶上client IP，可是其實不怎麼實用，由於這至關於你們緩存DNS查詢結果的時候多了一維client IP，一維數組變二維數組，簡直是內存的災難。因此，你們日常就別用8.8.8.8這樣的DNS服務器了，否則別人覺得你是在美國，而後用美國的源站和你通訊，確定慢成狗啊。

總結

總結一下CDN的工做原理：經過權威dns服務器來實現優質節點的選擇，經過緩存來減小源站的壓力。

推薦閱讀

最後推薦一下阿里CDN的負責人叔度在ArchSummit上的演講，把阿里CDN架構講的很清楚。本文不少內容來自該演講。連接在這裏。

http://www.infoq.com/cn/presentations/alibaba-cloud-cdn-technology-evolution/