最近有Webluker的用户在自己的博客上发贴称：Webluker的CDN不是根据客户机IP判断客户所在位置，而是根据客户的LDNS来判断客户所在位置，真是滑稽之至。用户说的根据LDNS来判断而不是客户机IP确实如此，但滑稽确实有些“冤枉”Webluker了。下面我阐述一下CDN给出解析IP的原理来给Webluker”平反”一下，呵呵。
假设有网站www.a.com，此网站要使用CDN有目前多采用以下两种办法：
1 将www.a.com CNAME 至 CDN服务商指定域名；
2 将www.a.com NS 指向CDN服务商指定的DNS服务器；
这两种方法都是通过域名解析环节将解析权交给了CDN服务商的DNS服务器，然后又有两种方法进行下一步的调度：
a 根据客户请求的LDNS判断客户所在位置，给出合适的CDN节点IP，然后客户的请求就被引导到CDN Cache节点了；
注意此环节因为是解析环节，只能获取LDNS的IP，无法获取客户机IP，所以只能通过LDNS判断客户位置，此方法的优点是解析快速，调度引导过程快速，缺点就是少数情况下客户设定的LDNS与客户机的IP所属区域不同，这样不能准确判断客户位置。
b 直接给出一个CDN服务商的IP，此IP对应一个Web Server，这样客户机可以与此IP建立Http连接，Web Server获得客户机的真实IP后判断客户位置后返回一个302跳转（此跳转URL里含有Cache节点IP地址）给客户机，客户机再与跳转后的URL重新建立连接，从而将客户的请求引导到Cache节点。
此方法的优点是能获得客户机真实IP地址，判断客户位置更加准确，但调度速度较前一种慢很多。由于LDNS与客户IP不属同一区域情况比较少，所以多数CDN服务商一般情况都采用a方案，只有在大文件的下载是才采用b方案。
另外，还有一种CDN实现方式是将www.a.com直接指向CDN服务商的代理服务器，代理服务器后端挂多个Cache设备，客户机直接与代理服务器建立Http链接，代理服务器转发请求和响应结果。但这样的架构在CDN这样通用型大流量的应用上极易出现代理服务器单点故障，一般CDN应用很少采用这样的实现方式。
总之，任何技术都不是极端理想的，总是在特定的需求和应用下有一些权衡和折中的。