HTTP/2

原文網址：http://www.integralist.co.uk/posts/http2.html

---

引言

這是一篇很簡短的文章，展示如何利用新的 HTTP/2 通訊協定。如果你不熟悉它，那麼讓我花一點點時間來討論其中的一些亮點：

• 單一、持續的連線
• Multiplexing
• 壓縮 header
• 優先等級
• 加密
• Server Push

如果這些功能對你而言都不知所云，讓我作進一步的解釋……

持續連線

在 HTTP/1.x，web 頁面上每個 resource 都需要各自的連線。如果一個頁面上有三張圖片、就會分別產生三個連線。

在 HTTP/2 會用單一的連線搭配 stream 的概念來改善這個狀況。stream 是一個有效率的雙向通道，資訊可以透過 stream 往上或往下傳遞；一個連線在有需要的情況下也可以管理多個 stream。

以前為了效率而發展出的這些技術就不再需要了：

• domain sharding：解決 browser 對同一個 domain 的並行連線數量限制。
• 影像 sprite：將多個影像合併成一個，以減少 server 連線數量。
• 串接 CSS / JS：將數個 CSS / JavaScript 檔案組成單一檔案，以減少 server 連線數量。

這也代表 browser 可以更精準處理 resource 的 cache，因為已經沒有必要把 static resource 綁在一起。這也避免使用者下載他們不會用到的東西。

Multiplexing

簡單地說，就是單一連線可以同時承載多個 resource。這是個很棒的效能改善、在大量傳輸 resource 時也能比 HTTP/1.x 管理的更好。

壓縮

header 資訊不會用純文字的方式傳送了。現在會壓縮讓它更小、接收 response 的速度也更快（雖然這點公認只是個邊際效益）。

這也代表我們應該不用在那麼擔心「把 static resource 挪到 cookie-less domain 上」這件事情。這曾經是個問題，因為要包含 cookie 的資料，所以 static resource 會統統變大許多。

優先等級

因為用了 multiplexing 的方式讓所有連線變成一個連線，我們需要一個方法讓某些 request 有比較高的優先度，以確保它們可以比其他 resource 更快被存取到。HTTP/2 可以設定每個 stream 的權重（stream 的觀念參見上面「持續連線」的部份）。

我不打算深入到設計的細節中。只能說：如果你想知道藏了一堆魔鬼的細節，我建議你到這裡讀規格文件。

SSL / TLS

上述的亮點暗示了在 SSL / TLS 的 handshake 流程上也降低了整體的時間耗用。原因如下：

• 單一連線會將 client / server 之間的 handshake 次數降低到最低。
• multiplexing 允許用非同步的方式處理 request。
• 壓縮過的 HTTP header 讓連線更小（也就更快）。
• 有優先等級的連線會以適當的順序處理有關的 request。

Server Push

在 HTTP/2 的規格中，client 發出最初的 HTTP request 之後，server 可以送出額外的資訊。下面這件事情很重要：server push 與 server-sent event 是不一樣的技術。

server-send event 讓 server 可以推送更新給 client；而只要 client 有監聽相關的 event，該 client 就能接收到推送的通知。

server push 是不一樣的東西、解決不一樣的使用情況。使用 HTTP/2 的 server 可以對 client 發送額外的 resource，即使 client 根本沒有要求這些東西。

舉一個經典的例子：當 client request 一個有一些 CSS、JavaScript 等 static resource 的 HTTP 頁面。在 HTTP/1.x，client 會 request 頁面、parse 之後發現這個頁面有包含 CSS、JavaScript。接著 client 必須要另外發出那些 static resource 的 request。

在 HTTP/2 中，server 可以在處理 client 一開始的 request 時就送出全部的 static resource 以省去 client 發出多個 request。

---

後面還有「Implementations」，略過不譯

翻完之後才覺得這篇文章實在是… [遠目]
尤其是 Server Push 的段落實在有點語焉不詳…