Google效能工程師Ilya Grigorik談HTTP/2

　　HTTP/2，也就是超文字傳輸協議第2版，是下一代HTTP協議。該版本是自1999年HTML 1.1釋出後的首個更新，目前它正由網際網路工程任務組（IETF）的Hypertext Transfer Protocol Bis (httpbis)工作小組進行開發。

　　對於HTTP/2，來自於Google的效能工程師Ilya Grigorik最近釋出了一個PPT對此進行了詳細的說明。在該呈現中，Ilya Grigorik首先提到了一組資料：目前平均每個Web頁面大約會訪問12個不同的主機，包含78個不同的請求，傳輸1232KB的資料，導致一個頁面的渲染時間通常會在2.6s至5.6s之間。而在渲染佔用的整個時間裡面，網路大約佔69.5%，JavaScript佔6.6%，佈局佔5.1%，繪製佔4.5%，因此網路傳輸的效率對整體效能有明顯的影響。

　　Ilya Grigorik認為HTTP/1.1在效能方面有明顯的缺陷，主要體現在以下幾個方面：

　　a) 並行能力有限

• 每一個源最大隻支援6個請求
• 管道在實際使用時不起作用
• 競爭性的TCP流，強制快速重傳（Spurious retransmissions）
• 額外的握手、記憶體緩衝等

　　b) 客戶端請求佇列

• 隊首阻塞
• 延遲的請求分發

　　c) 較高的協議負載

• 頭資訊和Cookies大約要800位元組
• HTTP後設資料沒有壓縮

　　另外，HTTP/1.1只允許由客戶端主動發起請求，服務端只能等待客戶端傳送請求，這對於滿足預載入的現狀是一種桎梏。

　　針對這些問題，雖然我們可以通過一些變通的方法進行處理，但是這不可避免的會引發另外的問題。例如，針對請求數的限制我們可以把多個小檔案打包到一個大檔案中，但是由於並不是每一個頁面都需要所有的小檔案，所以這樣做會造成頻寬的浪費。那麼HTTP/2是否能夠幫助我們解決這些問題呢？它都包含哪些內容呢？

　　實際上HTTP/2是為了在全球資訊網上進行低延遲的資料傳輸而設計的一個協議，它提供了HTTP語義的傳輸優化，支援HTTP／1.1的所有核心特徵，並且在其他方面做的更高效。在HTTP/2中，基本的協議單位是幀，每個幀都有不同的型別和用途。例如，報頭(HEADERS)和資料(DATA)幀組成了基本的HTTP 請求和響應；其他幀，例如設定(SETTINGS)和推送承諾(PUSH_PROMISE)則用來實現HTTP/2的其他功能。

　　HTTP/2基於SPDY協議，充分解決了TCP連線的限制。它允許多個併發 HTTP 請求共用一個 TCP會話，而不是為每個請求單獨開放連線，這樣只需建立一個 TCP 連線就可以傳送網頁上所有資源，不僅可以減少訊息互動往返的時間還可以避免建立新連線造成的延遲，使得 TCP 的效率更高。

　　針對只能由客戶端發起請求的問題，HTTP/2新增了一種新的互動模式，即伺服器能夠通過複用一個以PUSH_PROMISE幀傳送的請求來實現推送。而對於資料冗餘問題，在HTTP/2中幀包含的HTTP報頭欄位是壓縮的，同時它還捨棄掉了不必要的頭資訊，因此能顯著地減少請求和響應的大小。

　　如果你想了解與HTTP/2相關的更多資訊，可以檢視百度閱讀提供的HTTP/2中文版。

　　對於Ilya Grigorik所分享的內容Hacker News社群上也有一些人發表了自己的看法，byuu認為：

首先Firefox以及一些其他的瀏覽器只能在TLS上使用HTTP/2，這對很多人而言是一種阻礙。雖然加密非常好，但是SSL證照可能需要一定的成本以及額外的CPU資源。其次，使用一種新的、自定義的壓縮演算法對頭資訊進行處理並不一定合適，因為如果頭資訊只有300位元組的資料，那麼壓縮資料所帶來的頻寬收益並不一定會比它所消耗的CPU成本高，況且這樣還增加了程式的複雜性。最後，byuu認為新協議可能會改變我們既有Web網站的工作方式，如果優化做的不好，那麼效能可能會比HTTP/1.1更糟，同時相容性也會阻礙大家對HTTP/2的採納。

　　而kator 則從另一個角度發表了自己的看法：

“我並不懷疑這裡有大量可提升的空間，很明顯HTTP/2有很多內容來自於SPDY以及其他的一些專案。我擔心的是我們現在正在做的事情對那些可以將所有內容塞到一個流中的大公司而言有巨大好處，而對於小公司而言則更多的是劣勢。另外，作為一個老傢伙，我擔心人們會丟失與這些服務對話，或者以文字的方式檢視對話的能力。”