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