CloudFlare 正式推出 HTTP/2,可以與 SPDY 同時混搭

CloudFlare 推出了 HTTP/2 服務,與其他 CDN 業者不一樣的地方在於,他可以同時接受 HTTP/2 與 SPDY:「HTTP/2 is here! Goodbye SPDY? Not quite yet」。

CloudFlare 拿自家的 www.cloudflare.com 官網測試,顯示 HTTP/2 的效能比 SPDY 又好了不少:

Access via HTTP Protocol Version Average Page Load time
HTTP 1.x 9.07 sec.
SPDY/3.1 7.06 sec.
HTTP/2 4.27 sec.

在正式上 HTTP/2 前,有 80.38% 對 www.cloudflare.com 的 SSL/TLS 連線是 SPDY:

During the week before our HTTP/2 launch, 80.38% of all SSL/TLS connections to our own website at www.cloudflare.com were made over SPDY/3.1.

上線後其實沒有想像中的高:

Protocol Version Percentage of Hits
HTTP 1.x 19.36%
SPDY/3.1 57.02%
HTTP/2 23.62%

這也說明了為什麼 CloudFlare 要推出 SPDY + HTTP/2 的服務:

Why choose, if you can have both? Today CloudFlare is introducing HTTP/2 support for all customers using SSL/TLS connections, while still supporting SPDY. There is no need to make a decision between SPDY or HTTP/2. Both are automatically there for you and your customers.

剛剛連到後台確認,由於本來已經打開 SPDY 的使用者會自動開啟 HTTP/2,這表示全球 HTTP/2 的使用率會馬上拉高很多,有太多資源掛在 CloudFlare 上:(像是 cdnjs.com,剛剛確認也已經是 HTTP/2 了)

If you are a customer on the Free or Pro plan, there is no need to do anything at all. Both SPDY and HTTP/2 are already enabled for you.

Customers on Business and Enterprise plans can enable HTTP/2 within the "Network" application of the CloudFlare Dashboard.

Facebook 因為 Connection Pool 選擇機制,加上系統的複雜性而導致的慘案...

Facebook 的 engineer 寫了一篇文章,說明他們花了超過兩年的時間找到一個 bug:「Solving the Mystery of Link Imbalance: A Metastable Failure State at Scale」。

整個故事是個通靈的故事...

Facebook 在底層的架構使用了 Link Aggregation 的規劃,多條線路 channel bonding 在一起連到骨幹上。但發現有時候會卡在某一條線路壅塞而導致 system failure。

於是就一路追下去,從 switch 本身開始懷疑,最後去組織跨部門的研究小組跳下去分析 (通靈)。後來才觀察到是因為 connection pool 的機制本身用的演算法在 Facebook 這個複雜的系統架構下造成的慘案...

當 query burst 發生時,Facebook 的系統會同時到 50~100 組資料庫撈資料出來寫入 cache,而 connection pool 的機制用的是 MRU (Most Recently Used),從 congestion link 回來的 connection 會在 pool 裡面的最上方,於是就愈來愈塞...

知道問題後,解決的方法就簡單多了。只是把 connection 選擇演算法從 MRU 換成 LRU 後就解決了,但中間用了超過兩年的時間,以及至少 30 個人的努力才把問題找出來並且解決。

可以看到最後銘謝的對象一卡車:

Thanks to all of the engineers who helped us manage and then fix this bug, including James Paussa, Ernesto Ovcharenko, Mark Drayton, Peter Hoose, Ankur Agrawal, Alexey Andreyev, Billy Choe, Brendan Cleary, JJ Crawford, Rodrigo Curado, Tim Eberhard, Kevin Federation, Hans Fugal, Mayuresh Gaitonde, CJ Infantino, Mark Marchukov, Chinmay Mehta, Murat Mugan, Austin Myzk, Gaya Nagarajan, Dmitri Petrov, Marco Rizzi, Rafael Rodriguez, Steve Shaw, Adam Simpkins, David Swafford, Wendy Tobagus, Thomas Tobin, TJ Trask, Diego Veca, Kaushik Veeraraghavan, Callahan Warlick, Jason Wilbanks, Jimmy Williams, and Keith Wright.

最後附上 Facebook 解釋的圖:

AWS Elastic Load Balancing 服務支援 Connection Draining

AWS Elastic Load Balancing 支援 Connection Draining 功能了:「ELB Connection Draining - Remove Instances From Service With Care」。

由於 Connection Draining 是自創名詞,所以 AWS 的人解釋了一大堆。其實對比較熟悉的人用「graceful shutdown」就應該能了解 Connection Draining 想要做什麼事情。

技術上的細節是,當 instance 從 ELB 內被移除 (無論是暫時性的還是永久性的),新的 request 將不會被送到該 instance 裡,而既有的連線將不會斷掉,直到 client 完成或是超時 (timeout)。

這個功能在一般商用的 load balancing solution 都會提供,而且是對於服務品質其實還蠻重要的功能。

話說回來,這陣子 ELB 動了不少東西?不查資料可以直接想到的就包括了:

  • HTTPS 支援 PFS
  • 支援 access log 下載。

再加上今天的 graceful shutdown。每次都改善一些東西,累積起來就是驚人的財產...