莫让CDN服务成为小网站的瓶颈

昨天晚上我在学校的机房上网（教育网），不自觉地打开了我的博客。因为刚刚给博客部署了新买的CDN服务（只为附件服务器部署），而且购买的CDN服务有教育网节点，所以我心想，我的博客的访问速度一定可以如飞喽。但事与愿违，博客的打开速度不仅没有提升，反而变慢了许多。而且通过浏览器的状态栏不难发现，载入时间最长的就是img.mawenjian.net域名下的资源，也就是部署了CDN服务的部分。

那么，这是什么原因造成的呢？

我首先从本地网络开始查起。我用的PC使用的线路是教育网的百兆共享，使用迅雷开下载，即使在忙时速度依然可以达到2~3MB/s。所以，瓶颈肯定不在本地网络这儿。

难道是因为CDN把我分到了一个非教育网的节点？我通过查询img.mawenjian.net域名所指向的IP归属及使用ping命令后发现，CDN并没有分错节点，而且本地PC到该节点的延时只有4ms。所以问题也不在这里。

不是节点的问题，那应该是源站的问题喽。但是我的www网站和img.mawenjian.net的源站使用的是同一个IP，我本地PC打开www网站速度流畅，这就说明了不是因为源站点拥塞而造成的。

既然前三个猜想都不是出现瓶颈的因素，那么原因只有一个——CDN节点！尽管这个结论有点让人难以相信，但是事实摆在眼前，不得不接受啊。可能你听到这里有些糊涂了，怎么就是CDN节点产生的瓶颈呢？且听我一一道来。

首先需要从CDN技术的原理说起。CDN的原理嘛，说白了就是缓存，即将内容缓存在离用户较近的节点上。当用户需要获取内容时，只要从距离“最近”的节点获取即可。因为这个“最近”的节点往往和用户位于同一网络，物理位置距离较近，带宽又比较充足，所以速度较快，给人以一种被加速的感觉，所以有时候也将CDN技术叫做“CDN加速”。

从我上面的表述中不难发现，CDN加速能否成功，很大程度上依赖于CDN节点上是否有要获取内容的缓存。而缓存内容是怎么获得呢？是当有用户访问该内容后产生的。如果该内容没有被缓存，CDN节点则需要作为客户端向源站点请求数据。

因为我的博客访问量实在太小了，以至于造成缓存的命中率很低（教育网节点更是接近于0），进而CDN节点频繁回源取数据。在我打开我的博客的过程中，CDN节点其实是在进行2个操作，即从源站点取数据和将取到的数据传送到我本地PC。这样一去一来，实际上CDN节点的流量是乘以2的。由此可见，CDN节点对带宽的要求是很高的。但是因为我的上网时段处于上网高峰期，CDN节点带宽紧张（可能跑满了）；而且我的源站点位于非教育网，但是教育网节点回源时却使用教育网线路，此时就会面临因互联互通问题造成的传输时间变长，进而形成了上述问题——使用CDN的资源比没使用CDN的资源还慢。

通过这个事情我们得出了一个结论，即在使用CDN技术时，不要盲目相信多节点，也不要盲目相信多线路，CDN节点的选择很重要。一旦CDN节点选择不慎，很容易出现问题。比如我原先使用的盛大云DDS，虽然节点数不多，而且没有教育网节点和线路，但是带宽充足，教育网方面的表现却比上述CDN服务要好的多。又比如我曾经使用的某免费CDN，因为带宽有限，所以经常出现文件加载不完全的现象，非常影响用户体验。

另外，对于小站点而言，尽量使用BGP线路或者多线线路来代替CDN服务，CDN技术的原理决定了CDN对小站的加速作用十分有限。当然，如果支持主动内容推送的话，这种状况可能会有所改观。

最后，使用CDN服务时，恰当的缓存策略很重要。比如不需要经常更新的图片、CSS文件、JS脚本文件等，可以通过设置一个较长的缓存时间来提高缓存命中率。像我购买的上述CDN服务，虽然系出名门，但是因为是从代理处获得的，不能自定义缓存规则，所以无法设定最优的缓存策略。因此，这对于上述问题的产生也是一个不能忽略的重要因素。