CDN基礎詳解

什麼是 CDN？

 

Origin Server: 源站，也就是作 CDN 以前的客戶真正的服務器;   User: 訪問者，也就是要訪問網站的網民;   Edge Server: CDN 的服務器，不單隻「邊緣服務器」，這個以後細說;   Last Mile: 最後一千米，也就是網民到他所訪問到的 CDN 服務器之間的路徑。

 

舉例：

咱們平時所使用的DNS服務器，通常稱之爲LDNS，在解析一個域名的時候，通常有兩個狀況，一種是域名在DNS上有記錄，另外一種狀況是沒有記錄，兩種狀況的處理流程不同。   當你訪問163這個域名時，若是LDNS上有緩存記錄，那它會直接將IP地址直接給你。若是沒有緩存記錄，它將會一步步向後面的服務器作請求，而後將全部數據進行彙總交給最終的客戶。   當你訪問163這個地址時，實際上若是自己沒有內容的話，它要去後面拿數據，這個過程術語叫遞歸，它首先會向全球13個根域服務器請求，問com域名在哪，而後根域服務器做出回答，一步步往下。

 

---

DNS調度

 

是如何進行調度和進行定位的？

其實也是經過LDNS的具體地址來進行的，好比，看圖，假設你是一個廣東電信客戶，那你所使用的DNS服務器去作遞歸的時會訪問到某一個CDN廠商的GRB，全球的一個調度系統,他就能看到來自於哪一個LDNS。假設若是用戶和LDNS使用同一個區域的服務器，他就會間接認爲用戶也是廣東電信的。   再舉個例子，好比說北京聯通的用戶，它使用DNS地址，通常自動給它分配的是北京聯通的服務器，這個服務器去作遞歸的時候，調度服務器就會看到這個請求是來自北京聯通的LDNS服務器，就會給它分配一個北京聯通的服務器地址，而後讓來自北京聯通的用戶直接訪問北京聯通的服務器地址，這樣來實現精準的區域性調度。   總結：用戶在設置自己DNS上須要警戒，不一樣的DNS指向的地區不一樣，會嚴重影響速度。

 

---

Http的302調度：

 

在http協議中有一個叫302跳轉的功能，它的實現並非說你訪問一個URL，而後立刻吐給你想要的數據，而是吐給你一個302返回信令，這個信令頭部會告訴你，有一個location目標，這個location就是告訴你下一步將要怎麼作，而具體調度是經過location來實現的。 舉例：即使我所使用的DNS和我不在一個區域，但當我訪問http server的時，這個server是由CDN公司提供的。客戶訪問server的時，雖然說經過DNS方式沒法拿到客戶的真正IP地址，可是若是你訪問的是http server，他必定能直接看到客戶的真實IP，利用這種方法能夠進行調度的糾偏，能夠直接返回給你一個302，而後location裏面攜帶一個真正離你最近的CDN server。   這種調度方式，優點是準確，可是也存在弊端，它不像DNS那樣直接請求一個數據包過去給一個反饋就OK了，他須要一次TCP的三次握手建連。

 

存在的問題：

通常狀況下都是經過DNS來進行第一次調度，而後用http來進行第二次糾偏。這種狀況下你們能夠想象，若是你下載一個大文件，好比說電影，但你訪問的是一個頁面小元素，好比說這個圖片只有幾k，那麼，實際上你調度的時間就已佔用了很大的成分。實際上，這種302調度是一種磨刀不誤砍柴工的方案，若是你後面有不少工做要作，好比要下載一個電影時間會很長，那你調度準確，即便花一點時間調度也是值得的。可是若是你後續訪問一下就完了，那麼你這樣調度就沒有太大意義。

 

---

Http DNS調度：

 

原理是經過一個正常的http請求，發一個get的請求，而後再請求裏面以參數的形式攜帶一個目標解析的域名，而後服務器那邊去經過數據庫查詢，查詢以後又經過http的正常響應，把目標請求的IP經過http協議給用戶，這種協議有一個特色就是必須雙端都支持，由於這種模式是非標準的。   這有點相似是一種API的這種方式，那若是要實現的話就必須雙端都支持。   通常，第三種調度的應用場景是在手機的APP端，在APP軟件裏面，你要訪問某些東西頗有可能被運營商劫持等問題。那爲了不這種劫持，可能會用到這種http DNS的調度方式。

 

---

CDN的接入：

那在沒有CDN以前，返回給用戶的IP地址就是在原來沒作CDN時的原始服務器地址。但若是你作過CDN的話，你會發現最終拿到的這個IP地址是CDN的節點，而並非真正的原始服務器。 實際上第一跳是跳到網速地址，第二跳是分配了網速的一個平臺，這個平臺又分開其餘的IP給最終的客戶。

 

---

Cache 系統

在CDN裏還有一個很是大的重頭戲就是Cache系統,也就是緩存系統。它用於把那些能夠緩存住的東西，緩存到CDN的邊緣節點，這樣當第二我的去訪問同一節點，同一具體電影或MP3時就不用再通過CDN鏈路回到真正的源站去拿數據，而是由邊緣節點直接給數據。

 

對於Cache系統來講，有兩種不一樣的工做狀態。   第一種工做狀態就是所謂的命中（hit），第二種就是沒有命中（miss）。若是命中了，直接經過檢索找到磁盤或內存上的數據，把這個數據直接吐給客戶，而不是從後面去拿數據。這樣的話就起到一個很完美的加速效果。   第二種是在miss時，其實，miss的時候跟hit惟一的區別就是，當我發現個人本機上沒有這個資源，我會去個人upstream（上游）去拿數據。拿完這個數據，除了第一時間給客戶，同時還會在硬盤上緩存一份。若是這個硬盤空間滿了，會經過一系列置換方法，把最老的數據、最冷的數據替換出去。

 

---

安全問題

 

攻擊通常分紅兩種,第一種叫 蠻力型攻擊，量大的讓你的帶寬沒法抗住最後致使拒絕服務，另一種是 技巧性攻擊。

 

蠻力型攻擊，做爲CDN來說，就已經將你的原始服務器的IP進行了隱藏。這樣當一個攻擊者去訪問你的域名的時，實際上訪問的並非你真正的服務器。當他訪問的是CDN的節點，就沒有辦法把CDN的節點打倒，換句話說，即便有能力把CDN的好比10g的節點或者是40g的大節點所有打倒，但因爲CDN自然的分佈式的部署方式，他也很難在同一時間以內迅速的把全國全部CDN的邊緣節點全都打癱。   技巧型攻擊，好比說，像注入、掛馬甚至說更嚴重的會直接拖走你的數據庫等等。防範：如WAF，就是應用層防火牆，他能夠直接去解析你的請求內容，分析內容是否有惡意性，若有惡意性的話去進行過濾，報警等一系列措施來保證你的原始服務器的安全。

 

---

CDN核心

 

原始的CDN實際上是Content Delivery Network這三個詞的縮寫，也就是內容分發網絡。CDN的理念是加速，因此，咱們就盡一切可能去作各類優化，從一層到七層的優化來實現最終的優化效果。

 

 

具體優化：

一層優化硬件，服務器選型就是一種優化。是用ssd，仍是用saker硬盤，CPU應該用至強仍是應該用阿童木的等等。   至於二層，鏈路層的優化指的就是資源方面。好比機房如何去選擇。   三層路由層是指你在middlemell這塊真正選路的具體的細節，後面會有一個圖來具體講一下。   四層是指傳輸層的優化，咱們通常的業務全都是TCP，因此說這裏面就能夠明確的說這裏是指TCP的優化。   七層也是能夠優化的。好比說你強行對內容進行壓縮，甚至你改變壓縮級別去   在現今的互聯網裏，TCP優化是能夠帶來最直接客戶體驗感的一種實現方式。

---

爲何沒有對手快分析：

 

在CDN裏你玩的是什麼？你玩的實際上就是網絡。對CDN公司來講。坦白來說，服務器有三大部分組成，第一部分是你的操做系統，第二部分是你的Cache緩存系統，第三部分就是你的網絡。

 

通常你的操做系統選型完畢優化以後你通常不會再動它了，除非遇到了重大的安全隱患或者是有重大的升級。而對你Cache系統來講也是，通常都求穩，在沒有重大的bug的時，不會去輕易的改變。但最複雜的就是網絡，你必需要掌握對網絡的控制度，這樣的話你才能駕馭它。

 

RTT: 往返時延。表示從發送端發送數據開始，到發送端收到來自接收端的確認，總共經歷的時延。

咱們能夠經過第一次和第二次握手，看到他的往返時延是35毫秒。和以前的23毫秒相比，可知這個資源的ping值比原來增長了52%。經過剛纔的分析方法咱們也能夠找到第35和37號包的跳變點。那麼35號包以前是第一個發送輪迴。整個的發包數量是20，它的初始發包數量實際上並非標準的10，而是20。那麼，咱們能夠再算一下，若是你有50kb必需要發出，你最終須要也是36個包，可是你初始是20就需兩輪，分別是20+16。   經過套公式，可知須要150毫秒完成。那150毫秒跟以前的92比只慢14%。在資源落後52%的狀況下，最終效果才慢了14%，中間的這個差距實際上就是你的技術帶來的價值。

 

---

WScale、SACK是什麼東西？

 

每一個廠商不管你是作CDN，作電商、作IT企業，只要你有對外提供的server，並且server的負載比較高都會遇到的一個syncookie的坑。在TCP的標準裏有兩個選項一個叫WScale一個是SACK。

 

在TCP三次握手的時候，客戶端若是要支持WScale選項的話，服務端被通知支持這個選項。若是服務端也支持，會記錄下來講客戶端支持，同時迴應也支持。在客戶端拿到第二次握手時，服務端就也把本身置成支持狀態了。在數據傳輸的時，它是以2爲底數，而後以WScale的這個n值爲指數的一個滑動窗口遞增值。   利用這個WScale是可把發送窗口的數量漲到很大的，好比說64k、128k、256k甚至更大。若是要這樣再套公式，他的傳輸效果就會變得很是好了。

 

關於參數SACK，選擇性應答。在你數據傳輸的時，沒有這個選項會怎麼樣呢？好比，要傳10個數據包，只有第6個數據包丟掉了，這時候須要把6到10從新發一遍，存在許多重複提交，速度會很是慢。 若是收到連續的序號完整的到5，可是還收到了7到10。服務端就可經過這兩個信息進行拼接找到中間的空隙，就會知道只有6號丟掉了，只需傳6便可。

 

syncookie須要注意的坑！

 

syncookie開啓的狀況下會怎麼樣呢？他會在協議棧以前本身僞造一個應答機制，並非真正的協議棧去代應答第二次握手。同時他的第二次握手會攜帶一個算好的一個cookie值做爲第三次握手的校驗。若是他收到了第三次握手的校驗值的會被認爲是一個合法的建連，那麼，他會把這個經過注入的方式，直接告訴你這個連接能夠直接用了。那在前期syncookie當滿的時候開始啓動這個狀態，他是不佔用隊列的，因此說他是一個很是好的防攻擊的一個手段，可是他的防攻擊的量不會很大，微量是能夠的。   但坑也偏偏就在這。因爲syncookie他不是標準的TCP協議棧，因此說他的支持，並非很是的完備。等一段syncookie發出，他代應答的第二次握手並不攜帶WScale和SACK這個選項。就會讓客戶端誤認爲是不支持的，因此，後續的溝通就變得很是的低效。咱們以前作過一個實驗，在有必定量丟包並且大延時的狀況下，你的速度可能只有300多k。後來查了不少資料發現確實是這個樣子,並且咱們作了不少的模擬時間。好比，都爲syncookie出發的時，他速度確實就很快。   後來咱們作了一個改動，在syncookie上，若是要是代應答的時，咱們攜帶SACK的這個數據給客戶，那後來建連的時均可以把這個功能用起來。用起來時咱們在線上是真正的無環境試驗能夠提高大概25%到35%的服務質量。

 

Cache的選型

 

目前市場上經常使用的cache選型： 不少公司直接使用開源； 目前並不推薦自研 緣由： 第一，你要耗費大量的人力和時間。 第二，你須要去思考，你能不能cover住這些本來人家已經作好的東西。 經過上面的截圖分析： 在客戶端發起請求的時候指望去和服務器進行這種長鏈接。而服務器給出去的時，並無明確的告訴客戶端是否支持。   致使這個問題的緣由是因爲咱們的研發人員並無真正地領會RTT協議的精髓，他沒有徹底cover住這個RTT協議致使最基本的這種車輪，這個輪骨作的是有問題的致使很嚴重的坑。

 

轉自《https://mp.weixin.qq.com/s?__biz=MjM5NTU2MTQwNA==&mid=2650653458&idx=3&sn=b658019ef6407a7d00f784f6f0cf238f&chksm=beffc9c1898840d7b75b27a3ba1f0f3084f6f7d7a45789c4adfbdf99522c15197d3974f88666&scene=21#wechat_redirect》，整理髮布。