【比較】HTTP/1.1・HTTP/2・HTTP/3の違い¶
概要¶
HTTP/1.1・HTTP/2・HTTP/3 は同じ「HTTP」ですが、世代ごとに下位の運び方（トランスポートと転送形式）が変わってきた進化系です。重要なのは、HTTP のセマンティクス（メソッド・ステータスコード・ヘッダの意味）は世代を通じて共通で、RFC 9110 がバージョン非依存のセマンティクスとして切り出している点です。変わるのは「同じ意味のやり取りを、どう効率よく運ぶか」です。
ざっくり言うと、HTTP/1.1（RFC 9112）はテキストベースで持続的接続を既定とし、HTTP/2（RFC 9113）はバイナリフレーミングで 1 本の TCP 接続上に多重化（ストリーム）を持ち込み、HTTP/3（RFC 9114）は TCP をやめて UDP 上の QUIC（RFC 9000）に乗せました。世代を分ける核心は Head-of-line（HOL）ブロッキングがどの層に残るかです。これを理解すると「なぜ HTTP/2 で速くなったのに HTTP/3 が必要だったのか」が腑に落ちます。
例えるなら：1 車線道路 → 多車線だが同じ橋 → 橋を架け替えた多車線¶
- HTTP/1.1 … 片側 1 車線。前の車（リクエスト）が詰まると後続も止まる。渋滞回避のため道路（TCP 接続）を複数本引く。
- HTTP/2 … 同じ 1 本の橋（TCP 接続）を多車線化。並走できるが、橋の途中で 1 か所事故（パケットロス）が起きると橋全体が止まる（TCP レベル HOL）。
- HTTP/3 … 橋そのものを架け替え（UDP/QUIC）。各車線が独立し、1 車線の事故が他車線を止めない。
詳細比較¶
| 比較軸 | HTTP/1.1 | HTTP/2 | HTTP/3 |
|---|---|---|---|
| RFC | RFC 9112（RFC 7230 を更新） | RFC 9113（RFC 7540 を obsolete） | RFC 9114 |
| トランスポート | TCP | TCP | QUIC（UDP 上） |
| 転送形式 | テキストベース | バイナリフレーミング | バイナリ（QUIC ストリーム上） |
| 多重化 | なし（1 接続＝逐次。並列は複数接続で代替） | あり（1 TCP 接続上に複数ストリームを多重化） | あり（QUIC の独立ストリームで多重化） |
| HOL ブロッキング | HTTP 層で発生（重い応答が後続を塞ぐ） | TCP 層で残存（1 パケットロスで全ストリーム停止） | 解消（ストリームが独立、ロスが他を止めない） |
| ヘッダ圧縮 | なし（毎回テキストで送る） | HPACK（RFC 7541） | QPACK（RFC 9204） |
| 接続確立 | TCP ハンドシェイク（+ TLS なら別途） | TCP + TLS（ブラウザ実装では実質必須。仕様上は平文 h2c も定義） | QUIC が暗号と統合、0-RTT 再接続が可能 |
| 既定の接続再利用 | 持続的接続（keep-alive）が既定 | 1 接続を多重利用 | 1 QUIC 接続を多重利用、接続マイグレーション可 |
よくある誤解¶
- 誤解1：「HTTP/2 でパイプライン化／多重化したので TCP の HOL ブロッキングは解決した」 — 解決していません。RFC 9113 自身が「TCP head-of-line blocking is not addressed by this protocol」と明記しています。HTTP/2 のストリーム並列性は TCP のロス回復から見えないため、RFC 9114 が言うように「パケットが 1 つ失われると、その影響を受けないトランザクションまで含めて全アクティブトランザクションが停止」します。これを根治するために HTTP/3 が QUIC に移りました。
- 誤解2：「HTTP/3 は UDP だから信頼性がなく順序も保証されない」 — 誤りです。HTTP/3 が乗る QUIC（RFC 9000）は UDP 上に独自の再送・順序整列・輻輳制御を実装し、ストリーム単位で信頼性のある順序付き配送を提供します。「UDP＝不確実」は素の UDP の話で、QUIC は別物です。
- 誤解3：「HTTP/2 はテキストを廃しただけで HTTP/1.1 と中身は同じ」 — 転送形式（バイナリフレーミング）と多重化という大きな構造変化があります。一方でセマンティクス（メソッド・ステータス・ヘッダの意味）は共通で、RFC 9110 が「主要バージョンが独立に進化できるよう、セマンティクスを HTTP/1.1 のメッセージ構文から分離した」と述べています。変わったのは意味ではなく運び方です。
- 誤解4：「HTTP/1.1 にはパイプラインがあるから多重化できる」 — パイプライン（応答を待たず複数リクエストを送る）は規格上許容されますが、サーバはリクエスト順に応答しなければならず、重い 1 件が後続を塞ぐ HOL ブロッキングが残ります。実運用では複数 TCP 接続を張って回避するのが一般的で、真の多重化は HTTP/2 以降です。
実務での選び分け¶
世代は基本的に「対応していれば新しい方が有利」で、明示的に選ぶというより有効化・フォールバック設計が論点です。
- 新規 Web/API でレイテンシ・多重リクエストが効く → HTTP/2 を既定で有効化、可能なら HTTP/3 も併用（
Alt-Svc等でアップグレード、未対応クライアントは自動フォールバック）。 - モバイル・高遅延／パケットロスの多い回線、接続が切り替わる環境 → HTTP/3（QUIC）の恩恵が大きい。TCP HOL の影響と再接続コスト（0-RTT）で差が出る。
- 企業ネットワーク／一部 FW・プロキシで UDP/443 が通らない → HTTP/3 が使えない場合があるため、HTTP/2 へのフォールバックを必ず確保する。
- シンプルさ・互換性最優先、低トラフィックの内部用途 → HTTP/1.1 でも十分なことは多い（デバッグもテキストで容易）。
- 判断の軸：①クライアント／中間装置の対応 ②回線品質（ロス・遅延） ③接続多重度。新しい世代を「使える限り使い、必ず下位へフォールバックできるようにする」のが実務の定石。
ひとことまとめ¶
セマンティクス（RFC 9110）は世代共通で、変わるのは運び方。HTTP/1.1＝テキスト＋逐次（HTTP 層 HOL）、HTTP/2＝バイナリ多重化だが TCP 層 HOL が残る、HTTP/3＝QUIC/UDP で HOL を解消し 0-RTT 可。HOL ブロッキングがどの層に残るかが世代を分ける核心です。
出典・参考¶
- RFC 9110「HTTP Semantics」（メソッド・ステータス・ヘッダ等のセマンティクスをバージョン非依存に分離。各主要バージョンは同じセマンティクスを参照しつつ独立に進化）: https://www.rfc-editor.org/rfc/rfc9110.html
- RFC 9112「HTTP/1.1」（持続的接続が既定。重い応答が後続を塞ぐ HOL を避けるため複数接続が使われる。RFC 7230 を更新）: https://www.rfc-editor.org/rfc/rfc9112.html
- RFC 9113「HTTP/2」（バイナリフレーミング、1 接続上の多重ストリーム、HPACK ヘッダ圧縮。"TCP head-of-line blocking is not addressed by this protocol"。RFC 7540 を obsolete）: https://www.rfc-editor.org/rfc/rfc9113.html
- RFC 9114「HTTP/3」（QUIC 上で動作。HTTP/2 ではパケットロスが全トランザクションを停止させるが、HTTP/3 のストリームは独立で他を止めない）: https://www.rfc-editor.org/rfc/rfc9114.html
- RFC 9000「QUIC: A UDP-Based Multiplexed and Secure Transport」（UDP 上でストリーム多重化・per-stream フロー制御・接続全体の輻輳制御を提供、HTTP/3 の土台）: https://www.rfc-editor.org/rfc/rfc9000.html