HTTPバージョンの違いと歴史

HTTPの各版は、共通のメソッドやステータスの意味を保ちながら通信方法を変えてきました。0.9から1.1の持続接続、2の多重化、3のQUICまで、何が変わったかを押さえます。新しい版なら必ず速い、というわけではありません。

ざっくり年表

主要バージョンの節目を押さえておくと設計やトラブルシュートが楽になります。

HTTP/0.9（1991頃）: GETのみ、ヘッダーなしでHTMLを返すシンプル仕様。
HTTP/1.0（1996年にRFC 1945）：ステータス行やContent-Typeなどのヘッダーを整理。通常は要求・応答ごとに接続を閉じますが、持続接続の拡張実装もありました。
HTTP/1.1（1997年にRFC 2068）：持続接続が既定となり、Host必須、チャンク転送などを規定。現在のメッセージ構文はRFC 9112、共通の意味はRFC 9110、キャッシュはRFC 9111です。
SPDY（2009）：Google発の実験プロトコル。多重化・ヘッダー圧縮・優先度のアイデアがHTTP/2に継承。
HTTP/2（2015年にRFC 7540、2022年にRFC 9113へ更新）：TCP上でバイナリフレームを多重化し、HPACKでヘッダーを圧縮。
HTTP/3（2022年にRFC 9114）：UDP上のQUICを利用。ストリームごとの配送とTLS 1.3による保護を使い、ヘッダー圧縮はQPACK。

どの課題を解決するための改訂かを意識すると理解しやすいです。

1接続の複数ストリームに要求・応答を多重化し、HTTP/1.1の応答順による待ちを軽減。ただしTCPのパケット損失による接続全体の待ち（head-of-line blocking）は残ります。
ヘッダー圧縮（HPACK）でオーバーヘッド削減。
RFC 7540の依存関係による優先度方式はRFC 9113で非推奨になっています。優先度の情報は配信順や速さの保証ではありません。
バイナリフレーミングで拡張しやすい構造に。

QUICは接続IDなどによりネットワーク経路の変更へ対応できます。ただし移行の可否は設定や経路検証にも依存し、どんな回線切り替えでも接続が保たれるわけではありません。
1ストリームの欠落待ちが、他ストリームの受信済みデータの配送を止めない仕組みです。同じストリーム内の順序待ち、輻輳制御、QPACKの依存関係による待ちは残り得ます。
QPACKはQUICに合わせたヘッダー圧縮です。HTTP/3のQUIC接続はTLS 1.3で保護されます。再接続の0-RTTは利用条件があり、再送攻撃への注意も必要です。

利用される版はクライアント、サーバー、CDN、ネットワークで変わります。一般的な普及率を自分のサイトに当てはめず、ブラウザーの開発者ツールやログで実際の通信を確認しましょう。

HTTPSのHTTP/2はTLSのALPNでh2を交渉します。HTTP/3はQUIC接続でh3を交渉します。HTTP/3接続先はAlt-Svcなどで知ることができ、TCP接続がそのままQUICへ切り替わるわけではありません。
HTTP/3は一部ネットワーク機器でUDPブロックされる場合があり、フォールバックにHTTP/2/1.1を持つ構成が現実的。
ブラウザーのNetwork欄でProtocol列を表示するとh2、h3、http/1.1などを確認できます。CDN利用時はブラウザー〜CDNとCDN〜オリジンサーバーで版が異なる場合があります。
1.1しか使えないクライアントも残るため、サーバー設定で複数バージョンを併用するケースが多い。
監視はバージョン別の指標（ハンドシェイク時間、再送、QoE）を分けて見ると問題箇所を特定しやすい。

共通の意味と転送方式を分けると理解しやすくなります。HTTPが運ぶデータ、メソッドの意味、転送速度の見方も参照してください。

< HTTPメソッドのアンチパターン集データサイズの単位まとめ >