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

什么是CDN?

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

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

参考:百度百科


为什么用CDN

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

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链接,免受资源被劫持后插入危险代码的风险。


✧(≖‿≖)✧ 谢谢您的支持 (●'◡'●)ノ♥
0%