幹壞事是進步最大的原動力
在「A List of Free Public CDNs for Web Developers」這篇文章裡面列出了網路上免費的 CDN 資源。
可以看到 MaxCDN (jsDelivr、OSSCDN、jQuery CDN) 與 CloudFlare (cdnjs) 都投資了不少在其中。不過 MaxCDN 的部份都沒有拿出亞洲 PoP 來用，速度還是慢了不少...
對於有使用各種套件的人，可以在這邊的列表上找一找，除了可以節省自己機器的頻寬負擔外，另外用 CDN 也有機會與其他人共用 cache 而加速...
在 CloudFlare 的官方 blog 上的公告：「CloudFlare Now Supports WebSockets」。
於是 CloudFlare 自豪的 DDoS 防護服務也涵蓋到 WebSockets 了：
The ability to protect and accelerate WebSockets has been one of our most requested features.
裡面其實還提到一些 CDN + WebSockets 的技術問題 (像是 port 的數量)，有興趣的可以再仔細看 :o
今年一月的時候 CloudFlare 宣佈針對使用 TLS 1.1+ 的使用者停用 RC4：「Killing RC4 (softly)」。
而現在 (五月) 則直接從 cipher priority 上拔掉 RC4：「Killing RC4: The Long Goodbye」。
切換後的資料其實非常有趣：
可以看到本來用 RC4 的有兩塊，一塊是 ECDHE-RC4，一塊是 RSA-RC4。在 RC4 被拿掉後，就流竄到 ECDHE-AES-CBC 與 RSA-AES-CBC... (這兩個本來就可以預期)
但冒出 RSA-3DES 是怎樣 XDDD
Anyway，CloudFlare 在目前市場上算是很大的 provider，由他們出面率先拔掉 RC4 會對整個市場有正面的影響。接下來看看還有誰會動手？
最近幾天 NTP 放大攻擊還蠻嚴重的，像是 CloudFlare 這兩天就被 400Gbps 貓：「NTP-based DDoS attacks a concern, says Cloudflare」。
CloudFlare 有寫過一篇 NTP 放大攻擊的說明：「Understanding and mitigating NTP-based DDoS attacks」。
另外在 irc 上看到系上學弟說可以查詢有哪些 NTP server 是會被當作 NTP 放大攻擊的工具：「OpenNTPProject.org - NTP Scanning Project」，把 IP range 丟進去就可以看到 (一次可以查到 /22)，可以當作一份外部資訊來幫助內部優先處理。
Imgur 宣佈支援 HTTPS：「100 million uniques, higher upload limits, and HTTPS support」。
以這張 https://i.imgur.com/X3L4U.jpg 範例：
同樣的 https://i.imgur.com/X3L4U.jpg 也會動，所以之後就可以使用 //i.imgur.com/X3L4U.jpg。
看了 DNS 記錄，目前 i.imgur.com 是透過 CloudFlare 的 CDN 加速。
Netcraft 從 2012 年 11 月開始偵測 OCSP 的 availability，然後發現各家 OCSP 的穩定性都不太好：「Certificate revocation and the performance of OCSP」。
OCSP 是 Online Certificate Status Protocol 的縮寫，當 HTTPS 連線建立中，client 可以透過 OCSP 詢問這份 certificate 是否有效。這是 PKI 架構下的事後補救機制，因為已經發出去的簽名是無法被收回的，只好靠連線時再查詢。
另外一個機制比較舊，叫 CRL (Certificate Revocation List)，則是屬於清單類的機制，更新速度比 OCSP 慢。
目前是以 OCSP 為主，而舊的平台 (就是 XP 上的 IE) 則只支援 CRL。
可以看到 OCSP 檢查打開後對於速度的影響，有的影響很明顯，有的還好。而原文下面很多張 uptime 圖表也可以看出來各家 OCSP 的穩定性其實不怎樣，有些是直接上 Akamai 解決，有些是上 CloudFlare 解決 (然後遇到幾次 CloudFlare 爆炸就跟著炸 XD)
目前瀏覽器大多都是 soft-fail，也就是查不到就當作 pass。照目前的穩定性要推動 hard-fail (查不到就 break) 應該是頗有難度...
對於 HTTPS 速度很在意的人可以看一下內文的說明，可以挑 OCSP 速度比較快的幾家簽，對速度會有幫助...
CloudFlare 是一種 CDN 服務，相較於其他 CDN 會被歸類到 Akamai 的 Dynamic Site Accelerator，Limelight Networks 的 Dynamic Site Platform，或是 EdgeCast 的 Application Delivery Network。
這類型的 CDN 加速服務，如果用在完全沒有考慮最佳化的網站上，效果應該會很明顯。但如果拿到 WordPress 或是其他 open source 軟體上，反而會因為軟體已經做了不少處理，上了 CloudFlare 反而因為多了一層而變慢。
不過會變慢多少呢？有人跳下去測試寫報告了：「Cloudflare Showdown」，如果懶得看中間的數據，可以看最後的結論「Conclusion」。
如果用在已經最佳化過的網站上，用 CloudFlare 會慢不少，如果是 WordPress 及其他 open source 軟體，最好的情況是快一點點，但最差的情況會慢個幾倍... 作者下的結論是「不要用」。
跟預期差不多，動態資料的加速基本上是個商業包裝而已，真正需要加速還是得自己把可以 cache 的部份切割出來。
之前曾經提過 BootstrapCDN，不過我不是很喜歡用。主要的原因包括 netdna.bootstrapcdn.com 所使用的 CDN 在是不包含亞洲範圍 (會需要到美西抓)，加上之前因為換 url 結構結果本來的 url broken...
cdnjs 是之前就知道的服務，剛剛看了一下發現東西愈來愈完整了... 雖然名稱裡是放 js，但實際上上面放的 Bootstrap 是完整的：
//cdnjs.cloudflare.com/ajax/libs/twitter-bootstrap/2.2.2/img/glyphicons-halflings.png
//cdnjs.cloudflare.com/ajax/libs/twitter-bootstrap/2.2.2/img/glyphicons-halflings-white.png
//cdnjs.cloudflare.com/ajax/libs/twitter-bootstrap/2.2.2/css/bootstrap.min.css
//cdnjs.cloudflare.com/ajax/libs/twitter-bootstrap/2.2.2/css/bootstrap.css
//cdnjs.cloudflare.com/ajax/libs/twitter-bootstrap/2.2.2/css/bootstrap-responsive.min.css
//cdnjs.cloudflare.com/ajax/libs/twitter-bootstrap/2.2.2/css/bootstrap-responsive.css
//cdnjs.cloudflare.com/ajax/libs/twitter-bootstrap/2.2.2/bootstrap.min.js
//cdnjs.cloudflare.com/ajax/libs/twitter-bootstrap/2.2.2/bootstrap.js
剛剛在 CloudFlare 官方的 blog 上看到介紹 cdnjs 有點意外：「CDNJS: The Fastest Javascript Repo on the Web」。
翻了翻 cdnjs.cloudflare.com，看起來是包含亞洲的點，在 HiNet 與 TWGate 上測試是導到香港的點，應該會用用看吧。至於其他 Google Hosted Libraries 有提供的應該是會用 Google 的服務，畢竟是直接從台灣的機房供應的...
