HTTP/2 保留了 HTTP 語意，卻將多條串流多工到單一連線上

HTTP/1.1 為每個請求開啟新連線，或重複使用少數幾條連線，迫使瀏覽器對同一個網站開啟約六條平行連線。每條連線都要各自付出握手成本，而某一條連線上回應緩慢，就會讓排在它後面的其他請求一起被卡住。網路之所以慢，是結構性原因，而非技術性原因。

Google 的 SPDY 證明了修正方法：完全保留 HTTP 的方法、標頭與狀態碼不變，但把流量移入單一連線，由該連線承載許多多工串流。IETF 承接這項工作，並在 RFC 7540 中將其標準化為 HTTP/2，採用二進位訊框與 HPACK 標頭壓縮。

由於語意維持完全相同，伺服器與瀏覽器不必重新思考 HTTP 請求的意義就能採用。傳輸方式改變了，契約卻沒有改變，因此每個網站都免費獲得這項加速。

凍結 HTTP 的語意；在單一連線上執行多條串流。

由於 HTTP 語意未被更動，既有伺服器可以加入支援，而不必改變應用程式撰寫回應的方式。

單一連線承載多條串流，消除了六條連線的瓶頸，也免除了每項資源的連線建立成本。

HPACK 會壓縮重複的標頭，因此相同的 cookie 與 user-agent 欄位不再於每個請求中重複傳送。

伺服器推送讓伺服器能在用戶端要求之前先送出資源，省去一次往返。

即使語意不變，保留相容性的傳輸方式仍能勝出；守住契約，換掉底層管線。

RFC 7540 於 2015 年 5 月定案，並成為幾乎所有 HTTPS 流量的預設協定。它剩下的主要問題是 TCP 隊頭阻塞，這直接促成了 QUIC 與 HTTP/3。HTTP/2 也助長了請求走私，以及 2023 年發現的 HTTP/2 快速重置 DoS 模式。