一篇读懂「CDN请求过程详解」cdn操作教程cdn入门

CDN简介

CDN大家比较熟悉，这里做个简单介绍。

CDN主要是让用户访问资源的时候，能从离用户距离很近的CDN节点进行获取，不必到真正

提供服务的机器上获取。所以CDN可以

CDN经历了三个阶段

第一阶段 1995年，互联网发明者Tim，创建了第一家CDN服务公司Akamai

第二阶段 1999~2001，互联网发展高潮期，CDN快速发展

第三阶段 2001年互联网破灭，CDN公司大量倒闭，Tim的公司也倒闭了。2002年开始，宽带提升、游戏和视频大发展，带动CDN大发展

CDN虽然经历了二十多年的发展，但是现在还没有形成标准规范，各家的具体实现也不一样，本文章只讲解一种类型，希望能够让大家更深入的了解CDN。

CDN请求过程

CDN的请求过程，大致如下图所示，下面我简单介绍。左侧的实线框是DNS查找阶段，右侧的虚线框是CDN的范围。

DNS查找阶段

用户在浏览器请求某个链接，如event.mi.com，浏览器需要查找该域名对应的ip地址

1.先查找自己机器的DNS客户端上是否有记录，如果没有记录

2.从本地DNS服务器获取，如果本地DNS服务器没有记录

3.从根域名服务器查找（根域名服务器全球共13台），根域名返回com域名服务器所在地址

4.本地DNS服务器从com域名服务器查找，com域名服务器返回event.mi.com的权威域名服务器地址

- 权威域名DNS服务器：包含了该域名的所有信息

5.找到权威域名服务器后，会查到该域名有个CNAME，这个CNAME一般指向CDN的全局负载均衡系统

- DNS的A记录

1）A记录格式为“域名-ip”，记录的是该域名对应的服务器ip地址

2）DNS的CNAMECNAME为域名的别名，一般有两种作用1)多个域名指向同一个服务ip，当服务ip变动时，只需要改一个A记录即可。例如，域名www.abc.com的A记录为1.1.1.1，对于域名mail.abc.com和study.abc.com的别名可以设置为www.abc.com，这样当该服务变更ip地址时，只需要变更www.abc.com的A记录，其他域名无需变动，减少维护成本2)CNAME在CDN上的作用也很重要。将域名挂载在CDN上，需要将该域名的CNAME设置为CDN供应商提供的域名，这样CDN供应商才能通过DNS将流量转移到CDN上。而且域名的CNAME设置为CDN的域名后，该域名的A记录也不能存在了。一般通过nslookup和dig命令，可以查看DNS解析的情况，如下图所示，可以看到域名event.mi.com的CNAME为白山云的一个域名。另外可以看到白山云的域名还有对应的CNAME，这个主要是为了做负载均衡，后面会进行讲解。

3) 本模块讲述的DNS解析是使用迭代查找，DNS还提供递归查找的方法， 大家如果有兴趣，可以看一下两者的差异

CDN阶段

通过上面讲述的DNS解析过程，CDN运营商成功将请求转移到他们那里

1.CDN的全局负载均衡系统实现方式很多，这里讲述使用的比较普遍的方案，基于DNS的全局负载均衡系统。

2.客户端请求CDN区域负载均衡系统，该系统会确定提供服务的CDN缓存服务器。区域负载均衡系统一般使用动态策略，为此需要有单独的服务器来收集区域内CDN缓存服务器的各种信息（如会话能力、往返时间、流量、缓存所在位置等）

3.如果区域负载均衡系统提供的CDN缓存服务器没有缓存或者缓存失效，则会向上一级CDN缓存服务器进行请求，一般使用的协议有ICP/HTCP/CARP等。当然，判断缓存失效使用的是Web基础知识，Pragma、 Expires、Cache-Control、Last-Modified、Etag等

4.如果上层的CDN缓存服务器仍然没有缓存或者过期，则会到回源机上请求该文件，请求成功后进行缓存

CDN使用过程中的一些问题

CDN对抗高并发的情况是很有用的，可以参考这篇文章《常用缓存技巧》

但是使用CDN的时候，也可能遇到一些问题，在这里我给大家讲述一些我曾经遇到的问题

获取文件时间超长

最近遇到一个问题，通过CDN获取50KB的图片，耗时120s。

发生这种情况的原因是CDN厂商负载均衡配置有问题，在错误的配置下，为了拿到该图片，需要经过半个地球。后来让CDN厂商修改配置后，只需要0.2s。

获取到错误文件

商品需要有产品站，产品站会引用js文件，每次产品站变更，js名称不变，但js的tag会变，如从base.js?v01变为base.js?v02。js文件设置的是永不过期，如果版本号变更，则会回源，这是前提。

如果产品站和js版本不匹配，产品站会产生一些错误，如打不开页面或者某些功能无法使用。产品站和js不匹配有两种情况

1.产品站为新版本，js为老版本

这种情况一般是因为发布的时候，没有先将js发布到回源机上，而是先发布了新的产品站，这样新的产品站请求新的js时，会请求到回源机，而回源机还是老版本，这样老的js被当做新的js缓存了。这种情况发生后，一般生成新的js版本，重新走一次发布操作。

2.产品站为老版本，js为新版本

这种情况产生的原因比较多，也往往比较难以处理。发生这种情况的一个前提是已经发布新的js到回源机上，老的产品站还没有发布

请求大量回源

这种情况发生后，往往会将服务器压垮。发生这种情况的原因是因为大部分CDN服务商，判断命中CDN的方式是根据整个url，如果该url通过google广告等推广，后面会添加不同的后缀，会无法命中。阻止这种情况的发生，可以让运维帮忙做特殊配置，只有指定的query参数变化才回源(运维很可能不想做这种操作，因为不利于后期维护)，或者提升自己的服务性能。

最后

大家如果喜欢我的文章，可以关注我的公众号（程序员麻辣烫）

1. 记博客服务被压垮的历程

2. 常用缓存技巧

3. 如何高效对接第三方支付

4. Gin框架简洁版

5. 关于代码review的思考

资料

一篇读懂「CDN请求过程详解」cdn操作教程cdn入门