HTTP/1.1 性能瓶頸：

1.請求 / 響應頭部（Header）未經壓縮就發送。只能壓縮Body的部分；

2.沒有請求優先級控制；

3.服務器是按請求的順序響應的，有隊頭阻塞；

4.請求只能從客戶端開始，服務器只能被動響應。

http/2.0

1.HTTP/2 會壓縮頭，如果你同時發出多個請求會幫你消除請求頭重復的部分。

2.數據包不是按順序發送的，同一個連接里面連續的數據包，要對數據包做標記，指出它屬于哪個回應。

3.純文本形式的報文改為了二進制格式，統稱為幀：頭信息幀和數據幀。

4.多路復用：一個連接中并發多個請求或回應，而不用按照順序一一對應。

5.服務器推送，主動向客戶端發消息。

問題：

多個 HTTP 請求在復用一個 TCP 連接，下層的 TCP 協議是不知道有多少個 HTTP 請求的。所以一旦發生了丟包現象，就會觸發 TCP 的重傳機制，這樣在一個 TCP 連接中的所有的 HTTP 請求都必須等待這個丟了的包被重傳回來。

http/3.0

1.傳輸層由TCP轉成了UDP