HTTP/3は、Webサイトを表示するときに使われるHTTPの新しい世代です。名前だけ見ると「HTMLの書き方が変わるのか」「URLが変わるのか」と思いがちですが、基本的にはそうではありません。
HTTP/3で大きく変わるのは、ブラウザとサーバーの間でデータを運ぶ土台です。HTTP/1.1やHTTP/2はTCPの上で動いていました。HTTP/3は、QUICというUDPベースの通信プロトコルの上でHTTPを動かします。
たとえるなら、注文書の書き方そのものは大きく変えず、配送方法を変えるようなものです。これにより、通信の始まりを短くしたり、途中で一部のデータが失われたときの待ち時間を減らしたり、スマートフォンがWi-Fiからモバイル回線へ切り替わる場面で接続を保ちやすくしたりできます。
HTTP/3は「HTTPをQUICで運ぶ仕組み」
IETFのRFC 9114では、HTTP/3はHTTPの意味をQUIC上へ対応させる仕様として定義されています。ここでいうHTTPの意味とは、リクエスト、レスポンス、ヘッダー、ステータスコードといった、Webアプリケーションが普段扱っている考え方です。
つまり、HTTP/3になったからといって、GETやPOSTが別物になるわけではありません。WebサイトのURLも、通常はhttps://のままです。変わるのは、ブラウザとサーバー、またはブラウザとCDNの間で、HTTPのデータをどう分けて、どう暗号化し、どう再送するかという通信の下側です。
| 世代 | ざっくりした運び方 | 理解のポイント |
|---|---|---|
| HTTP/1.1 | TCP上で順番にやり取りする | 複数ファイルの読み込みでは待ちが出やすい |
| HTTP/2 | TCP上の1本の接続で複数の流れを多重化する | 効率は上がったが、TCPの詰まりは残る |
| HTTP/3 | QUIC上で複数の流れを扱う | 一部の損失が他の流れへ広がりにくい |
ここで重要なのは、HTTP/2が悪いという話ではないことです。HTTP/2は今でも広く使われています。HTTP/3は、特にパケット損失があるネットワーク、モバイル回線、接続の開始が多い場面で、より有利に働きやすい選択肢です。
HTTP/2で残っていた「詰まり」を小さくする
HTTP/2は、1本のTCP接続の中で、HTML、CSS、JavaScript、画像などを並行して運べるようにしました。これはHTTP/1.1からの大きな改善です。
ただし、HTTP/2の下にはTCPがあります。TCPは、届かなかったデータがあると、その接続の後続データをアプリケーションへ渡す前に、失われた部分の再送を待ちます。そのため、ある画像の一部が失われただけでも、同じTCP接続に乗っている別のデータまで待ちやすくなります。これは、head-of-line blockingと呼ばれる問題です。
QUICは複数のストリームを通信の土台側で扱います。RFC 9000でも、QUICの利点として、複数ストリーム間のhead-of-line blockingを避けやすいことが説明されています。失われたデータを含むストリームは再送を待ちますが、関係のない別ストリームは進められます。
例1：画像が多いページで一部だけ詰まる
たとえば、商品一覧ページや記事一覧ページのように、1ページ内に画像が多い画面を考えます。ブラウザはHTML、CSS、JavaScript、複数の画像をまとめて取りにいきます。
HTTP/2では、それらを1本のTCP接続で効率よく運べます。しかし、通信途中で一部のパケットが失われると、TCPの仕組みにより、その接続で後ろに並んでいるデータも待ちやすくなります。たとえるなら、1本の道路で前の荷物が止まると、後ろの荷物も一緒に止まる状態です。
HTTP/3では、QUICが複数の流れを意識して扱います。ある画像に関係するデータが再送待ちになっても、別の画像やCSSの流れは進められる可能性があります。実際の体感差はサイト構成やネットワーク状況によりますが、通信が不安定な環境では違いが出やすくなります。
例2：ブラウザがHTTP/3を見つける流れ
HTTP/3は、URLをhttp3://のように変えて使うものではありません。多くの場合、ブラウザはまずHTTP/2やHTTP/1.1で接続し、サーバーからのAlt-Svcヘッダーを見て、次回以降にHTTP/3を試します。
Alt-Svcは、同じサイトを別のプロトコルでも扱えることをブラウザへ知らせます。HTTP/3接続に失敗した場合は、HTTP/2などへ戻れることも重要です。RFC 9114では、HTTP/3の利用可能性をAlt-SvcヘッダーやHTTP/2のALTSVCフレームで知らせられると説明されています。たとえばAlt-Svc: h3=":443"は、同じホストのUDP 443番ポートでHTTP/3を使えることを示します。
この仕組みのおかげで、HTTP/3に対応していないブラウザや、企業ネットワークなどでUDP 443が通らない環境でも、HTTP/2やHTTP/1.1へ戻せます。HTTP/3は「使えないとサイトが見えない」方式ではなく、対応できる環境では新しい経路を使う方式として導入されることが多いです。
例3：最初の接続が短くなりやすい
Webページを開くときは、実際のデータを受け取る前に、接続の準備が必要です。HTTP/2では、TCP接続を作り、その上でTLSの暗号化を始め、その後にHTTPのやり取りへ進みます。
HTTP/3では、QUICの中に暗号化の仕組みが組み込まれています。そのため、接続開始の段階をまとめやすく、特に初回接続や再接続の待ち時間を短くできる場合があります。ただし、サイトの表示全体は画像サイズやJavaScriptの実行時間にも左右されるため、接続開始だけで速度を判断しないことが大切です。
例4：スマートフォンで回線が切り替わる
スマートフォンでページを見ていると、Wi-Fiからモバイル回線へ切り替わることがあります。TCPでは、接続がIPアドレスやポートの組み合わせに強く結びつくため、ネットワークが切り替わると接続を作り直す必要が出やすくなります。
QUICは接続IDを使って接続を識別できるため、ネットワークの切り替わりに対して柔軟に扱いやすい設計です。AWS CloudFrontのHTTP/3説明でも、Wi-Fiと携帯回線の切り替えのような場面で、接続移行により中断を抑えやすいことが説明されています。
これは、移動中に管理画面を見たり、スマートフォンで予約や問い合わせフォームを操作したりする利用者にとって意味があります。必ず劇的に速くなるというより、「不安定な場面で失敗しにくくなる可能性がある」と捉えると実務に近い理解になります。
例5：CDNを使うと、サーバー本体を変えずに始められる場合がある
HTTP/3を導入する方法は、サーバーソフトウェアで直接対応する方法だけではありません。CloudFrontのようなCDNを使う場合、閲覧者とCDNエッジの間だけHTTP/3にし、CDNからオリジンへの通信は従来の方式のままにできる場合があります。
AWSのCloudFront HTTP/3サポート説明では、HTTP/3を有効にすると、利用者はCloudFrontエッジロケーションへHTTP/3でリクエストでき、オリジン側にサーバー変更を加えずに利用できる趣旨が説明されています。小規模なWebサイトでは、この形が現実的な導入ルートになることがあります。
坂本商店の公式サイトでも、CloudFrontからの応答にalt-svc: h3=":443"; ma=86400が含まれることを確認できます。これは、ブラウザに「同じサイトへHTTP/3でも接続できます」と知らせるための案内です。
HTTP/3で必ず速くなるわけではない
HTTP/3は便利ですが、すべてのサイトで必ず体感速度が上がるわけではありません。ページが重い原因が、画像サイズ、JavaScriptの実行時間、サーバー側の処理、データベースの遅さにある場合、通信プロトコルだけを変えても効果は限定的です。
HTTP/3が効きやすいのは、通信の開始や再接続、パケット損失、モバイル回線の揺れがボトルネックになっている場面です。一方で、同じオフィス内の安定した回線から見る小さなページでは、差が分かりにくいこともあります。
そのため、実務では「HTTP/3を有効にしたから完了」ではなく、次のように切り分けて確認するのが現実的です。
- レスポンスヘッダーに
Alt-Svcが出ているか - CDNやサーバーでHTTP/3が有効になっているか
- UDP 443がネットワーク上で遮断されていないか
- ブラウザの開発者ツールでプロトコル列が
h3になっているか curl --http3に対応したcurlでHTTP/3接続を試せるか
Alt-Svc、ブラウザ側のh3表示を順に見ると切り分けやすくなります。確認コマンドの例
まず、HTTP/3を案内しているかはレスポンスヘッダーで確認できます。
curl -I https://example.com/出力に次のようなヘッダーがあれば、少なくともサーバー側はHTTP/3の利用可能性を案内しています。
alt-svc: h3=":443"; ma=86400ただし、Alt-Svcが見えることと、実際にHTTP/3で通信できていることは別です。実際の通信プロトコルは、ブラウザの開発者ツールのNetworkタブでProtocol列を表示するか、HTTP/3対応のcurlで確認します。
curl --http3 -I https://example.com/手元のcurlがHTTP/3に対応していない場合、このオプションは使えません。その場合は、ブラウザ側で確認するか、HTTP/3対応のcurlを用意して検証します。
導入時の注意点
HTTP/3はQUICを使うため、TCPではなくUDP 443番ポートの通信が関係します。サーバー、ロードバランサー、CDN、ファイアウォール、WAF、社内プロキシのどこかでUDP 443が遮断されていると、HTTP/3で接続できないことがあります。
また、ログや監視の見え方も確認しておく必要があります。HTTP/2やHTTP/1.1では見えていた情報が、HTTP/3やCDN経由で同じように取れるとは限りません。障害対応を考えるなら、「HTTP/3で見えているユーザー」と「HTTP/2へ戻っているユーザー」を区別できるかも確認点になります。
小規模サイトでは、まずCDN側のHTTP/3有効化、レスポンスヘッダー確認、ブラウザでの表示確認、フォームやログイン画面の動作確認から始めるのが現実的です。体感速度の改善だけでなく、問題が起きたときにすぐHTTP/2へ戻せる設定かどうかも見ておくと安心です。
参考情報
- RFC 9114: HTTP/3
- RFC 9000: QUIC: A UDP-Based Multiplexed and Secure Transport
- MDN Web Docs: Alt-Svc header
- AWS News Blog: New – HTTP/3 Support for Amazon CloudFront
- Can I use: HTTP/3 protocol
まとめ
HTTP/3は、Webサイトの見た目やURLを変える技術ではなく、HTTPをQUICという新しい土台で運ぶための仕組みです。HTTP/2までのTCPベースの通信で残っていた詰まりを小さくし、接続開始やモバイル環境での切り替わりを扱いやすくする狙いがあります。
ただし、HTTP/3は万能の高速化スイッチではありません。画像やJavaScriptが重い、サーバー処理が遅い、キャッシュが効いていないといった問題は別に解決する必要があります。まずはAlt-Svc、UDP 443、ブラウザのProtocol列を確認し、「自分のサイトでHTTP/3がどこまで効いているか」を小さく見ていくのがよい進め方です。
