Webサイトの表示速度やサーバー設定について調べていると、
「HTTP/2に対応」
「HTTP/3を有効化」
「QUIC対応」
といった言葉を見かけることがあります。
しかし、
「HTTP/2とHTTP/3は何が違う？」
「HTTP/3のほうが必ず速い？」
「HTTP/2はTCP、HTTP/3はUDPってどういう意味？」
「QUICとHTTP/3は同じもの？」
「HTTP/3ならTLSは不要？」
「HTTP/2からHTTP/3へ変更するとHTMLも書き換える？」
と迷うことがあります。
結論からいうと、「HTTP/2」と「HTTP/3」は、どちらもHTTPの意味や基本的な仕組みを維持しながら、Web通信を効率化するためのHTTPプロトコルです。最大の違いは、HTTP/2が主にTCP上で動くのに対し、HTTP/3はQUICというUDPを基盤とした新しいトランスポートプロトコル上で動くことです。
一言で覚えるなら、
HTTP/2＝「TCP上でHTTP通信を多重化」
HTTP/3＝「QUIC上でHTTP通信を多重化」
です。
IETFのRFC 9113ではHTTP/2を、HTTPの意味を変えずに、効率的なフィールド圧縮や複数リクエスト・レスポンスの多重化によって通信効率を向上させるプロトコルとして規定しています。
一方、RFC 9114ではHTTP/3を、HTTPの意味をQUICトランスポート上へマッピングするプロトコルとして定義しています。
HTTP/3がQUICを採用した大きな理由の一つが、HTTP/2で残っていたTCPレベルの、
Head-of-Line Blocking（ヘッドオブラインブロッキング）
の影響を減らすことです。
この記事では、「HTTP/2」と「HTTP/3」の違いから、TCP・UDP・QUIC、TLS 1.3、接続確立、パケットロス、ストリーム、HPACK・QPACK、0-RTT、モバイル通信、Webサイト運営者がHTTP/3へ対応する必要性まで詳しく解説します。
- 「HTTP/2」と「HTTP/3」の違い【結論】
- そもそもHTTP/2とは？
- HTTP/2の大きな特徴「多重化」とは？
- HTTP/2ではデータを「フレーム」で送る
- HTTP/2の「HPACK」とは？
- HTTP/2にも問題は残った
- 「Head-of-Line Blocking」とは？
- 「HTTP/3」とは？
- 「QUIC」とは？
- HTTP/3は「UDPだから高速」なの？
- HTTP/2とHTTP/3の最大の違いは「TCP」と「QUIC」
- HTTP/3ではHead-of-Line Blockingがなくなる？
- HTTP/3とTLS 1.3の関係
- HTTP/2は暗号化されていないこともある？
- 「ALPN」とは？
- HTTP/3を使うにはURLを変える？
- HTTP/3対応サイトをHTTP/2対応ブラウザで開くと？
- UDPがブロックされたらHTTP/3は使えない？
- HTTP/3の「Connection ID」とは？
- HTTP/3の「0-RTT」とは？
- HTTP/2のHPACKとHTTP/3のQPACKの違い
- HTTP/3のほうが必ず高速？
- HTTP/3にするとHTMLやWordPressを変更する？
- HTTP/3にすればSEO順位が上がる？
- HTTP/2の「Server Push」はHTTP/3でも使う？
- HTTP/2からHTTP/3へ完全移行する必要はある？
- 自分のWebサイトがHTTP/3対応か確認する方法
- HTTP/3に対応するにはUDP 443も重要
- 「HTTP/2・HTTP/3」で迷ったときの3秒判定
- 「HTTP/2」を使った例文
- 「HTTP/3」を使った例文
- 具体例で比較：画像を大量に読み込むWebページ
- 具体例で比較：スマートフォンで移動する
- よくある間違い1：「HTTP/3はHTTP/2と内容が違う」と思う
- よくある間違い2：「HTTP/3はUDPなので信頼性がない」と思う
- よくある間違い3：「HTTP/3なら必ずHTTP/2より速い」と思う
- よくある間違い4：「HTTP/3ならHTTPSは不要」と思う
- よくある間違い5：「HTTP/3にするとURLも変わる」と思う
- よくある間違い6：「HTTP/3にしたらHTTP/2を無効にすべき」と思う
- よくある間違い7：「HTTP/3を入れればSEO対策は完了」と思う
- 「HTTP/2」と「HTTP/3」に関するよくある質問
- まとめ
- 参考リンク・出典
「HTTP/2」と「HTTP/3」の違い【結論】
| 比較項目 | HTTP/2 | HTTP/3 |
|---|---|---|
| 標準仕様 | RFC 9113 | RFC 9114 |
| 主なトランスポート | TCP | QUIC |
| QUICの基盤 | 使用しない | UDP |
| 暗号化 | Webブラウザでは通常TLSと組み合わせる | QUICにTLS 1.3が組み込まれている |
| 複数通信の多重化 | 対応 | 対応 |
| TCPレベルのHead-of-Line Blocking | 影響を受ける | ストリーム単位で影響を分離しやすい |
| ヘッダー圧縮 | HPACK | QPACK |
| ネットワーク切り替え | TCP接続では再接続が必要になることがある | QUICのConnection IDにより接続継続が可能な場合がある |
| 代表的な利点 | HTTP/1.1より効率的な多重通信 | 損失のある回線やモバイル環境での改善が期待できる |
3秒で判断するなら、
「TCP上で多重化するHTTP？」 → HTTP/2
「QUIC上で動き、TCP依存をなくしたHTTP？」 → HTTP/3
と考えると分かりやすいでしょう。
そもそもHTTP/2とは？
HTTP/1.1の意味を変えず、通信方法を効率化したHTTP
HTTP/2は、HTTP/1.1より効率よくWebコンテンツを送受信するために作られたHTTPのメジャーバージョンです。
重要なのは、HTTP/2になっても、
- GET
- POST
- ステータスコード
- HTTPヘッダー
- URL
といったHTTPの基本的な意味が大きく変わったわけではないことです。
MDNも、HTTP/2はHTTPのセマンティクスを変更せず、データをどのようにフレーム化して転送するかを改善したものと説明しています。
HTTP/2の大きな特徴「多重化」とは？
HTTP/2の重要な特徴が、
Multiplexing（多重化）
です。
1つの接続の中に複数の、
ストリーム
を作り、複数のHTTPリクエスト・レスポンスを並行してやり取りできます。
たとえばWebページに、
- HTML
- CSS
- JavaScript
- 画像A
- 画像B
- 画像C
が必要だとします。
HTTP/2では、一つの接続上でこれらの通信を複数のストリームとして並行処理できます。
HTTP/1.1時代に多く使われた、同一ホストへ多数のTCP接続を作って並列通信する必要を減らせるようになりました。
HTTP/2ではデータを「フレーム」で送る
HTTP/2では通信データを、
Frame（フレーム）
という単位で扱います。
HTTPのリクエスト・レスポンスをフレームへ分割し、ストリームごとに識別します。
そのため1本の接続上で、複数のリクエスト・レスポンスを混在させながら送信できます。
HTTP/1.xのような単純なテキスト表現から、HTTP/2ではバイナリフレーミングへ移行したことも大きな特徴です。
HTTP/2の「HPACK」とは？
HTTP通信では、毎回多くのHTTPヘッダーが送信されます。
たとえば、
- Cookie
- User-Agent
- Accept
- Cache-Control
- その他の各種フィールド
です。
同じようなヘッダーを何度も送ると通信量が増えます。
そこでHTTP/2では、
HPACK
というヘッダー圧縮方式を利用します。
これによって重複するHTTPフィールドを効率的に圧縮し、通信量を削減できます。
HTTP/2にも問題は残った
HTTP/2によってHTTPレベルでは複数のリクエストを別々のストリームに分けられるようになりました。
しかし、HTTP/2は通常、
1本のTCP接続
上で通信します。
ここでTCPの性質による問題が残ります。
それが、
TCPレベルのHead-of-Line Blocking
です。
「Head-of-Line Blocking」とは？
TCPは、送ったデータを、
順番どおり、欠けることなく
アプリケーションへ渡す信頼性の高い通信を提供します。
そのため途中のパケットが1つ失われた場合、そのパケットが再送されて届くまで、後から届いたデータをHTTP/2側へ渡せないことがあります。
HTTP/2には複数のストリームがあっても、すべてが同じTCP接続を共有しています。
RFC 9114は、HTTP/2のストリーム多重化をTCPの損失回復機構から見ることができないため、パケットの損失や順序変更が発生すると、直接影響を受けていないものを含むすべてのアクティブなトランザクションが一時停止する可能性があると説明しています。
これがHTTP/3誕生の重要な背景です。
「HTTP/3」とは？
TCPではなくQUICを使うHTTP
HTTP/3は、HTTP/2の次のメジャーバージョンです。
最大の特徴は、
TCPを使わず、QUICを利用する
ことです。
RFC 9114ではHTTP/3を、
HTTP semanticsをQUIC上へマッピングしたもの
として定義しています。
HTTP/3でも、
- GET
- POST
- ステータスコード
- HTTPフィールド
- URL
など、HTTPの基本的な意味は変わりません。
大きく変わったのは、
データをどのように運ぶか
です。
「QUIC」とは？
QUICは、IETFがRFC 9000で標準化したトランスポートプロトコルです。
QUICはUDPを基盤にしながら、
- 信頼性のある通信
- 複数ストリーム
- 輻輳制御
- 接続管理
- 暗号化
など、HTTPの高速・安全な通信に必要な多くの機能を提供します。
したがって、
「HTTP/3はUDPなので、データが欠けても気にしない」
という理解は間違いです。
HTTP/3はUDPをそのまま使うのではなく、UDP上に構築されたQUICによって、必要な信頼性を実現しています。
HTTP/3は「UDPだから高速」なの？
単純に、
UDP＝速い
TCP＝遅い
という理由ではありません。
QUICはUDPを基盤とすることで、OSのTCP実装に縛られず、HTTPに適した通信機能をユーザー空間で柔軟に実装しやすくしています。
そのうえで、
- ストリーム単位の損失回復
- TLS 1.3との統合
- 効率的な接続確立
- Connection ID
などを組み合わせています。
HTTP/3の性能改善は、QUIC全体の設計によるものと考えるのが適切です。
HTTP/2とHTTP/3の最大の違いは「TCP」と「QUIC」
| HTTP/2 | HTTP/3 |
|---|---|
| TCPを利用 | QUICを利用 |
| TCPは信頼性を接続単位で提供 | QUICは複数の独立したストリームを提供 |
| パケット損失で複数ストリームが待たされる場合がある | 失われたデータに関係するストリームへ影響を限定しやすい |
| TLSはTCP上で利用 | TLS 1.3がQUICへ統合 |
HTTP/2とHTTP/3を理解するなら、まずこの違いを押さえるのが重要です。
HTTP/3ではHead-of-Line Blockingがなくなる？
「すべての待ち時間がなくなる」という意味ではありません。
QUICでは、あるストリームのパケットが失われても、別のストリームで必要なデータが届いていれば、そのストリームの処理を進められます。
これによってHTTP/2＋TCPで問題となる、
一つのパケット損失によって接続上のすべてのストリームが待たされる
という影響を軽減できます。
ただしネットワークの輻輳などは接続全体の送信速度に影響するため、
「パケットロスが起きてもHTTP/3なら何の影響もない」
わけではありません。
HTTP/3とTLS 1.3の関係
HTTP/3で利用されるQUICでは、
TLS 1.3
がプロトコルに統合されています。
RFC 9114では、QUIC Version 1がTLS 1.3以上をハンドシェイクプロトコルとして利用すると規定しています。
つまりHTTP/3では、暗号化が後から付け足されたオプションではなく、QUICの通信確立に組み込まれています。
HTTP/2は暗号化されていないこともある？
HTTP/2の仕様そのものは、理論上TLSを使わない運用も考えられます。
しかし現在の一般的なWebブラウザでは、HTTP/2はHTTPS、つまりTLSと組み合わせて利用されるのが基本です。
RFC 9113ではHTTPS URIへHTTP/2で接続するとき、TLSとALPNを利用して、
h2
というプロトコル識別子をネゴシエートすることが規定されています。
以前存在した、平文HTTP/2へのUpgradeを示す、
h2c
は広く普及せず、現在のRFC 9113ではそのUpgrade方式が非推奨となっています。
「ALPN」とは？
ALPNは、
Application-Layer Protocol Negotiation
の略です。
TLS接続時に、クライアントとサーバーが、
「どのアプリケーションプロトコルを使うか」
を決めるための仕組みです。
たとえばHTTP/2 over TLSでは、
h2
という識別子を利用します。
利用者がURLへ、
https://example.com/http2/
などと特別な指定をする必要はありません。
ブラウザとサーバーが自動的に対応可能なプロトコルを選択します。
HTTP/3を使うにはURLを変える？
変える必要はありません。
HTTP/2でもHTTP/3でも、利用者が開くURLは通常、
https://example.com/
のままです。
HTTP/3だから、
http3://
というURLになるわけではありません。
HTTPのバージョンは、ブラウザとサーバーが通信時に選択します。
HTTP/3対応サイトをHTTP/2対応ブラウザで開くと？
HTTP/3だけしか使えないようにする必要はありません。
一般的なWebサービスでは、
- HTTP/3
- HTTP/2
- 場合によってはHTTP/1.1
を必要に応じて使い分けられるようにします。
クライアントがHTTP/3に対応していなかったり、ネットワーク環境でQUICが利用できなかったりする場合は、HTTP/2などへフォールバックできます。
UDPがブロックされたらHTTP/3は使えない？
ネットワーク環境によっては、QUICで利用するUDP通信が制限される場合があります。
その場合、WebブラウザはHTTP/2など別の方式へ切り替えて通信できることがあります。
そのためWebサイト運営者は、
HTTP/3だけを唯一の通信方法にする
のではなく、HTTP/2等との互換性を維持するのが一般的です。
HTTP/3の「Connection ID」とは？
QUICでは接続を、単純なIPアドレスとポート番号の組み合わせだけではなく、
Connection ID
によって識別できます。
これによって、たとえばスマートフォンが、
Wi-Fi → 携帯電話回線
へ移動し、IPアドレスが変わった場合でも、条件が整えば同じQUIC接続を継続できます。
TCPではIPアドレス等が変化すると、通常は新しい接続を確立する必要があります。
このためQUICは、ネットワークを頻繁に切り替えるモバイル環境と相性のよい設計になっています。
HTTP/3の「0-RTT」とは？
QUIC・TLSでは、以前接続したことがあるサーバーへの再接続で、条件によって、
0-RTT
と呼ばれる早期データ送信を利用できる場合があります。
通常は通信を始める前に一定のハンドシェイクが必要ですが、0-RTTでは過去の接続情報を利用し、より早い段階からアプリケーションデータを送信できます。
ただし0-RTTデータには、
リプレイ攻撃
に関する注意があります。
そのため、どのHTTPリクエストでも無条件に0-RTTで送信すればよいわけではありません。
HTTP/2のHPACKとHTTP/3のQPACKの違い
HTTP/2ではヘッダー圧縮に、
HPACK
を利用します。
HTTP/3では、
QPACK
を利用します。
QPACKはQUICの複数ストリーム環境へ適したHTTPフィールド圧縮方式です。
HTTP/2のHPACKをそのままQUICへ持ち込むと、動的テーブルへの依存によって別のブロッキング問題が起きる可能性があります。
そこでHTTP/3ではQUIC環境に合わせてQPACKが設計されています。
| HTTP/2 | HTTP/3 |
|---|---|
| HPACK | QPACK |
| TCP環境を前提 | QUICの独立ストリームに対応 |
HTTP/3のほうが必ず高速？
必ずしもそうではありません。
HTTP/3の設計上の利点は、特に、
- パケットロスが発生しやすい環境
- 遅延が大きい回線
- モバイル通信
- ネットワーク切り替えが起こる環境
などで発揮される可能性があります。
一方、
- 高速で安定した回線
- サーバー実装
- ブラウザ実装
- CDN構成
- 輻輳制御アルゴリズム
- コンテンツ量
などによっては、HTTP/2との体感差がほとんどないこともあります。
Cloudflareも、HTTP/3が損失のあるネットワークで優位になる可能性を説明する一方、性能はネットワーク条件や実装によって変わるとしています。
したがって、
「HTTP/3ならページ表示が必ず何％高速になる」
とは断定できません。
HTTP/3にするとHTMLやWordPressを変更する？
通常、WebページのHTMLをHTTP/3専用に書き換える必要はありません。
HTTP/2・HTTP/3の違いは主に、
ブラウザとWebサーバー・CDNの間でデータをどのように運ぶか
という通信層の違いだからです。
WordPressの記事本文やHTML構造を、
「HTTP/3用HTML」
へ変更する必要はありません。
HTTP/3への対応は、主に、
- Webサーバー
- CDN
- ロードバランサー
- ホスティングサービス
側で行います。
HTTP/3にすればSEO順位が上がる？
HTTP/3を有効にしただけで、検索順位が直接上がると考えるべきではありません。
HTTP/3によって実際のユーザー環境で表示性能・安定性が改善すれば、ユーザー体験の改善につながる可能性はあります。
しかし検索順位は、
- コンテンツの品質
- 検索意図との一致
- サイト構造
- ページエクスペリエンス
- 多数のその他のシグナル
などを含めて総合的に決まります。
HTTP/3は、
SEOテクニックというより、Web通信を効率化するインフラ技術
として考えるのが適切です。
HTTP/2の「Server Push」はHTTP/3でも使う？
HTTP/2では、クライアントが要求する前にサーバーからリソースを送る、
Server Push
という仕組みが導入されました。
HTTP/3の仕様にもPushに関する仕組みがあります。
しかし実際のWebブラウザではHTTP/2 Server Pushは期待した効果を得るのが難しく、主要ブラウザでサポートが縮小・削除されています。
現在は、
- preload
- 103 Early Hints
など別の方法が利用されることがあります。
そのため、
「HTTP/2の最大の利点はServer Push」
と覚えるのは現在では適切ではありません。
HTTP/2からHTTP/3へ完全移行する必要はある？
必ずしも、HTTP/2を廃止してHTTP/3だけにする必要はありません。
現在の現実的な運用は、
HTTP/3を利用できるクライアントにはHTTP/3を提供し、それ以外にはHTTP/2等を提供する
という形です。
利用者がプロトコルを手動で選ぶ必要はなく、ブラウザ・サーバー・CDNが対応状況に応じて処理します。
自分のWebサイトがHTTP/3対応か確認する方法
Webブラウザの開発者ツールなどで、各リクエストに利用されたプロトコルを確認できる場合があります。
たとえば、
- h2
- h3
などの表示です。
一般的に、
h2＝HTTP/2
h3＝HTTP/3
を表します。
ただしブラウザの表示方法はバージョンによって異なるため、具体的な確認手順は使用しているブラウザの最新情報を確認してください。
HTTP/3に対応するにはUDP 443も重要
HTTPSのHTTP/2では、一般にTCPの443番ポートが利用されます。
HTTP/3ではQUICがUDPを利用するため、
UDP 443
で通信する構成が一般的です。
そのため、
- ファイアウォール
- ネットワーク機器
- サーバー
- CDN
などがQUIC通信へ対応している必要があります。
HTTP/3が利用できない場合でも、HTTP/2等へフォールバックできる構成にすることが重要です。
「HTTP/2・HTTP/3」で迷ったときの3秒判定
| こんな場合 | 答え |
|---|---|
| TCPを利用する | HTTP/2 |
| QUICを利用する | HTTP/3 |
| UDPを基盤にする | HTTP/3 |
| ヘッダー圧縮にHPACK | HTTP/2 |
| ヘッダー圧縮にQPACK | HTTP/3 |
| TCPレベルのHead-of-Line Blockingが残る | HTTP/2 |
| QUICのストリーム単位で損失の影響を分離しやすい | HTTP/3 |
| h2 | HTTP/2 |
| h3 | HTTP/3 |
最も簡単に覚えるなら、
HTTP/2＝「TCPで進化したHTTP」
HTTP/3＝「QUICへ移行したHTTP」
です。
「HTTP/2」を使った例文
- WebサーバーでHTTP/2を有効にする。
- HTTP/2では複数のストリームを1つの接続上で多重化できる。
- HTTP/2はヘッダー圧縮にHPACKを利用する。
- ブラウザがHTTP/2のh2をネゴシエートした。
- HTTP/2ではTCPレベルのHead-of-Line Blockingが残る。
「HTTP/3」を使った例文
- CDNでHTTP/3を有効化する。
- HTTP/3はQUIC上で動作する。
- HTTP/3はQPACKでHTTPフィールドを圧縮する。
- モバイル環境でHTTP/3の利点が発揮される場合がある。
- 利用できない環境ではHTTP/3からHTTP/2へフォールバックする。
具体例で比較：画像を大量に読み込むWebページ
Webページで50枚の画像を読み込むとします。
HTTP/2では、複数の画像リクエストを一つのTCP接続上の複数ストリームとして並行処理できます。
HTTP/1.1に比べて効率的ですが、通信途中でTCPパケットが失われると、その再送を待つ間、同じTCP接続上の別ストリームも影響を受ける可能性があります。
HTTP/3ではQUICがストリームを独立して扱うため、一つのストリームに必要なデータが失われても、別ストリームで必要なデータが揃っていれば処理を進められます。
具体例で比較：スマートフォンで移動する
スマートフォンでWebサイトを閲覧しながら家を出て、
自宅Wi-Fi → 5G・4G
へ切り替わったとします。
TCP接続ではネットワーク環境が変化すると、接続の再確立が必要になる場合があります。
QUICではConnection IDを利用することで、IPアドレスが変化しても接続を継続できる場合があります。
この点はHTTP/3がモバイル環境で期待される理由の一つです。
よくある間違い1：「HTTP/3はHTTP/2と内容が違う」と思う
HTTPの基本的な意味は維持されています。
GET、POST、ステータスコード、HTTPフィールドなどの基本概念は共通です。
大きく変わるのは通信データの運び方です。
よくある間違い2：「HTTP/3はUDPなので信頼性がない」と思う
HTTP/3はUDPを直接そのまま利用するのではなく、QUICを利用します。
QUIC自身が再送・損失回復・輻輳制御などの仕組みを備えています。
よくある間違い3：「HTTP/3なら必ずHTTP/2より速い」と思う
ネットワーク条件や実装によって変わります。
特に損失・遅延が大きい環境ではHTTP/3の利点が出やすい一方、安定した高速回線では差が小さい場合もあります。
よくある間違い4：「HTTP/3ならHTTPSは不要」と思う
違います。
HTTP/3で利用するQUICにはTLS 1.3が組み込まれており、暗号化・完全性・認証が前提になっています。
よくある間違い5：「HTTP/3にするとURLも変わる」と思う
通常は変わりません。
https://で始まる同じURLへアクセスし、ブラウザとサーバーが利用するHTTPバージョンを自動的に決めます。
よくある間違い6：「HTTP/3にしたらHTTP/2を無効にすべき」と思う
HTTP/3を利用できないネットワーク・クライアントも考えられるため、HTTP/2等へのフォールバックを用意するのが一般的です。
よくある間違い7：「HTTP/3を入れればSEO対策は完了」と思う
HTTP/3はWeb通信の効率化技術です。
実際の表示性能が改善すればユーザー体験向上にはつながりますが、検索順位はプロトコルだけで決まりません。
「HTTP/2」と「HTTP/3」に関するよくある質問
Q1. 「HTTP/2」と「HTTP/3」の一番簡単な違いは？
HTTP/2は主にTCP上で動き、HTTP/3はQUIC上で動くことが最大の違いです。
Q2. QUICとHTTP/3は同じですか？
同じではありません。
QUICはトランスポートプロトコルで、HTTP/3はHTTPのセマンティクスをQUIC上で利用するためのプロトコルです。
Q3. HTTP/3はTCPを使いますか？
通常は使いません。
HTTP/3はQUICを利用し、QUICはUDPを基盤としています。
Q4. HTTP/2でも複数リクエストを同時に処理できますか？
はい。
HTTP/2は一つの接続上に複数ストリームを作り、リクエスト・レスポンスを多重化できます。
Q5. HTTP/3ならパケットロスの影響を受けませんか？
影響は受けます。
ただしQUICでは、あるストリームの損失によって別の独立したストリームまでTCPのように一律に待たされる問題を軽減できます。
Q6. HTTP/3は暗号化されていますか？
はい。
HTTP/3が利用するQUICではTLS 1.3が統合されており、通信の機密性・完全性・相手認証を提供します。
Q7. HTTP/3を使うにはサイトのURLを変更しますか？
いいえ。
通常は同じhttps://のURLを利用します。
Q8. WordPressでもHTTP/3を使えますか？
利用できます。
ただしWordPressの記事側で設定するというより、利用しているサーバー・CDN・ホスティングサービスがHTTP/3へ対応しているかが重要です。
Q9. HTTP/2はもう古いので使わないほうがよいですか？
HTTP/2は現在も広く利用されている標準です。
HTTP/3対応と同時にHTTP/2も提供し、環境に応じて自動的に使い分ける運用が一般的です。
Q10. HTTP/3へ対応する価値はありますか？
利用者が多いWebサイトやCDNを利用するサイトでは、HTTP/3を利用できるようにすることで、特にモバイル回線やパケットロスのある環境で通信性能・安定性が改善する可能性があります。
ただし実際の効果はサイト・ネットワーク条件によって異なるため、HTTP/3だけを高速化の万能策と考えないことが重要です。
まとめ
「HTTP/2」と「HTTP/3」は、どちらもHTTP通信を効率化するためのプロトコルですが、最大の違いは下位の通信方式です。
| HTTP/2 | HTTP/3 |
|---|---|
| RFC 9113 | RFC 9114 |
| 主にTCP | QUIC |
| 一つのTCP接続上でストリームを多重化 | QUICが独立した複数ストリームを提供 |
| TCPレベルのHead-of-Line Blockingが残る | ストリーム間の損失影響を分離しやすい |
| HPACK | QPACK |
| TLSとTCPを組み合わせる | TLS 1.3がQUICに統合 |
最も簡単な覚え方は、
HTTP/2＝「TCPを使って効率化したHTTP」
HTTP/3＝「QUICへ移行してさらに通信上の制約を改善したHTTP」
です。
HTTP/2の時点で、
- 複数ストリームの多重化
- バイナリフレーミング
- HPACKによるヘッダー圧縮
など、大きな改善が行われました。
しかしHTTP/2はTCPを利用するため、1つのTCPパケットが失われると、同じ接続上の複数ストリームが再送を待つ、
TCPレベルのHead-of-Line Blocking
が残ります。
HTTP/3ではTCPの代わりにQUICを採用し、
- ストリームごとの独立した損失回復
- TLS 1.3との統合
- 効率的な接続確立
- ネットワーク変更への対応
などを実現しています。
ただし、
HTTP/3＝必ずHTTP/2より速い
というわけではありません。
実際の速度差は回線品質、パケットロス、遅延、サーバーやCDNの実装などによって変わります。
またHTTP/3に対応してもHTTP/2を捨てる必要はありません。
現在の現実的な運用では、
HTTP/3を使える環境ではHTTP/3、それ以外ではHTTP/2などへ自動的に切り替える
形が基本です。
「HTTP/2」「HTTP/3」「QUIC」を整理するなら、
HTTP/2＝HTTP over TCP
HTTP/3＝HTTP over QUIC
QUIC＝UDPを基盤にした安全で多重化可能なトランスポートプロトコル
と覚えると理解しやすいでしょう。
参考リンク・出典
-
IETF / RFC Editor「RFC 9113: HTTP/2」
― HTTP/2を規定する現行RFC。ストリーム多重化、バイナリフレーミング、TLS利用時のh2識別子などを規定し、旧RFC 7540を置き換えている -
IETF / RFC Editor「RFC 9114: HTTP/3」
― HTTP/3をHTTP semanticsのQUIC上へのマッピングとして規定。HTTP/2で残るTCPレベルのHead-of-Line Blocking、QUICによるストリーム多重化、TLS 1.3との統合などを説明 -
IETF / RFC Editor「RFC 9000: QUIC: A UDP-Based Multiplexed and Secure Transport」
― HTTP/3の基盤となるQUICを、UDPベースで多重化・暗号化された安全なトランスポートプロトコルとして標準化 -
IETF / RFC Editor「RFC 9204: QPACK: Field Compression for HTTP/3」
― HTTP/3で利用するQPACKフィールド圧縮方式を規定。QUICのストリーム構造に適した圧縮方式を定義 -
MDN Web Docs「HTTP/3」
― HTTP/3がHTTP/2の後継であり、TCPではなくUDPベースのQUICを利用すること、遅延やHead-of-Line Blockingの改善について解説 -
MDN Web Docs「HTTP messages」
― HTTP/2の多重化とTCPレベルのHead-of-Line Blocking、HTTP/3がQUICを利用してその問題を改善する仕組みを解説 -
Cloudflare「HTTP/3とは？」
― HTTP/3とQUIC、UDP、ネットワーク切り替え、Head-of-Line Blocking、接続確立などHTTP/2との主な違いを解説 -
Cloudflare Docs「HTTP/3 (with QUIC)」
― HTTP/3の現在の提供状況と、QUICがTCPのHead-of-Line Blocking問題を改善し、損失の多いネットワークで性能向上が期待できることを説明
※本記事では一般ユーザー・Webサイト運営者向けに、「HTTP/2＝主にTCP上で動作」「HTTP/3＝QUIC上で動作」と整理しています。
※HTTP/3は「UDPをそのまま使って信頼性を捨てた通信」ではありません。QUICがUDP上で再送・損失回復・輻輳制御・ストリーム管理・暗号化等を提供します。
※HTTP/3はHTTP/2より常に高速とは限りません。ネットワーク遅延、パケットロス、回線品質、サーバー・ブラウザ・CDNの実装等によって性能差は変化します。
※HTTP/3を導入しても、通常はHTML・CSS・WordPressの記事そのものを書き換える必要はありません。対応は主にWebサーバー・CDN・ホスティング環境側で行います。
※HTTP・QUIC・TLS・ブラウザ実装は今後も更新される可能性があります。実際にHTTP/3を設定・運用する場合は、IETF、利用中のWebサーバー、CDN、ホスティング事業者等の最新情報を確認してください。
