HTTP 2.0相容HTTP 1.X，同時大大提升了Web效能，進一步減少了網路延遲，減少了前端方面的工作。HTTP 1.X存在的缺點如下：

　　1）HTTP 1.0一次只允許在一個TCP連線上發起一個請求，HTTP 1.1使用的流水線技術也只能部分處理請求併發，仍然會存在佇列頭阻塞問題，因此客戶端在需要發起多次請求時，通常會採用建立多連線來減少延遲。
　　2）單向請求，只能由客戶端發起。
　　3）請求報文與響應報文首部資訊冗餘量大。
　　4）資料沒有進行壓縮處理，導致資料的傳輸量大

HTTP 2.0採用了新的二進位制格式，解決了多路複用（連線共享）問題，可對Header進行壓縮，使用較為安全的HPACK壓縮演算法，重置連線表現更好，有一定的流量控制功能，使用更安全的SSL。

一、二進位制分幀

在儘可能相容HTTP 1.X的前提下，為了解決HTTP 1.X存在的問題，改進傳輸效能，實現低延遲高吞吐量；HTTP 2.0在應用層（HTTP）和傳輸層（TCP）之間增加一個二進位制分幀層。

HTTP2.0中所有加強效能的核心是二進位制傳輸，在HTTP1.x中，我們是通過文字的方式傳輸資料。基於文字的方式傳輸資料存在很多缺陷，文字的表現形式有多樣性，因此要做到健壯性考慮的場景必然有很多，但是二進位制則不同，只有0和1的組合，因此選擇了二進位制傳輸，實現方便且健壯。
在HTTP2.0中引入了新的編碼機制，所有傳輸的資料都會被分割，並採用二進位制格式編碼。

在二進位制分幀層上，HTTP2.0會將所有傳輸的資訊分為更小的訊息和幀，並採用二進位制格式編碼，其中HTTP1.X的首部資訊會被封裝到Headers幀，而Request Body則封裝到Data幀。

二、首部壓縮

HTTP每次通訊（請求或響應）都會攜帶首部資訊用於描述資源屬性。
在HTTP1.0中，使用文字的形式傳輸header，在header中攜帶cookie的話，每次都需要重複傳輸幾百到幾千的位元組，這導致了極大的開銷。
在HTTP2.0中，使用了HPACK（HTTP 2.0頭部壓縮演算法）壓縮格式對傳輸的header進行編碼，減少了header的大小。並在兩端維護了索引表，用於記錄出現過的header，後面在傳輸過程中就可以傳輸已經記錄過的header的鍵名，對端收到資料後就可以通過鍵名找到對應的值。

三、多路複用

HTTP2.0中，基於二進位制分幀層，HTTP2.0可以在共享TCP連線的基礎上同時傳送請求和響應。HTTP訊息被分解為獨立的幀，而不破壞訊息本身的語義

　　1）幀：HTTP2.0通訊的最小單位，所有幀都共享一個8位元組的首部，其中包含幀的長度、型別、標誌、還有一個保留位，並且至少有標識出當前幀所屬的流的識別符號，幀承載著特定型別的資料，如HTTP首部、負荷、等等。
　　2）訊息：比幀大的通訊單位，是指邏輯上的HTTP訊息，比如請求、響應等。每個訊息由一個或多個幀組成。
　　3）流：比訊息大的通訊單位。是TCP連線中的一個虛擬通道，可以承載雙向的訊息。每個流都有一個唯一的整數識別符號。

四、請求優先順序

把HTTP訊息分為很多獨立幀之後，就可以通過優化這些幀的交錯和傳輸順序進一步優化效能。

五、伺服器推送

HTTP2.0新增的一個強大的新功能，就是伺服器可以對一個客戶端請求傳送多個響應。伺服器向客戶端推送資源無需客戶端明確的請求。

服務端根據客戶端的請求，提前返回多個響應，推送額外的資源給客戶端。如下圖，客戶端請求stream 1(/page.html)。服務端在返回stream 1的訊息的同時推送了stream 2(/script.js)和stream 4(/style.css)

服務端推送是一種在客戶端請求之前傳送資料的機制。在HTTP2.0中，伺服器可以對一個客戶端的請求傳送多個響應。如果一個請求是由你的主頁傳送的，伺服器可能會響應主頁內容、logo以及樣式表，因為他知道客戶端會用到這些東西。這樣不但減輕了資料傳送冗餘步驟，也加快了頁面響應的速度，提高了使用者體驗。

推送的缺點：所有推送的資源都必須遵守同源策略。換句話說，伺服器不能隨便將第三方資源推送給客戶端，而必須是經過雙方的確認才行。

六、HTTPS與SSL/TLS協議

（1）https和http的區別：
　　1）https需要ca證書，需要費用，http不用
　　2）https是有安全性ssl加密傳輸協議，http是超文字傳輸，是明文的
　　3）https和http的傳輸方式也不一樣，埠也不一樣，一個預設443，一個預設80
　　4）https是又ssl和http組成的具有加密和身份安全認證的網路協議，http是無狀態的

（2）SSL/TLS協議

　　1）客戶端給出一個協議版本號，一個客戶端生成的隨機數，以及客戶端支援的加密方法
　　2）服務端確認加密方法，傳送數字證書，給出一個服務端生成的隨機數
　　3）客戶端確認證書有效，生成一個新的隨機數，並用證書內的公鑰，加密這個隨機數，傳送給服務端，
　　4）服務端用自己的私鑰，獲取這個隨機數
　　5）雙方根據約定的加密方法，使用這三個隨機數，生成"對話金鑰"，用來加密整個對話過程

本文來自部落格園，作者：Jcpeng_std，轉載請註明原文連結：https://www.cnblogs.com/JCpeng/p/15019624.html