藉助 HTTP/2 打造更迅捷的 Web 體驗

HTTP/2 的目標

2015 年 2 月，網際網路工程任務組（IETF）批准了 HTTP/2 標準提案，1999 年 HTTP/1.1 正式標準化 ，而 HTTP/2 是自那時以來的首個重大升級。HTTP/2 的主要目標是與 HTTP/1.1 完全語義相容的基礎上，進一步減少網路延遲。換句話說，HTTP/2 要在不破壞原有 Web 體系的基礎上使它變得更快。

SPDY 的起源

自 2009 年底以來，Google 一直在開發一個實驗性的協議，這個神祕的協議名叫 SPDY（讀作 speedy）。SPDY 並不是一個首字母縮略詞，其實，它是 Google 註冊的一個商標，HTTP/2 正是起源於這個 SPDY 實驗。事實上，後來有許多曾經參與 SPDY 專案的核心開發者同樣也加入到 HTTP/2 的開發中去。在 2015 年 2 月，Google正式宣佈停止支援 SPDY 計劃，全力支援 HTTP/2 的開發，預計在 2016 年前實現全部功能。

HTTP/1.1

自 1999 年以來，HTTP/1.1 默默地為我們服務了十幾年，它是在當時那樣的計算機和網路應用場景下被設計出來的。我不說你也知道，HTTP 早就應該升級了。為了便於描述 HTTP/1 是如何工作的，我在下面放了幾張圖解。根據序號的順序你就會看到，從客戶端開始（很可能是一個web瀏覽器）與右方的伺服器建立一個 HTTP/1 的連線。

(2) 客戶端/瀏覽器隨後傳送一個 GET 請求（HTTP 方法）獲取 index.html 頁面。 (3) 伺服器響應客戶端請求的資源。 (4-7) 在我們這個簡單的示例中，這個不斷進行的 請求-響應迴圈過程 持續地獲取樣式表和指令碼來完善整個 HTML 文件。 (8) 最終，這個 HTTP/1 連線斷開了。

線頭阻塞（Head-of-Line Blocking）

如你所見，客戶端/瀏覽器 花費大量的時間等待每一個資源被響應。因為 HTTP/1 不能在同一個連線上進行併發請求，瀏覽器通常需要開啟多個連線來加速請求資源的過程。

代價高昂的連線

即使開啟多個連線能有效提高資源的載入速度，但是從計算機網路的角度來看，開啟每一個連線的代價都很高。所以，現代瀏覽器通常都有最多 6-8 個 HTTP/1.1 連線的限制，許多網站現在需要載入 80多個或者更多的資源，這些連線限制逐漸成為了整個 Web 系統的效能瓶頸。

HTTP 管線化（HTTP Pipelining）

HTTP/1.1 嘗試利用一個名為 HTTP管線化的技術解決效能瓶頸問題，不幸的是，單一的大檔案和過慢的響應仍然會阻塞所有後續的請求。HTTP管線化 不難部署，但你基本上不太可能去部署它，現代瀏覽器幾乎都不怎麼支援 HTTP 管線化的功能，因為許多媒介和伺服器不能正確地處理它（譯者注：可以參考 http://en.wikipedia.org/wiki/HTTP_pipelining 檢視一下支援的平臺）。

HTTP/2 多路複用（Multiplexing）

多路複用允許同時通過單一的 HTTP/2 連線發起多重的請求-響應訊息，為了向你們量化展示一個 HTTP/2 連線到底快多少，我準備了一套並排的圖對比 HTTP/2 與 HTTP/1 的效能，在這個簡單的示例中只請求 3 個資源，從 web 頁面開始渲染到載入結束，HTTP/2 比 HTTP/1 節省不少時間。

推而廣之，當 80 個資源複合請求時，與 HTTP/1.1 相比，很明顯通過單一連線進行傳遞的 HTTP/2 更高效！

其它提高 HTTP/2 效能的因素

除了多路複用，HTTP/2 還是二進位制的，與 HTTP/1 這樣的文字協議相比，二進位制協議解析起來更加高效。很顯然，二進位制的協議更適合線上路進行傳輸，並且更不容易出錯。

HTTP/2 同時也減少了壓縮頭部的開銷，這些在 HTTP/1 裡都沒有實現。

伺服器推送（Server Push）

在 HTTP/2 中，伺服器推送是指在客戶端請求之前傳送資料的機制。如果一個請求是由你的主頁發起的，伺服器很可能響應主頁內容、logo以及樣式表，因為它知道客戶端會用到這些東西。這相當於在一個 HTML 文件內集合了所有的資源，不過與之相比，伺服器推送有一個很大的優勢：可以快取！

當然這同時也是它的一個缺點，如果客戶端已經快取了資料，此時會產生不必要的冗餘。這也是為什麼我推薦伺服器提示（Server Hints）的原因。

伺服器提示（Server Hints）

伺服器提示可以先於客戶端檢測到將要請求的資源，提前通知客戶端，伺服器不傳送所有資源的實體，它只傳送資源的 URL。客戶端接到提示後進一步驗證之前的快取，如果發現需要這些資源，則正式發起請求。伺服器提示對 HTTP/2 來說興許不是最新的，但非常值得在這裡順便一提，因為它沒有上文提到的伺服器推送冗餘的缺點。

伺服器提示是通過 HTTP Link header 和與已實現的 link prefetching 語義重疊的部分來實現的。舉個例子，一個 HTTP Link header 看起來是這樣的：

Link:<https://example.com/images/large-background.jpg>; rel=prefetch

如果 HTML 文件的 head 標籤中有一個 prefetch link標籤，不需要在服務端有額外的實現，舉個例子：

<linkrel="prefetch"href="https://example.com/images/large-background.jpg">

瞭解更多有關 rel=”prefetch” 的資訊，參考 Mozilla 出品的 Link prefetching 常見問題。

進一步瞭解資源提示

預載入關聯用於宣告一個資源和它的 fetch 屬性，這個規範通過額外的處理策略擴充套件了功能，有效地獲取在下一個導航可能需要請求的資源，舉個例子

一些瀏覽器中，loadpolicy=”next inert” 等同於 rel=prefetch 這樣的實現，loadpolicy 屬性的 next 值在語義上與 rel=prerender 相同，這個規範對預獲取和預渲染的功能進行了標準化，並且給他們擴充套件了額外的功能。

欲瞭解更多，移步釋出在 W3C 的由 Ilya Grigorik 編輯的文章 資源提示。

HTTP/2 安全批判

儘管 HTTP/2 的主要目標是使網路更快，但是因為它不強制加密連線，目前飽受批判。還好的是，主導的瀏覽器廠商迄今為止都拒絕開發不加密的 HTTP/2，所以 HTTP/2 需要通過代理部署一個加密的連線。如果你不認為這對 Web 的未來大有裨益，請移步我的文章 HTTPS 無所不在。

瀏覽器支援

HTTP/2 現在或者將來會被所有主流瀏覽器支援。

• Chrome 40 支援 HTTP/2 14 號草案，但是預設不開啟。HTTP/2 17 號草案（也就是最終草案），現在可以在 Chrome Canary 43（開發者預覽版）裡使用了，目前只有基於 TLS（加密的）的 HTTP/2 實現。 如需在 Chrome 中啟用 HTTP/2，訪問： chrome://flags/#enable-spdy4
• Firefox 支援 HTTP/2，在第 36 版中預設啟用，早在第 34 版中，就已經開始新增針對 HTTP/2 的實驗性支援。目前也只有基於 TLS 的HTTP/2 實現。
• IE11 支援 HTTP/2，但是隻在 Windows 10 Beta 版裡預設啟用。目前也只有基於 TLS 的 HTTP/2 實現。
• Spartan 預計也會支援基於 TLS 的 HTTP/2，儘管微軟為 Windows 10 打造的新瀏覽器的有關細節尚未完全曝光。
• Safari 在 Mac OS X Yosemite（10.10）和 iOS 8 中預設支援 SPDY，對於 HTTP/2 的全支援預計在 2015 年底完成。
• Opera 預設支援 SPDY。預計在 Chrome 全部實現 HTTP/2 最終草案的特性後全面支援 HTTP/2。

伺服器支援

支援 HTTP/2

• IIS（網際網路資訊服務）在 Windows 10 beta 版中支援 HTTP/2。
• OpenLiteSpeed 1.3.8 和 1.4.5 支援 HTTP/2 第 17 號草案。

支援 SPDY，但不支援 HTTP/2

• Apache 通過 mod_spdy 模組支援老版本的 SPDY，目前這個模組已經停止開發。
• LiteSpeed Web 伺服器目前支援 SPDY/3.1。
• Nginx 通過一個模組提供針對 SPDY(Draft 3.1) 的實驗性支援，計劃在 2015 年底支援 HTTP/2。

目前沒有支援 HTTP/2 計劃的

• lighttpd 在版本 1.x 中沒有支援 SPDY 或 HTTP/2 的計劃

其它 HTTP/2 實現

其它已知的 HTTP/2 實現可以在 Github HTTP/2 wiki 中找到

最後，有關 HTTP/2 的暢想

正如我們所探索的，HTTP/2 早就應該為升級 Web 而出現，當它在接下來的幾年中被廣泛接受，網站和其它 web 服務將會變得更快，比以前任何時候更加能幹。感謝有遠見的瀏覽器廠商們，HTTP/2 將會增強使用者的隱私和安全。我認為對於整個 Web 生態來說，HTTP/2 是一次至關重要的飛躍，未來有許多新的事業正等著我們去開拓。

如果關於 HTTP/2 你有任何的問題或建議，可以在 Twitter 上 @BenjaminPatch