昨天晚上测试了加速乐CDN及抗DDoS的功能。具体效果怎么样，大家自己评判吧，我就不点评了。总之老老实实掏钱总是没错的

以下测试为免费套餐、香港节点、NS方式的结果，其他方式不保证通用。

 CDN

主要测试它的缓存策略。加速乐的控制面板中关于缓存的配置非常简单：

就四个勾和四个时间选择，当然对于我们无课金用户来说是够用的。免费套餐不能白名单却能黑名单给人一种很小气的感觉。

缓存的主要策略如下：

  • 开启目录加速后，”/”结尾的uri会进入缓存
  • 默认带query的请求不缓存，如”/test?1=1″不会被缓存
  • css, js等资源会根据扩展名带query缓存，如”/css/main.css?v=1″会被缓存，且与”/css/main.css?v=2″分开缓存
  • jpg, png等图片资源根据文件头带query缓存
  • 404等错误码不缓存，且404页会替换成加速乐的错误页，并带有油腻的世界广告

测一下Ping，看看就好，不服来跑个ping？  和cf比略有优势，平均快20ms。点击放大：

加速乐ping

加速乐ping

Incapsula

Incapsula

Cloudflare

Cloudflare

 

抗DDoS测试

因为4层攻击会打在节点上，无法在源主机上准确观测，这里只测试7层的攻击。测试中特意选了一个干净的域名，没有搜索引擎抓取，没有正常用户，所有请求均为攻击请求。看下结果：

  • WP-xmlrpc：100秒后，总请求数 17782，总流量 893.75MB，网站浏览人数（IP） 2512，遭受攻击次数 31；按每秒200请求数，5分钟左右就将一小时流量3G流量耗尽了（按理说会回源，但并没有在源服务器看到日志，可能是已缓存的页面并不会回源）。6万请求数后，仍然只有182次攻击。但是由于请求了不带query且为”/”结尾的uri，中了缓存，源服务器日志中仅有300多条来自加速乐的fetch请求。如果是带query的uri，后果将会很愉快。加速乐判定这次攻击为“恶意扫描”

 

  • GET：使用压力测试工具进行大规模GET请求，由于UA没有显著特点（之前的WP-xmlrpc有显著的UA特征），将更加难以过滤。减去之前的6万条，这次共有8w次攻击请求，加速乐拦截了1w条。这次测试的uri是一个不存在的页面，因此按照默认策略，全部打到了源服务器上。坑爹的是压测工具关掉之后，仍然收到来自加速乐的fetch请求，高潮又持续了10分钟，可以拍毛片了。

 

 总结

正常的网站就上阿里云/AWS/Azure，奇怪的网站就上Cloudflare；耐打，经艹，值得信赖

ping是用来跑分的，合理安排cache及静态资源很重要

我没收钱