HTTP/2はHTTPのセマンティクスを保ちつつ、多数のストリームを1つの接続に多重化した

HTTP/1.1はリクエストごとに新しい接続を開くか、少数の接続を再利用するだけだったため、ブラウザはサイトに対して約6本の並列接続を開かざるを得なかった。各接続は個別のハンドシェイクのコストを払い、1つの遅い応答がその後ろの他の応答をブロックした。ウェブが遅かったのは、技術的な理由ではなく構造的な理由によるものだった。

GoogleのSPDYがその修正を証明した。HTTPのメソッド、ヘッダー、ステータスコードをそのまま維持しながら、トラフィックを多数の多重化されたストリームを運ぶ単一の接続へ移すのである。IETFはその成果を取り入れ、バイナリフレーミングとHPACKヘッダー圧縮を備えたHTTP/2としてRFC 7540で標準化した。

セマンティクスが同一のままだったため、サーバーとブラウザはHTTPリクエストの意味を再考することなく採用できた。変わったのはトランスポートであり、契約は変わらなかったので、すべてのサイトが高速化を無償で手に入れた。

HTTPのセマンティクスを凍結し、ストリームを1つの接続上で実行する。

HTTPのセマンティクスが手つかずだったため、既存のサーバーはアプリケーションが応答を書く方法を変えることなくサポートを追加できた。

多数のストリームを持つ1つの接続は、6接続のボトルネックと、すべてのリソースに対する接続設定のコストを取り除く。

HPACKは繰り返されるヘッダーを圧縮するので、同じCookieやUser-Agentのフィールドをリクエストごとに再送しなくなる。

サーバープッシュにより、サーバーはクライアントが要求する前にアセットを送信でき、往復を1回削減できた。

互換性を保つトランスポートは、セマンティクスが変わらなくても勝利を得られる。契約を保ち、配管を入れ替えよ。

RFC 7540は2015年5月に確定し、事実上すべてのHTTPSトラフィックのデフォルトとなった。残る主な問題はTCPのヘッドオブラインブロッキングであり、それが直接QUICとHTTP/3につながった。HTTP/2はまた、リクエストスマグリングや、2023年に発見されたHTTP/2ラピッドリセットDoSパターンを可能にした。