HTTP/2 的目標

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

SPDY 的起源

自 2009 年底以來，Google 一直在開發(fā)一個實驗性的協(xié)議，這個神秘的協(xié)議名叫 SPDY（讀作 speedy）。SPDY 并不是一個首字母縮略詞，其實，它是 Google 注冊的一個商標，HTTP/2 正是起源于這個 SPDY 實驗。事實上，后來有許多曾經(jīng)參與 SPDY 項目的核心開發(fā)者同樣也加入到 HTTP/2 的開發(fā)中去。在 2015 年 2 月，Google正式宣布停止支持 SPDY 計劃，全力支持 HTTP/2 的開發(fā)，預計在 2016 年前實現(xiàn)全部功能。

HTTP/1.1

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

(2) 客戶端/瀏覽器隨后發(fā)送一個 GET 請求（HTTP 方法）獲取 index.html 頁面。 (3) 服務器響應客戶端請求的資源。 (4-7) 在我們這個簡單的示例中，這個不斷進行的 請求-響應循環(huán)過程 持續(xù)地獲取樣式表和腳本來完善整個 HTML 文檔。 (8) 最終，這個 HTTP/1 連接斷開了。

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

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

代價高昂的連接

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

HTTP 管線化（HTTP Pipelining）

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

HTTP/2 多路復用（Multiplexing）

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

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

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

除了多路復用，HTTP/2 還是二進制的，與 HTTP/1 這樣的文本協(xié)議相比，二進制協(xié)議解析起來更加高效。很顯然，二進制的協(xié)議更適合在線路進行傳輸，并且更不容易出錯。

HTTP/2 同時也減少了壓縮頭部的開銷，這些在 HTTP/1 里都沒有實現(xiàn)。

服務器推送（Server Push）

在 HTTP/2 中，服務器推送是指在客戶端請求之前發(fā)送數(shù)據(jù)的機制。如果一個請求是由你的主頁發(fā)起的，服務器很可能響應主頁內容、logo以及樣式表，因為它知道客戶端會用到這些東西。這相當于在一個 HTML 文檔內集合了所有的資源，不過與之相比，服務器推送有一個很大的優(yōu)勢：可以緩存！

當然這同時也是它的一個缺點，如果客戶端已經(jīng)緩存了數(shù)據(jù)，此時會產生不必要的冗余。這也是為什么我推薦服務器提示（Server Hints）的原因。

服務器提示（Server Hints）

服務器提示可以先于客戶端檢測到將要請求的資源，提前通知客戶端，服務器不發(fā)送所有資源的實體，它只發(fā)送資源的 URL。客戶端接到提示后進一步驗證之前的緩存，如果發(fā)現(xiàn)需要這些資源，則正式發(fā)起請求。服務器提示對 HTTP/2 來說興許不是最新的，但非常值得在這里順便一提，因為它沒有上文提到的服務器推送冗余的缺點。

進一步了解資源提示

預加載關聯(lián)用于聲明一個資源和它的 fetch 屬性，這個規(guī)范通過額外的處理策略擴展了功能，有效地獲取在下一個導航可能需要請求的資源，舉個例子

一些瀏覽器中，loadpolicy=”next inert” 等同于 rel=prefetch 這樣的實現(xiàn)，loadpolicy 屬性的 next 值在語義上與 rel=prerender 相同，這個規(guī)范對預獲取和預渲染的功能進行了標準化，并且給他們擴展了額外的功能。

欲了解更多，移步發(fā)布在 W3C 的由 Ilya Grigorik 編輯的文章 資源提示。

HTTP/2 安全批判

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

瀏覽器支持

HTTP/2 現(xiàn)在或者將來會被所有主流瀏覽器支持。

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

服務器支持

支持 HTTP/2

IIS（互聯(lián)網(wǎng)信息服務）在 Windows 10 beta 版中支持 HTTP/2。 OpenLiteSpeed 1.3.8 和 1.4.5 支持 HTTP/2 第 17 號草案。

支持 SPDY，但不支持 HTTP/2

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

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

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

其它 HTTP/2 實現(xiàn)

其它已知的 HTTP/2 實現(xiàn)可以在 Github HTTP/2 wiki 中找到

最后，有關 HTTP/2 的暢想

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

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