先說結論
- 結論1：從HTTP/1.0到HTTP/2，都是利用TCP作為底層協議進行通信的。
- 結論2：HTTP/1.1，引進了長連接(keep-alive)，減少了建立和關閉連接的消耗和延遲。
- 結論3：HTTP/2，引入了多路復用：連接共享，提高了連接的利用率，降低延遲。
HTTP2.0和HTTP1.X相比的新特性
-
新的二進制格式（Binary Format），HTTP1.x的解析是基於文本。基於文本協議的格式解析存在天然缺陷，文本的表現形式有多樣性，要做到健壯性考慮的場景必然很多，二進制則不同，只認0和1的組合。基於這種考慮HTTP2.0的協議解析決定采用二進制格式，實現方便且健壯。
-
多路復用（MultiPlexing），即連接共享，即每一個request都是是用作連接共享機制的。一個request對應一個id，這樣一個連接上可以有多個request，每個連接的request可以隨機的混雜在一起，接收方可以根據request的 id將request再歸屬到各自不同的服務端請求里面。
-
header壓縮，如上文中所言，對前面提到過HTTP1.x的header帶有大量信息，而且每次都要重復發送，HTTP2.0使用encoder來減少需要傳輸的header大小，通訊雙方各自cache一份header fields表，既避免了重復header的傳輸，又減小了需要傳輸的大小。
-
服務端推送（server push），同SPDY一樣，HTTP2.0也具有server push功能。
1. HTTP2.0的多路復用和HTTP1.X中的長連接復用有什么區別？
-
HTTP/1.* 一次請求-響應，建立一個連接，用完關閉；每一個請求都要建立一個連接；
-
HTTP/1.1 Pipeling解決方式為，若干個請求排隊串行化單線程處理，后面的請求等待前面請求的返回才能獲得執行機會，一旦有某請求超時等，后續請求只能被阻塞，毫無辦法，也就是人們常說的線頭阻塞；
-
HTTP/2多個請求可同時在一個連接上並行執行。某個請求任務耗時嚴重，不會影響到其它連接的正常執行；具體如圖：
2. 為什么需要頭部壓縮？
假定一個頁面有100個資源需要加載（這個數量對於今天的Web而言還是挺保守的）, 而每一次請求都有1kb的消息頭（這同樣也並不少見，因為Cookie和引用等東西的存在）, 則至少需要多消耗100kb來獲取這些消息頭。HTTP2.0可以維護一個字典，差量更新HTTP頭部，大大降低因頭部傳輸產生的流量。具體參考：HTTP/2 頭部壓縮技術介紹
3. HTTP2.0多路復用有多好？
HTTP 性能優化的關鍵並不在於高帶寬，而是低延遲。TCP 連接會隨着時間進行自我「調諧」，起初會限制連接的最大速度，如果數據成功傳輸，會隨着時間的推移提高傳輸的速度。這種調諧則被稱為 TCP 慢啟動。由於這種原因，讓原本就具有突發性和短時性的 HTTP 連接變的十分低效。HTTP/2 通過讓所有數據流共用同一個連接，可以更有效地使用 TCP 連接，讓高帶寬也能真正的服務於 HTTP 的性能提升。
參考鏈接：