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

我沒收錢