幹壞事是進步最大的原動力
在「nginx 1.9.5：支援 HTTP/2！」這邊提到 nginx 支援 HTTP/2，不過過了一個禮拜，比較知名的 PPA「NGINX Mainline」一直沒更新，維持在 1.9.4 版 (只支援 SPDY)。
這幾天一直找資料，在 chris lea 的 PPA「nginx-devel」這邊看到 1.9.5 的版本，就先暫時改裝了。
裝完後把設定檔裡的 spdy 字串改成 http2 就可以用了，比預期中簡單不少，然後重新啟動後連上去就可以看到藍色 icon 了：
收工解決... (樂)
前幾天 nginx 釋出 1.9.5 版，支援 HTTP/2 (ngx_http_v2_module)：「NGINX Open Source 1.9.5 Released with HTTP/2 Support」。
不過預設是沒有編進去的，需要用 --with-http_v2_module 開起來：
This module is not built by default, it should be enabled with the --with-http_v2_module configuration parameter.
要注意的是，由於是透過 ALPN 實作，需要 OpenSSL 1.0.2 之後的版本：
Note that accepting HTTP/2 connections over TLS requires the “Application-Layer Protocol Negotiation” (ALPN) TLS extension support, which is available only since OpenSSL version 1.0.2. Using the “Next Protocol Negotiation” (NPN) TLS extension for this purpose (available since OpenSSL version 1.0.1) is not guaranteed.
不過 PPA 的 NGINX Mainline 這邊還沒更新到 1.9.5，反正 SPDY 現在的佔有率還是比 HTTP/2 高，再等等吧...
在「Announcing NGINX Plus R7」這邊 nginx 透漏了目前 HTTP/2 的進度。
NGINX Plus 是商業版本，這次將釋出 HTTP/2 功能：
NGINX Plus now provides a fully supported implementation of the new HTTP/2 web standard. NGINX Plus can be deployed as a front-end HTTP/2 gateway and accelerator for both new and existing web services.
而 open source 版本也將會在 NGINX Plus R7 版釋出後放出：
Based on user testing from the alpha-level patch, and with the early support from corporate co-sponsors Automattic and Dropbox, the final open source version of HTTP/2 will become available following the release of R7.
如同之前提到的，nginx 的實作上會將 HTTP/2 與 SPDY 分開，所以 package 是分開的：
HTTP/2 support is available in the optional nginx‑plus‑http2 package only. The nginx‑plus and nginx‑plus‑extras packages provide SPDY support and are currently recommended for production sites because of wider browser support and code maturity.
至於 open source 版本會怎麼規劃就等看看了...
Adobe 的 Typekit 宣佈之後的 embed code 預設就會是 HTTPS only：「Font loading update: All HTTPS, all the time」。
主要的原因是出自於最近發現的安全問題，攻擊者可以藉由字型處理的 security issue 攻擊，而導入 HTTPS 後可以降低這部分的風險：
We’ve made this change as a response to the recent vulnerabilities and exploits in the OpenType and TrueType font formats. A malicious attacker could use these vulnerabilities to modify a Typekit font while it is being transmitted from our servers to your browser. Serving fonts (and other resources) over HTTPS ensures that the communication channel between your browser and our servers is not compromised and fonts are delivered in a secure way.
就目前看起來，use.typekit.net 還是使用 EdgeCast 的 CDN 服務，在 HTTPS 上還是沒有 SPDY 或是 HTTP/2，對效能的影響還是要測試過才知道...
CloudFlare 宣佈開始測試 HTTP/2 了：「Test all the things: IPv6, HTTP/2, SHA-2」。
網站是 https://http2.cloudflare.com/，如果有裝 HTTP/2 and SPDY indicator 的人應該會看到藍色的閃電：
原來的站則是綠色的 SPDY/3.1：
接下來就是花時間等待了。
在使用 CDN 前，先考慮上 SPDY 或 HTTP/2 (i.e. 全站 HTTPS)，改善的效果跟 CDN latency 帶來的效益有得拼。尤其是 server 放在美國機房的情況，SPDY 與 HTTP/2 帶來的效能提昇是相當明顯的。
會寫這篇是因為這兩個禮拜意外被問到好幾次，所以來整理幾家如果讓我來選，我會選擇的 CDN。至少再被問到的時候可以直接從這邊開始說明。
下面的圖是從我家裡 HiNet 光世代測試的結果 (最後是走兩條電話線)，所以會有個 10ms 的 latency 基底，如果要計算 latency 的效能影響請考慮進去。
先講 Akamai。
Akamai 的歷史很久了，再加上併購了不少公司，所以產品成熟度很夠，你要什麼產品都有提供，只要拿的出錢就可以。
KKBOX (敝公司) 用過 PMD、DSD、DSA 三個產品，其中 PMD 與 DSD 只有保障服務可靠度 (availability)，DSA 還有保障效能提昇 (performance)。早期是用 PMD + DSD，現在改用 PMD + DSA。
在功能面上，雖然 Akamai 是大公司，但各種新功能跟的蠻快的。主要就是為了 SPDY 以及之後預期會有的 HTTP/2 而選了 DSA，另外也剛好有效能提昇 SLA 需求而一併升級。
品質上來說，Akamai 在全球的點 (PoP) 夠密集 (差不多是有 ISP 機房就會放)，當初會選擇 Akamai 是為了敝公司在泰國與馬來西亞兩個地區的用戶，而 PMD 在這兩個地區的品質都還不錯。
在台灣也有好幾個點，但除非你買的產品線等級夠高 (i.e. 合約有保證 performance，像是 DSA)，不然平常不會分到台灣的點，以最近的情況來說是深夜才有機會指回台灣。
這是 Akamai DSD 的圖：
而這是 DSA 的圖：
可以看得出來 latency 的差異。
在 SLA 的部份，是目前少數有提供保證 100% availability SLA 的 CDN。
成本考量上，價錢是最硬的，但由於 CDN 這個領域競爭得很激烈，只要超過某一個 commit level 後有機會壓到跟 CloudFront 拼的價錢，也就是說，有經濟規模就有機會在台灣變成重點客戶而坐下來談價錢 (不確定多少，但 CloudFront 的第一個級距 10TB/month 應該是基本吧)。
另一方面，因為透過業務談價錢，會需要開會討論，所以對使用方的人力成本偏高。不過因為如此，台灣有 Akamai 辦公室與經銷商，稅務會比較好處理。(參考：「零壹科技正式代理Akamai 推展雲端優化服務解決方案」)
總結來說，適合已經有量，而且台灣是重要客群的公司。
再來講 EdgeCast。
EdgeCast 的功能比 Akamai 少很多，自從被 Verizon 買進去後就沒推出什麼比較有趣的產品了 (參考「Verizon 打算買下 EdgeCast...」)，感覺上是電信公司買來補產品線的啦，所以也不用太期待之後會有什麼新產品推出來...
比較特別的是 EdgeCast 跟 HiNet 有合作 (參考「EdgeCast 與 HiNet 合作...」)，所以也是少數在台灣有機房的 CDN 業者。在台灣的 PoP 據說是在高雄 HiNet 機房內：
另外 EdgeCast 有 Network Map 可以看在全球有哪些 PoP。
價錢上聽朋友說比 Akamai 低了不少，不過自己沒經手過無法確認。同樣是透過業務談，所以也有類似的人力與稅務優缺點。不過據說也可以直接 bypass 國內的業務，直接跟國外談，不過這樣搞境外稅務的問題就要自己解決了。
綜合來說，也是適合已經有量，由於沒有 SPDY 與 HTTP/2，就看 PoP 的點決定合不合用。
Amazon CloudFront 算是很多 startup 的第一嘗試，no commit 以及帳單在同一張可以省下不少功夫。
在 CloudFront 上分成三個不同等級的產品，通常下載用可以拿 Price Class 100 (只有北美與歐洲的 PoP)，而真正要加速用的再拿 Price Class All 用。
而功能面上，CloudFront 的功能說不定還比 EdgeCast 多，不過還是沒支援 SPDY 或 HTTP/2，所以基本上是靠台灣的 PoP 在撐 latency 的。而台灣的 PoP 據說在內湖：
價錢在官網上就擺出來給大家看了，比較大的缺點是不同區域是分開算錢的，不過是可以找台灣的經銷商談 commit level 包價錢啦，不過價錢還是很難談。
綜合來說，適合 startup 用。
CloudFlare 也是很多人問的一個選擇，不看流量價錢固定是賣點之一。
功能非常多，SSL certificate 涵蓋在所有產品內，另外也是目前少數支援 SPDY 的 CDN。技術上是走 Anycast 而非 GeoDNS dispatch。
HiNet 過去的品質爛到爆炸 (重點在於會 packet loss)，也常常是被 DDoS 的目標。台灣其他的 ISP 過去大多都是到日本機房，但 HiNet 會到香港機房，而 HiNet 的這條線路相當壅塞：
主要還是靠 SPDY 的能耐硬是把效能撐到「堪用」的程度，而 CloudFlare 遇到 DDoS 時就慘了。
價錢也是公開的，但以商用水準的品質來說，已經低到及格線以下了...
綜合來說，自己玩玩的東西還可以啦，任何商業性質的網站都不應該單獨用 (與其他 CDN 服務動態偵測服務搭配著用還加減可以用用)。所以目前看到用最多的服務就是內容農場 (Content Farm) 在用，為了節省頻寬與伺服器的負荷，不太在意品質。
最後補充在台灣有機房的 CDN 業者：(按照字母排，可能有漏)
Tony Hunt 在「We’re struggling to get traction with SSL because it’s still a “premium service”」這篇文章裡抱怨了目前 web 要朝向 HTTPS only 還很遠，甚至還酸了一下 Let's Encrypt 冨樫問題：
可是東尼... 你的站也沒上 HTTPS 啊 :/
順便整理一下目前 HTTPS 技術發展出來的優點：
現在網站的 best practice 是 HTTPS + HTTP/2，對 SEO 好、速度又快 (這兩個對營收有影響)，而另外也可以增加安全性 (對聲譽有幫助)。
nginx 宣佈了 Early Alpha 的 HTTP/2 支援：「Announcing an Early Alpha Patch for HTTP/2」。
除了警告這是早期版本不應該用在 production 上，另外也說明了目前的 patch 會讓 SPDY 失效：
Applying this patch removes the SPDY module from the NGINX codebase and replaces it with the HTTP/2 module. After applying this patch, you can no longer configure NGINX to use SPDY.
而在這之後也不會讓 HTTP/2 與 SPDY 同時並存：
This will also be the case for the production-ready release of the HTTP/2 implementation in both NGINX and NGINX Plus. SPDY is being deprecated by Google in early 2016, so there is no need to support both.
但從 HTTP/2 的支援度與 SPDY 的支援度來看，行動裝置都還不支援 HTTP/2，但 iOS 8.4 以及 Android 3+ 都已經支援 SPDY 了，這樣看起來非常的傷啊...
不知道到年底會有什麼其他解決方案出現...
Adobe Typekit 宣佈支援 CJK 字型：「Announcing East Asian web font support and new font browsing tools for Japanese customers」。中文的公告在「正式公開東亞網頁字體支援以及日文客戶適用的全新字體瀏覽工具」這邊。
這也包括了網頁版的部份。對於 CJK 單一字型檔案過大的問題，與大家的解法也都一樣，取出對應的字組出來給使用者作為 workaround (稱為 Dynamic Subsetting)：
會稱為這是 workaround 是因為當網路速度愈來愈之後，就會又變成最單純的直接整包下載...
Anyway，Adobe 這個新功能是一個大邁進，不過他用的 HTTPS (EdgeCast) 還沒支援 SPDY 或是 HTTP/2 啊... :/
QUIC (Quick UDP Internet Connections) 是 Google 發明的協定，主要是希望改善 TCP + TLS 的反應速度，目前是用來加速 Google Chrome 與 Google server 之間的連線。
與 SPDY 或 HTTP/2 不同的地方在於使用了 UDP，這降低了 TCP packet loss 造成的壅塞現象，以及 TCP 3-way handshake 的成本，而這兩點在行動平台上都特別明顯。
依照最新的說法，目前 Google Chrome 連到 Google server 大約有一半的連線會走 QUIC：「A QUIC update on Google’s experimental transport」。
Today, roughly half of all requests from Chrome to Google servers are served over QUIC and we’re continuing to ramp up QUIC traffic, eventually making it the default transport from Google clients — both Chrome and mobile apps — to Google servers.
而在 YouTube 的改善也很大：
These benefits are even more apparent for video services like YouTube. Users report 30% fewer rebuffers when watching videos over QUIC. This means less time spent staring at the spinner and more time watching videos.
由於效果不錯，他們打算要換更多...