三种CDN调度系统实现原理详解
1. 調度系統是什么？
調度系統是指CDN廠家有能力通過各種機制將客戶域名的所有現網請求引導到合適的目標機房，從而實現流量控制、質量控制、成本控制以及故障處理。
2. 接入CDN的方式
在講解調度原理之前，我們先來看看客戶是怎么接入CDN的，或者說客戶的流量是如何切往CDN的。(假設客戶的域名為：www.test.com,大概有以下幾種方式：)
【1】CNAME方式
CNAME方式是最常見的接入方式，即CDN廠家向客戶提供一個調度域名，客戶將自己業務域名的CNAME指向這個調度域名，從而實現將請求引導到CDN上來。
騰訊云向客戶提供的CDN是 $domain.cdn.dnsv1.com ，客戶的域名 www.test.com 如果需要將請求切到騰訊云CDN上，只需要將 www.test.com 的CNAME 設置為 www.test.com.cdn.dnsv1.com 即可。
CNAME方式的背后，又分為以下幾種模式：
01
CDN廠家提供基于DNS的調度，最終客戶的域名經CDN的調度域名解析出CDN節點的IP。騰訊云CDN即采用這種模式。
02
CDN廠家提供基于302的調度，給的CNAME不是真正CDN節點，而是一個調度集群，真正的CDN IP地址是通過在調度集群上向請求響應302跳轉實現的。騰訊云為一些手機廠家的下載業務提供過這種模式
03
再有一種，是Anycast CDN。從DNS層面上看，CDN廠家提供給你的CNAME的解析結果只有全球固定的一兩個IP地址，不像方式1中不同地區的解析結果IP不同。這種場景下的流量調度，不是靠DNS解析，而是Anycast BGP路由的調整，通過調整Anycast的路由來調度各地區的流量到哪個機房。
【2】調度域名深度定制方式
這種模式主要是一些代理商客戶，即使用騰訊云CDN來接客戶，又想在DNS層面隱藏他們使用的CDN廠商。一般做法是客戶提供一個自己的域名比如：gslb.mycdn.com，騰訊云也提供一個中性的且不備案的平臺調度域名glsb.mycdn-platform.com。真正的客戶域名 www.test.com CNAME到 gslb.mycdn.com ，后者CNAME到騰訊云的調度域名 gslb.mycdn-platform.com。這樣整個解析環節都沒有騰訊云的痕跡。
【3】域名托管方式
這種模式不太常見。以域名 www.test.com 為例，如果客戶要將請求切往CDN，需要將 test.com 的NS記錄改為 CDN廠商提供的NS 權威服務器。這時CDN廠商同時擔當了DNS服務商和CDN服務商的角色。
3. 調度形式詳解
| DNS調度 | 基于請求端local dns的出口IP歸屬地及運營商屬性的DNS調度 |
| 302調度 | 基于客戶端IP歸屬地及運營商屬性的302跳轉調度 |
| 路由調度 | 基于Anycast技術（BGP路由）的機房流量調度 |
【1】DNS調度
CDN的調度服務器是調度域名的NS權威服務器，調度域名的TTL被故意設置成很短（比如3分鐘），這樣所有請求都會較頻繁地觸發客戶端的local DNS重新到CDN調度服務器解析新的IP地址。此時CDN的調度服務器依據是local DNS的出口地址。DNS調度流程如下：
01
客戶端DNS TTL過期無首次訪問，向local DNS發起DNS查詢
02
local DNS在遞歸解析過程中，向CDN的調度服務器發起解析請求
03
CDN調度服務器可以看到local DNS的出口ip（有時還有基于EDNS的客戶端ip）
04
通過IP庫獲取上一步IP的地理及運營商屬性，從當前調度域名的策略規則中匹配，同時結合其它的因素（比如質量監控、機房成本因素等）得到最佳的一組IP
以上是DNS調度的基本流程，下面將舉個實際場景中的例子:
| 測試機出口IP | 113.87.117.154 (中國 廣東 深圳 電信 中國電信)；出口IP會變化，但大概率穩定在深圳電信 |
| DNS服務器 | 202.96.134.133 / 202.96.128.166 (中國 廣東 深圳 電信 中國電信)，中國電信DHCP自動配置 |
| DNS出口地址 | 202.96.136.240 (中國 廣東 深圳 電信)，多次測試結果會發生變化，但大概率穩定在深圳電信 |
| 目標域名解析 | p73.ping.dnsv1.com 的DNS解析情況如下：p73.ping.dnsv1.com；p73.ping.dnsv1.com.cdn.dnsv1.com；388957.p23.tc.cdntip.com；113.96.154.108 等十多個IP |
DNS調度原理
01
瀏覽器首次請求目標URL，本地無p73.ping.dnsv1.com 解析記錄，向DNS服務器（也稱為 local DNS）202.96.134.133發起查詢請求
02
202.96.134.133（此IP背后的真實服務器）若本地無緩存，發起遞歸解析，最終解析到388957.p23.tc.cdntip.com，解析請求被發往cdntip.com的權威服務器 ns-open3.qq.com
ns-open3.qq.com并非一臺實體服務器，而是網絡的虛擬IP，先避開復雜的網絡結構，其背后有一臺或多臺真實DNS權威服務器（或集群），為描述方便假設其IP為10.1.1.1
03
10.1.1.1 目前有的信息包括域名 388957.p23.tc.cdntip.com、local DNS ip 202.96.136.240。如果local DNS支持EDNS，那此時還能看到客戶端IP 113.87.117.154。
有了以上3個信息，調度服務器，就能通過算法得出結果了
04
202.96.134.133 將IP結果返回給客戶端，瀏覽器按自己的策略從中選擇一個IP發起HTTP請求
DNS調度的優缺點：
| 缺點 | 調度策略非實時生效（DNS是樹型分布式系統，所有節點上都會按域名的TTL來做緩存） |
| 調度不夠精確（大量的local DNS不支持edns協議，拿不到客戶的真實IP，CDN絕大多數時候只能通過local DNS ip來做決策，而local DNS ip有時候不太靠譜） |
【2】302調度
先看下302模式下與前面的DNS調度有什么不同。
（http://p73.ping.dnsv1.com/a.php）
在DNS解析調度模式下，瀏覽器訪問上面的URL時，正常情況下會收到CDN節點的返回碼200和文件內容，即DNS解析到的IP會直接做為文件服務器響應瀏覽器請求。類似于：
HTTP/1.1 200 OK
Server: NWS_S1
Connection: keep-alive
Date: Sun, 11 Dec 2018 19:44:02 GMT
Transfer-Encoding: chunked
Keep-Alive: timeout=120
X-Daa-Tunnel: hop_count=2
X-NWS-LOG-UUID:750246221628030518 0be2170ce2df3d9f634cd70470120401
\r\r\r\n文件內容
但在302跳轉模式下，上述URL的訪問，瀏覽會收到一個狀態碼為302的響應：
HTTP/1.1 302 Moved Temporarily
Server: stgw/1.3.6.2_1.13.5
Date: Sun, 16 Dec 2018 19:38:58 GMT
Content-Type: text/html
Content-Length: 168
Connection: keep-alive
Location: http://61.142.166.245/p73.ping.dnsv1.com/a.php
意思是告訴瀏覽器，你需要繼續訪問Location中的URL去請求實際的文件內容。所以瀏覽器又發起了第2次請求：
http://61.142.166.245/p73.ping.dnsv1.com/a.php
這個URL中的IP地址，就是CDN調度系統為我們分配的CDN節點，我們來看這個IP是怎么拿到的。
域名解析的過程和基于DNS的調度一樣，最終都會拿到一組IP，目標IP有兩種情況：
◎目標IP并不是CDN的實際邊緣節點，而是302調度集群的IP；
◎IP是CDN的普通邊緣節點IP
01
瀏覽器向第一次拿到的IP發起http請求
02
如果這個IP實際上是CDN的邊緣節點，它會從本機的配置文件中讀取信息：
◎若請求Host不是IP，URL形式為：http://p73.ping.dnsv1.com/a.php，則將請求轉發到后端調度集群；
◎若請求Host為IP，URL形式為：http://61.142.166.245/p73，ping.dnsv1.com/a.php，則讀取緩存提供文件服務
03
此時請求到了調度群集上，我們能拿到的客戶端信息有客戶端的出口IP（絕大多情況下是相同的）
04
接下來算法和基于DNS的調度可以是一樣的，只是判斷依據由local DNS出口IP變成了客戶端的出口IP（調度集群畢竟不是CDN節點，無法向客戶端提供實際的文件內容，此時它只能通過302報文告知客戶端）
05
瀏覽器收到302回應，跟隨Location中的URL，繼續發起http請求，這次請求的目標IP是CDN邊緣節點，且Host是IP，CDN節點會響應實際的文件內容
302調度的優缺點：
| 準確性高（可以拿到請求的出口IP，在不考慮NAT或小運營商出口飄移時，客戶端歸屬地更貼近真實情況，不受用戶的DNS配置影響） | |
| 缺點 | 業務兼容性（要求客戶業務的客戶端必須支持302跟隨，比如手機固定或應用下載，如果下載客戶端不識別http 302響應碼，那下載就會失敗） |
| 不適用于延時敏感業務（每個請求都會多出一次http交互，加載時間會成倍增加，對于web靜態小資源不合適） |
因此，302只適用于客戶端兼容性好的大文件下載業務哦~
實時調度的好處：
◎快速隔離故障設備
◎精確控制節點于機房的帶寬和資源負載
◎快速應對業務突發，尤其適合大文件加載類突發場景，例如：手機固件、游戲安裝包、大體積資源分發
【3】路由調度
Anycast路由技術使得物理分布在全球/全球不同區域的不同服務器具有相同的IP地址，客戶端對這個IP的請求會在路由層面引導到最近的物理服務器上。
Anycast BGP路由調度模式在表現形式上和DNS調度一樣：
◎業務域名通過CNAME解析到CDN的調度域名
◎CDN的調度域名解析出的IP即邊緣節點IP，請求不會發生302跳轉
但也有特殊之處：
◎解析結果的全球IP數量極少，通常只有1-2個，或者一個大洲或大片區域1~2個
◎DNS的TTL通常極大，經常配置成2小時甚至更長
Anycast路由調度的優缺點：
| 比DNS抗干擾，比302兼容性好（在路由層面完成了就近接入CDN） | |
| 路由策略變動生效時間快，優于DNS調度 | |
| 受DDOS攻擊時，只需調整路由，將攻擊流量引導到高帶寬清洗機房，無需從現網剔除IP | |
| 缺點 | 方案復雜（全網網絡復雜，BGP路由優化繁瑣，容易造成網絡不通，請求延時較長） |
| 成本高（Anycast實施需要整個完整的IPC段，IP浪費嚴重，為達到好的效果和扛攻擊，全球機房都要有足夠的帶寬） |
關注騰訊云CDN公眾號，技術干貨一手掌握！
總結
以上是生活随笔為你收集整理的三种CDN调度系统实现原理详解的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： IPv6下CDN和网络的最佳实践
- 下一篇： 应用于CDN的GSLB系统