DNS 調(diào)度

基于請(qǐng)求端 local DNS 的出口 IP 歸屬地以及運(yùn)營(yíng)商的 DNS 調(diào)度。

DNS 調(diào)度的問題：

• DNS 緩存時(shí)間在 TTL 過期前是不會(huì)刷新的， 這樣會(huì)導(dǎo)致節(jié)點(diǎn)異常的時(shí)候自動(dòng)調(diào)度延時(shí)很大，會(huì)直接影響線上業(yè)務(wù)訪問。
• 大量的 local DNS 不支持 EDNS 協(xié)議，拿不到客戶的真實(shí)IP，CDN 絕大多數(shù)時(shí)候只能通過local DNS IP來做決策，經(jīng)常會(huì)出現(xiàn)跨區(qū)域調(diào)度的情況。

HTTP DNS 調(diào)度

客戶端請(qǐng)求固定的 HTTP DNS 地址，根據(jù)返回獲取解析結(jié)果?？梢蕴岣呓馕龅臏?zhǔn)確性(不像DNS調(diào)度，只能通過local DNS IP來做決策)，能很好的避免劫持等問題。

當(dāng)然這種模式也有一些問題，例如客戶端每次加載URL都可能產(chǎn)生一次HTTP DNS查詢，這就對(duì)性能和網(wǎng)絡(luò)接入要求很高。

302調(diào)度

基于客戶端 IP 和 302 調(diào)度集群進(jìn)行實(shí)時(shí)的流量調(diào)度。

我們來看一個(gè)例子：

1. 訪問 URL 鏈接后，此時(shí)請(qǐng)求到了調(diào)度群集上，我們能拿到的客戶端信息有 客戶端的出口IP（絕大多情況下是相同的），接下來算法和基于 DNS 的調(diào)度可以是一樣的，只是判斷依據(jù)由 local DNS 出口 ip 變成了客戶端的出口IP。
2. 瀏覽器收到302回應(yīng)，跟隨 Location 中的 URL，繼續(xù)發(fā)起 http 請(qǐng)求，這次請(qǐng)求的目標(biāo) IP 是CDN 邊緣節(jié)點(diǎn)，CDN節(jié)點(diǎn)會(huì)響應(yīng)實(shí)際的文件內(nèi)容。

302 調(diào)度的優(yōu)勢(shì)：

• 實(shí)時(shí)調(diào)度，因?yàn)闆]有 local DNS 緩存的，適合 CDN 的削峰處理，對(duì)于成本控制意義重大；
• 準(zhǔn)確性高，直接獲取客戶端出口 IP 進(jìn)行調(diào)度。

302 調(diào)度的劣勢(shì)：

• 每次都要跳轉(zhuǎn)，對(duì)于延時(shí)敏感的業(yè)務(wù)不友好。一般只適用于大文件。

AnyCast BGP路由調(diào)度

基于 BGP AnyCast 路由策略，只提供極少的對(duì)外 IP，路由策略可以很快的調(diào)整。

目前 AWS CloudFront、CloudFlare 都使用了這種方式，在路由層面進(jìn)行調(diào)度。

這種方式可以很好地抵御 DDOS 攻擊，降低網(wǎng)絡(luò)擁塞。

當(dāng)然這種方式的成本和方案設(shè)計(jì)都比較復(fù)雜，所以國(guó)內(nèi)的 CDN 目前還都是用 UniCast 的方式。