Java 9和Spring Boot 2.0紛紛宣布支援的HTTP/2到底是什麼？
點選上方“Hollis”關注我，精彩内容第一時間呈現。
全文字數： 3000
閱讀時間： 8分鐘
關于HTTP/2，最近你可能沒少聽到過他。首先，如果你了解過Java 9的特性，那麼你會發現在Java9中，提供了新的方式來處理HTTP調用，提供了新的HTTP Client，将替代HttpURLConnection，并提供對WebSocket和HTTP/2的支援。還有前兩天剛剛釋出的Spring Boot 2.0 的新特性中，也會看到，Spring Boot 2.0支援的Web容器中Tomcat、Undertow和Jetty均已支援HTTP/2。
那麼，這篇文章，我們就來了解下，到底什麼是HTTP/2。
HTTP
超文本傳輸協定（英文：HyperText Transfer Protocol，縮寫：HTTP）是一種用于分布式、協作式和超媒體資訊系統的應用層協定。設計HTTP最初的目的是為了提供一種釋出和接收HTML頁面的方法。通過HTTP或者HTTPS協定請求的資源由統一資源辨別符（Uniform Resource Identifiers，URI）來辨別。
HTTP 協定是以 ASCII 碼傳輸，基于請求與響應模式的、無狀态的，建立在 TCP/IP 協定之上的應用層規範。它不涉及資料包（packet）傳輸，主要規定了用戶端和伺服器之間的通信格式，預設使用80端口。
HTTP協定主要的版本有3個，分别是HTTP/1.0、HTTP/1.1和HTTP/2。HTTPS是另外一個協定，簡單講是HTTP的安全版。
HTTP/1.0
1996年5月，HTTP/1.0 版本釋出，為了提高系統的效率，HTTP/1.0規定浏覽器與伺服器隻保持短暫的連接配接，浏覽器的每次請求都需要與伺服器建立一個TCP連接配接，伺服器完成請求處理後立即斷開TCP連接配接，伺服器不跟蹤每個客戶也不記錄過去的請求。
請注意上面提到的HTTP/1.0中浏覽器與伺服器隻保持短暫的連接配接，連接配接無法複用。也就是說每個TCP連接配接隻能發送一個請求。發送資料完畢，連接配接就關閉，如果還要請求其他資源，就必須再建立一個連接配接。
我們知道TCP連接配接的建立需要三次握手，是很耗費時間的一個過程。是以，HTTP/1.0版本的性能比較差。現在，随便打開一個網頁，上面都會有很多圖檔、視訊等資源，HTTP/1.0顯然無法滿足性能要求。
HTTP/1.1
為了解決HTTP/1.0存在的缺陷，HTTP/1.1于1999年誕生。相比較于HTTP/1.0來說，最主要的改進就是引入了持久連接配接。所謂的持久連接配接就是：在一個TCP連接配接上可以傳送多個HTTP請求和響應，減少了建立和關閉連接配接的消耗和延遲。
引入了持久連接配接之後，在性能方面，HTTP協定有了明顯的提升，基本可以用于日常使用，這也是這一版本一直延用至今的原因。當然還是有些力不從心的，後面會詳細介紹。
關于HTTP/1.0和HTTP/1.1還有些其他差別，這裡就不展開介紹了。網上也很多資料，可以自行查閱。
SPDY
雖然，HTTP/1.1在HTTP/1.0的基礎上提供了持久連接配接，提升了很大的效率，但是，還是有很大的提升空間。
正所謂時勢造英雄，正是因為HTTP存在着諸多不足，是以，才誕生了SPDY。2009年，谷歌公開了自行研發的 SPDY 協定，主要解決 HTTP/1.1 效率不高的問題。它的設計目标是降低 50% 的頁面加載時間。SPDY主要提供了以下功能（後文介紹HTTP2的時候再詳細介紹）：
- 多路複用（multiplexing）。多個請求共享一個tcp連接配接。
- header壓縮。删除或者壓縮HTTP頭
- 服務端推送。提供服務方發起通信，并向用戶端推送資料的機制。
- SPDY位于HTTP之下，TCP和SSL之上，這樣可以輕松相容老版本的HTTP協定。
實際上在 HTTP2 提出來之前，SPDY 流行了很長一段時間。當下很多著名的網際網路公司都在自己的網站或 APP 中采用了 SPDY 系列協定（目前最新版本是 SPDY/3.1），因為它對性能的提升是顯而易見的。主流的浏覽器（谷歌、火狐、Opera）也都早已經支援 SPDY，它已經成為了工業标準。HTTP Working-Group 最終決定以 SPDY/2 為基礎，開發 HTTP/2。
HTTP/2
下圖是Akamai 公司建立的一個官方的示範，主要用來說明在性能上HTTP/1.1和HTTP/2在性能升的差别。同時請求 379 張圖檔，HTTP/1.1加載用時4.54s，HTTP/2加載用時1.47s。
HTTP/2 是 HTTP 協定自 1999 年 HTTP 1.1 釋出後的首個更新，主要基于 SPDY 協定。由網際網路工程任務組（IETF）的 Hypertext Transfer Protocol Bis（httpbis）工作小組進行開發。該組織于2014年12月将HTTP/2标準提議遞交至IESG進行讨論，于2015年2月17日被準許。HTTP/2标準于2015年5月以RFC 7540正式發表。
下面來看下，HTTP/2相對于HTTP/1.1有哪些改進：
二進制分幀
在HTTP/2中，在應用層（HTTP2.0）和傳輸層（TCP或者UDP）之間加了一層：二進制分幀層。這是HTTP2中最大的改變。HTTP2之是以性能會比HTTP1.1有那麼大的提高，很大程度上正是由于這一層的引入。
在二進制分幀層中， HTTP/2 會将所有傳輸的資訊分割為更小的消息和幀（frame）,并對它們采用二進制格式的編碼。
這種單連接配接多資源的方式，減少了服務端的壓力，使得記憶體占用更少，連接配接吞吐量更大。而且，TCP連接配接數的減少使得網絡擁塞狀況得以改善，同時慢啟動時間的減少，使擁塞和丢包恢複速度更快。
多路複用
多路複用允許同時通過單一的HTTP/2.0連接配接發起多重的請求-響應消息。在HTTP1.1協定中，浏覽器用戶端在同一時間，針對同一域名下的請求有一定數量的限制，超過了這個限制的請求就會被阻塞。而多路複用允許同時通過單一的 HTTP2.0 連接配接發起多重的“請求-響應”消息。
HTTP2的請求的TCP的connection一旦建立，後續請求以stream的方式發送。每個stream的基本組成機關是frame（二進制幀）。用戶端和伺服器可以把 HTTP 消息分解為互不依賴的幀，然後亂序發送，最後再在另一端把它們重新組合起來。
也就是說， HTTP2.0 通信都在一個連接配接上完成，這個連接配接可以承載任意數量的雙向資料流。就好比，我請求一個頁面 http://www.hollischuang.com 。頁面上所有的資源請求都是用戶端與伺服器上的一條 TCP 上請求和響應的！
header壓縮
HTTP/1.1的header帶有大量資訊，而且每次都要重複發送。HTTP/2 為了減少這部分開銷，采用了HPACK 頭部壓縮算法對Header進行壓縮。
服務端推送
簡單來講就是當使用者的浏覽器和伺服器在建立連接配接後，伺服器主動将一些資源推送給浏覽器并緩存起來的機制。有了緩存，當浏覽器想要通路已緩存的資源的時候就可以直接從緩存中讀取了。
PS：本文參考了多篇文章，由于公衆号限制無法增加連結，參考資料請前往原文檢視。