昨天晚上測試了加速樂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及靜態資源很重要

我沒收錢