CDN 调度策略

什么是 CDN 的调度？

• CDN 调度是指通过各种策略将客户端请求调度到合理的目标机房。以达到成本、质量（可用性、平均速度）的最佳控制。

调度形式一般有以下几种形式：

1. DNS 调度
2. HTTP DNS 调度
3. 302 调度
4. 路由调度（Anycast）

DNS 调度

基于请求端 local DNS 的出口 IP 归属地以及运营商的 DNS 调度

我们通过 dig +trace 的过程看一下 DNS 解析的过程

➜  ~ dig cdn-galvin.e-galvin.cn +trace             

; <<>> DiG 9.10.6 <<>> cdn-galvin.e-galvin.cn +trace
;; global options: +cmd
.           66828   IN  NS  k.root-servers.net.
.           66828   IN  NS  a.root-servers.net.
.           66828   IN  NS  d.root-servers.net.
.           66828   IN  NS  c.root-servers.net.
.           66828   IN  NS  l.root-servers.net.
.           66828   IN  NS  e.root-servers.net.
.           66828   IN  NS  g.root-servers.net.
.           66828   IN  NS  h.root-servers.net.
.           66828   IN  NS  m.root-servers.net.
.           66828   IN  NS  f.root-servers.net.
.           66828   IN  NS  b.root-servers.net.
.           66828   IN  NS  j.root-servers.net.
.           66828   IN  NS  i.root-servers.net.
.           86378   IN  RRSIG   NS 8 0 518400 20191118050000 20191105040000 22545 . esnH6oyu3KXHC3SgoLAB41ywce9pFGdCWcAQov2OJ7LpCa6Qa5FNAAbr xnWnBVacijq8eQal6OxsfiWpW07xtIZ/Lw+UZrnkzvzIGMmZsN8To8Wf f/7bmfU1aefTSGNDe5pcIyk/YQUg/PK7h5TKpruYkRa+Yflg2KXcv1zJ 7WQ2tPjdsuIinw+g0TfCo6ev+cn1WXDw/wdvUMKttJMB0Lq1ETzsXv07 EBeJVD7TISWIeOVYqr3jxZ3mlFNoX6BwGCB/EjLpwCqdexK40sriE2Sl iGwHwZ3MFsivRzwqYV7r+kM56yL8O6EBo25sJFhT4+EWb7EhDXQ52jHj Bjvpsw==
;; Received 1111 bytes from 172.18.52.2#53(172.18.52.2) in 42 ms

cn.         172800  IN  NS  a.dns.cn.
cn.         172800  IN  NS  b.dns.cn.
cn.         172800  IN  NS  c.dns.cn.
cn.         172800  IN  NS  d.dns.cn.
cn.         172800  IN  NS  e.dns.cn.
cn.         172800  IN  NS  f.dns.cn.
cn.         172800  IN  NS  g.dns.cn.
cn.         172800  IN  NS  ns.cernet.net.
cn.         86400   IN  DS  57724 8 2 5D0423633EB24A499BE78AA22D1C0C9BA36218FF49FD95A4CDF1A4AD 97C67044
cn.         86400   IN  RRSIG   DS 8 1 86400 20191118050000 20191105040000 22545 . WyzJOsC1vL4G/ZluvJHaS7GQNxfA/A7j2zGr5mu9u1zMEaEpL+AzbPoG IJ0sM4xZaCwf/1LFVKPZRma2kqZV4IRnhQZR6mY8WM9NP0a69IaHMmvG jpjHCmtPuByifXPoKmJsMMJuWnERXqQ+huogxczoo27vUt7mwdCRBVo5 P332hOOVfT3W0/V2tdROVfF3RgUAaNzv3f355MzgwXRpa+SbNEKisWq4 JvpqxG/kAA/33GBdHZPuDL8AeXWvgDLv5G6zsUgUcJsb0CiPEV0kXjHn TBzvdX/OUA84xo+BxGXteQkYF/SYv5EgIBPtFlJyan/OF4UPm1WkzeF/ NreZTA==
;; Received 713 bytes from 199.7.91.13#53(d.root-servers.net) in 74 ms

e-galvin.cn.        86400   IN  NS  f1g1ns2.dnspod.net.
e-galvin.cn.        86400   IN  NS  f1g1ns1.dnspod.net.
3QDAQA092EE5BELP64A74EBNB8J53D7E.cn. 21600 IN NSEC3 1 1 10 AEF123AB 3QLMP0QRNQ96G5AFGOPNB7U7IJ4MBP4B  NS SOA RRSIG DNSKEY NSEC3PARAM
3QDAQA092EE5BELP64A74EBNB8J53D7E.cn. 21600 IN RRSIG NSEC3 8 2 21600 20191117072923 20191018072244 38388 cn. HXL4nUKND4ZJq6ZnjNKV0IyMCWh21KV9DA/hc/SBYpBNSE8fdq1Y7KlG O8DO+sgP/M68Zrkuml7cFTiFaJ1uYo7gHD55knKBrc1EbLRI3SehH6Q7 5iTGkZKEt70J2F4MnJ7gTdXUUhaJj5pEC8TiIB/Jebn5BV+FnyRh6XKJ s/c=
P4TRQG62UNGRB369OCJJBO43M8PFTR8K.cn. 21600 IN NSEC3 1 1 10 AEF123AB P4VVD0FRM6DCF16DU5E55F39TIG85RGV  CNAME RRSIG
P4TRQG62UNGRB369OCJJBO43M8PFTR8K.cn. 21600 IN RRSIG NSEC3 8 2 21600 20191117080118 20191018071547 38388 cn. fN0+cZt4zu9NVixY7lYNEllMYxxgoJlowgJsdzCPK5etrJrUJ9RYwlhd B8wuVm7if9enxeOb/cB1X3HsHyavynOu3I/d1U6NSAjee6/QpkYfZGK/ 84EhhCOuIP/DD3uqef0ZHg7SuCqur4+kVCus3xojwoDZISfPF+hE61fE ivo=
;; Received 596 bytes from 203.119.28.1#53(d.dns.cn) in 37 ms

cdn-galvin.e-galvin.cn. 600 IN  CNAME   cdn-galvin.e-galvin.cn.a.bdydns.com.
e-galvin.cn.        86400   IN  NS  f1g1ns1.dnspod.net.
e-galvin.cn.        86400   IN  NS  f1g1ns2.dnspod.net.
;; Received 164 bytes from 14.215.155.170#53(f1g1ns1.dnspod.net) in 34 ms

从上面的解析过程可以看出，先从根域开始，一步一步到主域名。

主域名最后是一个 CNAME 地址，最后又会再解析这个 CNAME 得到最后的结果。

NS 记录 显示了这个域名的权威 DNS，一般由云厂商提供 。

DNS 调度的问题：

• DNS 缓存时间在 TTL 过期前是不会刷新的， 这样会导致节点异常的时候自动调度延时很大，会直接影响线上业务访问
• 大量的 local DNS 不支持 EDNS 协议，拿不到客户的真实IP，CDN 绝大多数时候只能通过local DNS ip来做决策，经常会出现跨区域调度的情况。

HTTP DNS 调度

客户端请求固定的 HTTP DNS 地址，根据返回获取解析结果。能很好的避免劫持等问题。

下面我们查看下 HTTP DNS 请求解析结果的示例。

➜  ~ curl http://180.76.76.200/v3/resolve\?account_id\=102797\&dn\=www.e-galvin.cn\&sign\=a0482d97037d7b4950a09b9021d96651\&t\=1593602734 | json_pp
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   125  100   125    0     0   2118      0 --:--:-- --:--:-- --:--:--  2118
{
   "data" : {
      "www.e-galvin.cn" : {
         "ip" : [
            "180.76.76.76"
         ],
         "ttl" : 300
      }
   },
   "timestamp" : 1573366501,
   "clientip" : "116.226.251.138",
   "msg" : "ok"
}

从结果可以看出，直接访问 180.76.76.200，就可以获取到 www.e-galvin.cn 的解析结果。这样就可以提高解析的准确性，避免了域名劫持的风险。当然这种模式也有一些问题，例如客户端每次加载URL都可能产生一次HTTP DNS查询，这就对性能和网络接入要求很高。

302调度

基于客户端 IP 和 302 调度集群进行实时的流量调度。

我们来看一个例子：

• 访问 URL 链接后，此时请求到了调度群集上，我们能拿到的客户端信息有 客户端的出口IP（绝大多情况下是相同的），接下来算法和基于 DNS 的调度可以是一样的，只是判断依据由 local DNS 出口 ip 变成了客户端的出口IP。
• 浏览器收到302回应，跟随 Location 中的 URL，继续发起 http 请求，这次请求的目标 IP 是CDN 边缘节点，CDN节点会响应实际的文件内容。

image.png

302 调度的优势：

• 实时调度，因为没有 local DNS 缓存的，适合 CDN 的削峰处理，对于成本控制意义重大
• 准确性高，直接获取客户端出口 IP 进行调度

302 调度的劣势：

• 每次都要跳转，对于延时敏感的业务不友好。一般只适用于大文件。

AnyCast BGP 路由调度

基于 BGP AnyCast 路由策略，只提供极少的对外 IP，路由策略可以很快的调整，

目前 AWS CloudFront、CloudFlare 都使用了这种方式，在路由层面进行调度。

image.png

这种方式可以很好地抵御 DDOS 攻击，降低网络拥塞。

当然这种方式的成本和方案设计都比较复杂，所以国内的 CDN 目前还都是用 UniCast 的方式。

1. TCP Over AnyCast
   https://engineering.linkedin.com/network-performance/tcp-over-ip-anycast-pipe-dream-or-reality
2. AnyCast 原理
   https://www.cnblogs.com/zafu/p/9168617.html
3. 原文章来自我的知乎专栏：
   https://zhuanlan.zhihu.com/c_1150737866299682816