指路牌
- CDN
- 网站静态资源加速
- 定量展示CDN加速效果
- CDN配置好了但是没有加速效果？
适用场景
- “第一次接触”用户体验提升
- 网站具有大量图片、css、js等静态资源
- ECS购买了固定带宽，带宽成为性能瓶颈
环境
- 一个已完成“备案”的域名
域名购买后需要实名认证+备案，大概需要花费“14～20天”。
- 开通阿里云CDN服务
参考博客
Web项目聚集地 --- 一文读懂 CDN
阿里云 --- CDN文档
背景
我曾接触过两个项目，一个是基于web的AR项目，一个是使用了大图的展示项目。两个项目都有一个共同特点：加载速度很慢。慢到什么地步呢？页面完全加载完的时间量级均在两位数（10s左右），极端情况下甚至会达到20s甚至更久。
如此打开速度对于一款应用的体验来来说是灾难级的，因为不会有一个用户有耐心等待如此长的时间，web前端针对加载速度慢在技术上具有很多解决方案：如使用一张像素很低体积很小的图片先显示以“安慰”用户，或使用分批加载等。
但以上两种方案都无法解决我碰到场景的问题，因为AR项目的js文件与AR文件都同样庞大，以上方案都不能完全挽救两位数量级加载时间的灾难级体验。
幸运的是两个项目都是展位性质的，只需要利用浏览器自身的缓存机制，提前打开几次页面就能将加载时间将时间轻易降到50ms附近，让观众户完全感觉不到加载的耗时。
但是如此雨来，展示的互动性将变得很受限，因为用户无法使用自己的设备亲自打开体验应用，只能使用讲解员手中提前缓存好数据的设备。
我调研CDN的初衷，也是为了尝试解决以上问题：能够让完全没有缓存用户的设备在“第一次接触”应用时能够较快打开应用，提高互动性。
原理&思路
要解决现有的问题，那么需要先分析一下性能瓶颈到底出在了什么地方。网页加载速度慢的根本原因当然是文件过大，但监控服务器资源占用等参数后我将参数锁定在了两个：地理位置、带宽。
接下来我们就来看看CDN到底能不能实现加速，以及能够加速到什么地步？
步骤
为了确定上面两个问题，我选取了项目中的部分文件作为用例，做了一系列测试，得到三组对比数据如下：
一、境内外ECS对比
- “行”为该文件加载耗时，单位为ms、s
- 时间读取自Chrome控制台
- 禁用了浏览器cache，为了避免误差每次测试前均再一次手动删除缓存图片与记录。
- 每个文件在一个ECS测试3次，因此每个文件一共2组，6个数据。
- AWS的ECS在带宽上远比Ali的ECS高，Ali这的ECS的带宽为固定带宽5Mbps（也即0.625MB/s）。
现象
- 位于奥兰多的服务器和位于张家口的表象不相上下，
- 文件大小达到4MB左右均会开始向10s逼近，
结论：
由于空间位置原因无法获取文件在奥兰多处的加载耗时，不严谨的得出结论：AWS在带宽上弥补了物理距离的差距，二者速度差异不大。
二、在AliCloud的ECS，使用CDN加速与不使用CDN加速对比
C、D、E三列为先前测试数据
F、G、H、I列为使用CDN加速后测试数据
G为同局域网下同事电脑
H、I为使用手机热点4G网络下在另一台设备Mac上的时间表现
现象
- F列为本人PC，具有非常明显的加速效果，
- G、H、I三列均没有任何变快表现，甚至还更慢了......
结论：
- Ali的CDN难道是针对单个IP进行加速，来欺骗消费者的吗？
这个结论当然是错的，但是数据上又呈现出了以上特点，又是什么原因导致的呢？继续往下看
三、在AliCloud的ECS，使用CDN加速，并进行“数据预热”后数据对比
C、D、E为第一组测试数据，无CDN情况下性能表现
F为第二组测试数据，进行CDN加速但无数据预热时在一台新设备上的性能表现
H、I、J为使用CDN加速后，分别在同事G与另外两个完全没有开过网站的设备上打开网站的性能表现。
现象
- 在没有数据预热前，CDN加速基本没有任何提速效果
- 进行数据加热后，文件加载数据明显提升非常多。
结论
- CDN在数据预热后实现了网站加速的效果，对比数据预热前后同事G设备上的性能表现，加速效果大约在5～15倍之间。
从最后的效果效果来看，将文件打开速度由10s级降到将近ms级，确实极大优化了用户“第一次接触”的用户体验，能够让用户有耐心讲应用使用下去，也能够在展位上让观众能够使用自己的设备打开服务，对交互和受众面的提升都具有非常大的好处。
后记
以为这就完了？后面还有内容，量化说明CDN的加速效果并不是这篇文章的主要目的。
“数据预热”这一名词时在CDN的原理文章比较少提到的，在得到第二组测试数据的时候，我就十分困惑的提交了工单，才得知了“数据预热”这一环节。进一步和工程师询问得知，AliCloud的CND默认是抢占式的，就像硬盘与内存的映射关系，使用越频繁，加速内容在冗余站点的存放时间与获取资源也会越多。
因此我的PC所接入的加速站点具有很好的加速效果
而低频或刚添加的资源默认并不会传输到冗余站点，需要在控制台手动进行“数据预热”。且即使预热后，长时间不使用也会从冗余站点抹除，被替换掉。当然，从所支付的费用来说，这一抢占机制是很合理的，毕竟我完成所有测试也只花费了0.26RMB的费用。
在第三组数据中，应该能发现即使数据预热后，加速效果在不同设备间的表现效果也是存在差异的，如在同事C设备上，加载数据都在ms级，而在同事G与与同事L设备上，却是个位数的s级。细心的读者也许会发现，我在CDN设备上面都标注了一个地理信息，我的个人PC是湖北、同事G是山西，同事L与同事C是甘肃。（在第二组数据中由于还不清楚这个概念，当时没有记录）
这些地理位置，是AliCloud冗余加速站点所处的地理位置的信息，这里一个很有意思的现象是，以上所有4台设备都是处在同一个局域网下的4个独立的设备，3台Win，1台Mac，走同一个网关接入因特网，但每一台设备接入的CDN加速站点都不相同！
两个同属甘肃的服务器IP不相同
同一台设备接入的冗余站点始终相同
也因为以上原因，导致他们加速效果存在差异，这一点是让我非常不理解的，为什么同同一个局域网下的设备接入加速站点的位置却有如此大的差异？接入冗余加速站点的规则到底是怎样的？这是我一直没有弄明白的问题，在工单上询问工程后也没有得到明确的回复，姑且只能搁置于此。
####
要获取更多Haytham原创文章，请关注公众号"许聚龙":
原文地址：https://blog.51cto.com/13852791/2432752