其实也是通过LDNS的具体地址来进行的，比如，看图，假设你是一个广东电信客户，那你所使用的DNS服务器去做递归的时会访问到某一个CDN厂商的GRB，全球的一个调度系统,他就能看到来自于哪个LDNS。假设如果用户和LDNS使用同一个区域的服务器，他就会间接认为用户也是广东电信的。
再举个例子，比如说北京联通的用户，它使用DNS地址，一般自动给它分配的是北京联通的服务器，这个服务器去做递归的时候，调度服务器就会看到这个请求是来自北京联通的LDNS服务器，就会给它分配一个北京联通的服务器地址，然后让来自北京联通的用户直接访问北京联通的服务器地址，这样来实现精准的区域性调度。
从这个调度理论上看，我们可以发现一个问题，就是假设用户所使用的LDNS地址和你是同一个区域，那么这个时候我们的调度才有可能是正确的。但是举个例子来说，如果你是北京联通的用户，可是使用的是广东电信的LDNS的话，就会让GRB系统误以为你是广东电信的客户，这样就会错误的调度过去。
之前有一次我在小区里上网，由于我的路由器有问题，我设了202.106.0.20的北京联通的DNS服务器地址，后来出差去深圳，访问比较大的网站发现比较慢，经过分析，才发现原来我设的DNS地址是北京联通的，而我在广东和深圳使用的网络都是电信接入的，但是分配给我的是北京联通的地址，那我用电信的线路访问北京联通的地址，势必就会很慢。

        因为刚才讲到的DNS调度机制存在一定问题，所以在某些场合下我们会使用第二种调度机制，叫HTTP的调度。
了解http协议的人知道，在http协议中有一个叫302跳转的功能，它的实现并不是说你访问一个URL，然后马上吐给你想要的数据，而是吐给你一个302返回信令，这个信令头部会告诉你，有一个location目标，这个location就是告诉你下一步将要怎么做，而具体调度是通过location来实现的。
即便我所使用的DNS和我不在一个区域，但当我访问http server的时，这个server是由CDN公司提供的。客户访问server的时，虽说通过DNS方式无法拿到客户的真正IP地址，但是如果你访问的是http server，他一定能直接看到客户的真实IP，利用这种方法可以进行调度的纠偏，可以直接返回给你一个302，然后location里面携带一个真正离你最近的CDN server。
这种调度方式，优势是准确，但是也存在弊端，它需要有一次TCP的三次握手建连，他不像DNS那样直接请求一个数据包过去给一个反馈就OK了，他需要一次TCP的三次握手建连。
第二个是你如何访问到http的服务器?如果你之前是通过DNS调度过去的，实际上前边的那个DNS也是省不了，在国内是没有办法做anycast的，也就是没有办法来直接访问一个众所周知的大的IP来进行，所以，一般情况下都是通过DNS来进行第一次调度，然后用http来进行第二次纠偏。这种情况下大家可以想象，如果你下载一个大文件，比如说电影，但你访问的是一个页面小元素，比如说这个图片只有几k，那么，实际上你调度的时间就已占用了很大的成分。实际上，这种302调度是一种磨刀不误砍柴工的方案，如果你后面有很多工作要做，比如要下载一个电影时间会很长，那你调度准确，即使花一点时间调度也是值得的。但是如果你后续访问一下就完了，那么你这样调度就没有太大意义。

        除了DNS调度和http的302调度以外，其实还有一种调度方式，叫http DNS调度，它的原理是通过一个正常的http请求，发一个get的请求，然后再请求里面以参数的形式携带一个我要解析的域名，然后服务器那边去通过数据库查询，查询之后又通过http的正常响应，把这个你要请求的IP通过http协议给你，这种协议有一个特点就是必须双端都支持，因为这种模式是非标准的。没有任何一个RFC文档说，你的客户端或者你的操作系统天生就支持这种机制。这有点类似是一种API的这种方式，那如果要实现的话就必须双端都支持。
一般，第三种调度的应用场景是在手机的APP端，在APP软件里面，你要访问某些东西很有可能被运营商劫持等问题，这个劫持问题后面还有很大的篇幅去讲。那为了避免这种劫持，可能会用到这种http DNS的调度方式。既然APP的程序都是你自己写的，所以说实现这么简单一个API的借口是很容易的。