共计 2531 个字符，预计需要花费 7 分钟才能阅读完成。
指路牌
- 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 原创文章，请关注公众号 ” 许聚龙 ”: