CDN调度策略介绍

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 的方式。