HTTP/2 と HTTP/3 (QUIC)

HTTP/2 と HTTP/3 (QUIC)

解説

このレッスンで分かること

• HTTP/2 は TCP 上で多重化とヘッダー圧縮 (HPACK) を実現し、HTTP/1.1 の並列制限を解消しました
• HTTP/3 は QUIC (UDP ベース) で TCP の Head-of-Line Blocking を根本から解決
• TLS 1.3 を内包し 1 RTT で接続、Wi-Fi/モバイル切替でも接続マイグレーションで継続可能

解説

HTTP/2 と HTTP/3 とは

HTTP/1.1 の課題と、HTTP/2・HTTP/3 がどのように改善したかを学びます。本レッスンでは、HTTP/2 と HTTP/3 の基本から実際の使いどころまでを整理し、現場で迷わず使える形に落とし込みます。

HTTP/1.1 / 2 / 3 比較表

このレッスンで学ぶこと

HTTP/1.1 が抱えていた問題と、それを解決した HTTP/2、さらに UDP ベースで再設計した HTTP/3 (QUIC) を学びます。

HTTP/1.1 の課題

HTTP/1.1 は長らく Web の中心でしたが、現代の高速・複雑な Web サイトに対しては下記の弱点を抱えていました。

1. 1 接続で 1 リクエストずつ — レスポンスが返るまで次のリクエストを送れない (パイプライニングは普及せず)
2. テキストプロトコル — ヘッダーが冗長で、パース効率が悪い
3. ヘッダー圧縮なし — 毎回似たような Cookie / User-Agent を送る
4. ブラウザの並列数制限 — 同じドメインに 6 並列までしか接続できない

ブラウザはこの制限を「ドメインシャーディング (画像用、API 用にサブドメインを分ける)」などで回避していましたが、本質的な解決にはなりませんでした。

HTTP/2 の改善点

2015 年に標準化された HTTP/2 は、TCP 上で動く点は HTTP/1.1 と同じですが、内部表現を大幅に変えました。

• バイナリプロトコル — テキストからバイナリへ。パースが高速化。
• ストリームの多重化 — 1 つの TCP 接続上で複数のリクエストを並列に流せる。並列数制限の解消。
• ヘッダー圧縮 (HPACK) — 重複ヘッダーを圧縮し、転送量を削減。
• サーバープッシュ — クライアントが要求する前にサーバーが追加リソースを送れる機能だったが、Chrome 106 (2022) でデフォルト無効化され実質廃止。現在は代替として 103 Early Hints が使われる。
• 優先度 — ストリーム間の優先度を指定可能。

これにより、画像や JS / CSS が大量にある現代の Web ページが大幅に速くなりました。

HTTP/2 でも残る問題 — TCP の Head-of-Line Blocking

HTTP/2 はストリームを多重化しましたが、TCP の上に乗っているので「1 つのパケットが落ちると、後続のストリームの分まで再送を待つ」という Head-of-Line Blocking (HOLB) の問題が残ります。

たとえばストリーム A の 5 番目のパケットが落ちると、ストリーム B / C の続きが届いていても、TCP レイヤーで止まってしまいます。

HTTP/3 と QUIC の登場

これを解決したのが QUIC (Quick UDP Internet Connections) と、その上で動く HTTP/3 です。Google が開発し、IETF で 2022 年に正式標準化されました。

• UDP ベース — TCP の HOLB をそもそも回避
• ストリームごとに独立した順序保証 — 1 ストリームのロスが他に影響しない
• 1 RTT で接続 + TLS、再接続なら 0 RTT — 高速な接続確立
• 接続マイグレーション — Wi-Fi → モバイル回線に切り替えても接続が維持される

モバイルでの体感差は特に大きく、Cloudflare の統計では HTTP/3 が HTTP/2 より 10-30% 高速というデータも出ています。

並存と移行

現代の Web は HTTP/1.1, HTTP/2, HTTP/3 が並存しています。ALPN (Application-Layer Protocol Negotiation) という TLS の拡張で、クライアントとサーバーが対応しているバージョンを交渉します。

• Cloudflare, Google, Facebook, AWS CloudFront — HTTP/3 をすでに本番サポート
• 古いブラウザや、ファイアウォールで UDP が遮断されている環境 — HTTP/2 や HTTP/1.1 にフォールバック

サーバー側で HTTP/3 を有効にすると、対応クライアントはどんどん新しいプロトコルに乗り換えていきます。

チェックの仕方

ブラウザの DevTools を開いて Network パネルの Protocol カラムを見ると、各リクエストが h2 (HTTP/2), h3 (HTTP/3), http/1.1 のどれで通信しているか確認できます。

Chrome の旧フラグ画面で QUIC の挙動を切り替えることもできます。

まとめ

このレッスンの要点は、HTTP/2 多重化と HPACK / QUIC の設計 / 接続マイグレーション の 3 点です。実務でこれらを切り分けて説明できるようになると、設計レビューや障害対応の精度が一段上がります。

理解度チェック

Q. HTTP/3 (QUIC) が HTTP/2 より優れている 最大の理由 はどれ？

1. TCP より UDP のほうがプロトコル自体が高速だから
2. TCP の Head-of-Line Blocking を回避し、1 つのパケットロスが他ストリームに影響しない
3. ブラウザの並列接続数が増えるから
4. 暗号化が不要だから

答えを見る

正解は 2。QUIC は UDP の上にストリームごとに独立した順序保証を実装。TCP では 1 パケットロスで後続全てが待たされる Head-of-Line Blocking を、ストリーム単位で分離して解決しています。

出典 (References)

• IETF RFC 9113 — HTTP/2
• IETF RFC 9114 — HTTP/3
• IETF RFC 9000 — QUIC
• Cloudflare — HTTP/3 in practice

最終更新: 2026-05-28

関連レッスン

• HTTP の基本
• HTTP メソッド
• HTTPS と TLS ハンドシェイク
• REST API の設計原則

よくある質問

Q. GET と POST はどう使い分けますか？

A. 「取得して副作用がない」なら GET、「作成・更新など状態を変える」なら POST が原則です。GET は URL にパラメータが入りキャッシュも効きますが、POST はボディに乗せられ大きなデータも送れます。冪等性も GET は持ち、POST は持たないという違いがあります。

Q. ステータスコードは何を返すべき？

A. 成功は 2xx、リダイレクトは 3xx、クライアントエラーは 4xx、サーバーエラーは 5xx が大原則です。新規作成は 201、認証失敗は 401、権限不足は 403 を返すと REST 慣習に沿った設計になります。200 で全部返すのは避けてください。

Q. REST と GraphQL の違いは？

A. REST はリソース単位のエンドポイント、GraphQL は単一エンドポイントでクエリ言語を使って欲しいデータを指定します。フロントの要件が頻繁に変わるなら GraphQL、シンプルな CRUD なら REST がメンテしやすいことが多いです。

次のレッスン

次は REST API の設計原則 で、HTTP/1 を学びます。

事前確認 — 進む前に次の 3 つができることを確認しましょう。

1. HTTP/2 / HTTP/3 の要点を自分の言葉で説明できる
2. このレッスンの最小コード (または操作手順) を見ずに書ける
3. 練習問題やクイズで間違えた箇所を読み直して理解した

理解度チェック (30 秒)

Q. HTTP/2 / HTTP/3 とは何か、1 文で説明してください。

関連レッスン

• HTTPS と TLS ハンドシェイク
• HTTP メソッド
• HTTP の基本