背景
為什麼要談這個話題？緣由于現在 CDN 的廣泛應用在企業客戶，但是很多甲方的運維或者工程師對 CDN 的排程以及 DNS 的排程原理并不清楚，基本遇到問題也無法判斷到底是否問題在 CDN 。甚至使用者自己的使用規範不對也會埋怨是 CDN 的問題。今天簡單根據幾個案例聊下所謂 “排程不準” 的一系列疑問。
購買 CDN 加速服務後的解析流程
先了解幾個概念，我們在通過一張圖介紹下
1、首先 CDN 預設是通過 DNS 排程的，但提供了額外的 httpdns 産品，可以根據 IP 來進行準确的解析。
2、使用 CDN 加速服務會提供一個 CNAME 位址，但是 CNAME 的解析和域名的解析流程不同，不能混淆。
3、用戶端的真實出口 IP 和 出口 DNS IP 不一定是完全在一個 ISP 内。
“排程異常” 的範圍
一、使用者 DNS、出口IP 不再同一個營運商
如上圖，是一個很典型的熱點問題，使用者是聯通的 IP 出口，但配置了皓寬 DNS，結果是通路到 CDN 皓寬節點後出現了 ping 不穩定的情況。小營運商網絡都是從三大營運商買帶寬後組合的各種線路，通過網間的 proxy 跨網通路，網絡效果很差，逾時、RT 不穩定也不奇怪。使用者對 DNS 和 CDN 解析排程的基本概念也不了解，自認為是 CDN 節點出現了故障，這種回報很頻繁，分析這類問題并解決不難，可以參考：
1） 使用者端的 IP 必須和 localDNS 都是同營運商。 這個位址可以擷取到使用者的 IP 出口和 localDNS ，工具位址：
https://cdn.dns-detect.alicdn.com/https/doc.html基本上到這一步可以解決 20% 的場景。
2）要進行橫向比對域名的解析和 CNAME 解析是不是同樣出現問題，因為沒進入 CNAME 之前的域名解析都是由營運商的 localDNS 或者公用 DNS 遞歸轉發。而進去到 CNAME 之後是有 CDN 的 NS Server 和 CDN 内部排程系統處理。如果發現域名解析結果異常，但是 CNAME 解析結果正确，就可以明顯定位是 localDNS 或者 公共 DNS 的問題。到了這個環節基本就能解決 50% 的問題。
dig 域名
dig www.taobao.com
; <<>> DiG 9.10.6 <<>> www.taobao.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42589
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;www.taobao.com. IN A
;; ANSWER SECTION:
www.taobao.com. 131 IN CNAME www.taobao.com.danuoyi.tbcache.com.
www.taobao.com.danuoyi.tbcache.com. 24 IN A 61.155.221.227
www.taobao.com.danuoyi.tbcache.com. 24 IN A 221.229.203.214
www.taobao.com.danuoyi.tbcache.com. 24 IN A 221.229.203.213
;; Query time: 41 msec
;; SERVER: 30.14.128.31#53(30.14.128.31)
;; WHEN: Thu Mar 04 00:32:36 CST 2021
;; MSG SIZE rcvd: 136 dig $CDN_CNAME
dig www.taobao.com.danuoyi.tbcache.com
; <<>> DiG 9.10.6 <<>> www.taobao.com.danuoyi.tbcache.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13879
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;www.taobao.com.danuoyi.tbcache.com. IN A
;; ANSWER SECTION:
www.taobao.com.danuoyi.tbcache.com. 7 IN A 61.155.221.227
www.taobao.com.danuoyi.tbcache.com. 7 IN A 221.229.203.214
www.taobao.com.danuoyi.tbcache.com. 7 IN A 221.229.203.213
;; Query time: 41 msec
;; SERVER: 30.14.128.31#53(30.14.128.31)
;; WHEN: Thu Mar 04 00:33:54 CST 2021
;; MSG SIZE rcvd: 111 甚至可以更換 DNS 進行解析對比測試
dig www.taobao.com @114.114.114.114
; <<>> DiG 9.10.6 <<>> www.taobao.com @114.114.114.114
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58700
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;www.taobao.com. IN A
;; ANSWER SECTION:
www.taobao.com. 36 IN CNAME www.taobao.com.danuoyi.tbcache.com.
www.taobao.com.danuoyi.tbcache.com. 59 IN A 60.163.129.164
www.taobao.com.danuoyi.tbcache.com. 59 IN A 60.163.129.165
;; Query time: 40 msec
;; SERVER: 114.114.114.114#53(114.114.114.114)
;; WHEN: Thu Mar 04 00:35:43 CST 2021
;; MSG SIZE rcvd: 120 二、CDN 節點下線後為什麼使用者還會通路到
“下線“ 闡述這個概念前先說明，每個客戶的 CNAME 背後都對應着 CDN 一個排程域，有個 CDN 公司叫排程組。比如大檔案組、小檔案組、https 組等等。而排程域下可以簡單的了解為包含了 N 多個排程單元，層級往下追述服務使用者的 CDN 節點。
而 “下線” 就是服務端的監控聯合節點上各種業務、系統名額判斷節點 “生病” 了，需要從服務使用者的排程域中踢出，治理恢複後再重新上線。耳下線的過程涉及的較多，牽扯 DNS 解析、CDN 排程系統的生效、和自動化監控的準确性以及時效性。當下 CDN 廠商基本可以保證服務端排程的秒級切換和上下線，但是用戶端的 localDNS 确不是阿裡雲能夠控制的，經常會緩存住用戶端的 A 記錄，造成使用者依然通路舊的 CDN 節點，進而造成了所謂的故障。
從三個方面闡述
為什麼使用者端的 localDNS 要緩存 CDN 傳回的 A 記錄
1） 如果不對 CDN 傳回的 A 記錄進行緩存，那每次都要遞歸詢問 CDN 的權威伺服器，會消耗不必帶寬流量、對于網站的加載耗時也會增加。
2）很多小 ISP 或者四五線城市的 ISP 會不按規則出牌，比如 CDN 傳回的 DNSTTL 是 600 ，但會出現個别 ISP 把 TTL 緩存時間改的很大，這樣可以降低他們 localDNS Server 的查詢壓力，但這會網民可能就是個坑。
不按規則出牌進行的 TTL 緩存
帶來的結果就是用戶端短時間内無法切換到 CDN 新的節點上，通路異常切換時間的延長，也會加劇網民的通路異常。使用者可能會誤以為 “阿裡雲故障” ，這種情況下使用者可以保留 dig $domain 的傳回結果，以及 dig $CNAME 的對比結果投訴本地的接入營運商，并回報到阿裡雲協助處理。或者使用者可以清理 loaclDNS 緩存，但并不一定解決。
節點下線過程
節點被服務端監測到異常時，會自動從客戶的排程中删除，對應的 VIP 池子中摘掉，但這個摘除的過程，雖然排程系統秒級切換。但流量并不是瞬間掉到 0 byte ，很多已經長連接配接或者是解析出來節點 IP 正要通路的客戶仍然會把流量繼續打到 CDN 節點，是以節點流量有一個緩慢下降的過程，等流量基本都消除後，才會把 VIP 對應的服務停掉，不會直接将 VIP 對應的業務直接 kill ，基于這個流程，是以還有部分使用者會連接配接到舊的節點，直到整個請求過程完成。
三、解析出現了 0.0.0.0 127.0.0.1 空 等情況
出現上述情況，使用者第一時間就是認為阿裡雲故障。但并非如此，經過上面基礎介紹，大家應該知道了。網民通路域名時最先接入的就是 DNS 的解析，而控制台解析結果的就是 localDNS ，而 localDNS 如果傳回了 【0.0.0.0 127.0.0.1 空 】這種情況，說明使用者的 DNS 請求可能還未到 CDN，更不要說後面的建聯、通路的階段。
想驗證是阿裡雲 NS Server 沒有傳回記錄，還是使用者的 localDNS 解析異常，可以參考如下指令
dig $domain
dig $cname
如果解析異常，傳回 0.0.0.0、127.0.0.1、空說明 localDNS 層面禁止了全部解析。
dig $cname @114.114.114.114（可以多測試一些公共的大 DNS 避免資料不準）
如果解析正常，傳回 CDN IP ，說明 CDN 都是正常排程，沒有出現異常
dig $domain @114.114.114.114
如果解析異常，傳回 0.0.0.0、127.0.0.1、空說明可能是針對域名層面也做了封禁。
根據這個監測圖就能看出來，如果用 114 的 DNS 去解析就是正常傳回，如果是用 localDNS 解析就傳回了 0.0.0.0
為什麼會出現 0.0.0.0 127.0.0.1 空 等情況
經常遇到的原因如下：
1、使用者的域名被管局、省公安廳下發封禁操作。
2、使用者的域名被反詐騙中心警察局封禁。
3、使用者的域名被營運商封禁
怎麼申訴
有效果的申訴辦法，需要使用者第一時間保留測試現場作為申訴證據。到工信部的網站上進行申訴 ：
https://yhssglxt.miit.gov.cn/web/，有詳細的申訴流程，申訴通過後，工信部會聯系有關封禁部門解除封禁。
四、IP 歸屬問題
極個别的情況用戶端的 IP 在不同的 CDN 廠商會被劃分到不同的大區，比如同一個網民的 IP 10x.10x.x.x 在極個别的情況下可能在 A 廠商屬于廣電，在 B 廠商屬于移動，此時需要對應的 CDN 廠商糾偏，避免錯誤的排程到跨 ISP 的節點上出現通路異常。
但這種糾偏并不是随便做的，最合理的辦法是拿到使用者真正通路的 DNS IP 分别向相關的 2 個營運商詢問是否歸屬在其管轄的 IP 範圍。如果不确認好的話，直接糾偏對應的 IP 段，很可能整個段内的 IP 排程都會受到影響。有可能造成原本屬于廣電的 IP 被劃到了移動，出現災難性的連鎖問題。但是這種個别 IP 段不準的情況極少遇到。
常見解決排程異常的辦法
HTTPDNS産品
解決場景：使用者 localDNS 和出口 IP不一緻引起的排程不準确。以及針對 DNS 解析進行封禁的特殊場景。
使用者的請求方式，先用過 http 的方式請求 HTTPDNS 接口，擷取用戶端的排程 VIP，然後直接通路排程 VIP 。
HTTP 302
解決場景：針對用戶端 DNS 不準确的場景。HTTP 協定中有一個特殊的傳回狀态：302。在 HTTP 伺服器傳回 302 狀态碼時，可以攜帶一個新的 URL（使用的是正确 IP），浏覽器在拿到 302 傳回狀态碼時，會提取其中新的 URL 位址發起請求，這樣就可以做到重新排程了。弊病就是會有一定的耗時