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服務器來實現優質節點的選擇，通過緩存來減少源站的壓力
