免费的cdn静态资源加速服务

发表于 更新于 分类于 Waline：

什么是CDN？

cdn的全称:Content Delivery Network或Content Ddistribute Network，即内容分发网络

目的是解决因分布、带宽、服务器性能带来的访问延迟问题，适用于站点加速、点播、直播等场景。使用户可就近取得所需内容，解决 Internet网络拥挤的状况，提高用户访问网站的响应速度和成功率。控制时延无疑是现代信息科技的重要指标，CDN的意图就是尽可能的减少资源在转发、传输、链路抖动等情况下顺利保障信息的连贯性。CDN就是扮演者护航者和加速者的角色，更快准狠的触发信息和触达每一个用户，带来更为极致的使用体验。

参考：百度百科

为什么用CDN

今天在上 blog 时，发现网页加载奇慢，打开控制台发现是谷歌的字体库出现请求超时，然后 ping了一下字体库的服务器，也是出现请求超时。于是萌生了转向 国内免费cdn加速服务的想法，百度上也有很多，但都不是我的理想选择，然后在一个论坛上看到一个奇葩域名：sb.sb，点进去是一个提供国内加速服务的网站，托管了 CDNJS 的所有开源 JS 库以及反向代理了 Google Fonts、Ajax 和 Gravatar，这一点很令人激动，即解决了字体库的问题，顺手还可以解决因服务器波动而带来的脚本加载超时的问题，一举两得。

ping测试 fonts.cat.net 的传输速度:

1
2
3
4
5
6
7
8
9
10
正在 Ping all.cat.net.w.kunlunpi.com [123.6.7.31] 具有 32 字节的数据:
来自 123.6.7.31 的回复: 字节=32 时间=19ms TTL=45
来自 123.6.7.31 的回复: 字节=32 时间=20ms TTL=45
来自 123.6.7.31 的回复: 字节=32 时间=21ms TTL=45
来自 123.6.7.31 的回复: 字节=32 时间=19ms TTL=45

123.6.7.31 的 Ping 统计信息:
    数据包: 已发送 = 4，已接收 = 4，丢失 = 0 (0% 丢失)，
往返行程的估计时间(以毫秒为单位):
    最短 = 19ms，最长 = 21ms，平均 = 19ms

来对比下国内bootCDN的开源项目加速服务：

1
2
3
4
5
6
7
8
9
10
正在 Ping nm.cun.aicdn.com [211.91.140.66] 具有 32 字节的数据:
来自 211.91.140.66 的回复: 字节=32 时间=37ms TTL=52
来自 211.91.140.66 的回复: 字节=32 时间=37ms TTL=52
来自 211.91.140.66 的回复: 字节=32 时间=35ms TTL=52
来自 211.91.140.66 的回复: 字节=32 时间=37ms TTL=52

211.91.140.66 的 Ping 统计信息:
    数据包: 已发送 = 4，已接收 = 4，丢失 = 0 (0% 丢失)，
往返行程的估计时间(以毫秒为单位):
    最短 = 35ms，最长 = 37ms，平均 = 36ms

hexo默认的jsdelivr.net的加速服务

1
2
3
4
5
6
7
8
9
10
正在 Ping 1stcnsniwebmw.dtwscache.ourwebcdn.com [218.29.50.51] 具有 32 字节的数据:
来自 218.29.50.51 的回复: 字节=32 时间=25ms TTL=55
来自 218.29.50.51 的回复: 字节=32 时间=26ms TTL=55
来自 218.29.50.51 的回复: 字节=32 时间=24ms TTL=55
来自 218.29.50.51 的回复: 字节=32 时间=26ms TTL=55

218.29.50.51 的 Ping 统计信息:
    数据包: 已发送 = 4，已接收 = 4，丢失 = 0 (0% 丢失)，
往返行程的估计时间(以毫秒为单位):
    最短 = 24ms，最长 = 26ms，平均 = 25ms

看往返时间损耗很明显是 cat.net 更胜一筹，于是果断都换了链接，加载速度虽然相差不大，但至少可以实现全球加速，解决了一个隐患。

总结

经过一段时间的使用我还是推荐使用 cat.net 的加速服务，因为趁现在使用人数还不多，可以免受网络拥堵带来的漫长等待，关键是人家拥有庞大的静态资源库而且还免费全球加速，当然你也可以使用其他站点提供的加速服务，例如bootCDN，百度，jsdelivr等等，最好是使用https链接，免受资源被劫持后插入危险代码的风险。