DNS 調度

基于請求端 local DNS 的出口 IP 歸屬地以及運營商的 DNS 調度。

DNS 調度的問題：

• DNS 緩存時間在 TTL 過期前是不會刷新的， 這樣會導致節點異常的時候自動調度延時很大，會直接影響線上業務訪問。
• 大量的 local DNS 不支持 EDNS 協議，拿不到客戶的真實IP，CDN 絕大多數時候只能通過local DNS IP來做決策，經常會出現跨區域調度的情況。

HTTP DNS 調度

客戶端請求固定的 HTTP DNS 地址，根據返回獲取解析結果。可以提高解析的準確性(不像DNS調度，只能通過local DNS IP來做決策)，能很好的避免劫持等問題。

當然這種模式也有一些問題，例如客戶端每次加載URL都可能產生一次HTTP DNS查詢，這就對性能和網絡接入要求很高。

302調度

基于客戶端 IP 和 302 調度集群進行實時的流量調度。

我們來看一個例子：

1. 訪問 URL 鏈接后，此時請求到了調度群集上，我們能拿到的客戶端信息有 客戶端的出口IP（絕大多情況下是相同的），接下來算法和基于 DNS 的調度可以是一樣的，只是判斷依據由 local DNS 出口 ip 變成了客戶端的出口IP。
2. 瀏覽器收到302回應，跟隨 Location 中的 URL，繼續發起 http 請求，這次請求的目標 IP 是CDN 邊緣節點，CDN節點會響應實際的文件內容。

302 調度的優勢：

• 實時調度，因為沒有 local DNS 緩存的，適合 CDN 的削峰處理，對于成本控制意義重大；
• 準確性高，直接獲取客戶端出口 IP 進行調度。

302 調度的劣勢：

• 每次都要跳轉，對于延時敏感的業務不友好。一般只適用于大文件。

AnyCast BGP路由調度

基于 BGP AnyCast 路由策略，只提供極少的對外 IP，路由策略可以很快的調整。

目前 AWS CloudFront、CloudFlare 都使用了這種方式，在路由層面進行調度。

這種方式可以很好地抵御 DDOS 攻擊，降低網絡擁塞。

當然這種方式的成本和方案設計都比較復雜，所以國內的 CDN 目前還都是用 UniCast 的方式。