HTTP/3とQUICの仕組みとは？UDP採用の理由と通信高速化の秘密

ITエンジニアにお勧めの本 ↗

おすすめ

エンジニアが知っておきたい思考の整理術 複雑な情報を【理解する】【伝える】テクニック

難易度

実用性

図解

こんな人におすすめ： ドキュメント作成や説明に課題を感じているエンジニア

思考の整理というテーマを、実務ですぐに使える具体的な「技術」として落とし込んだ一冊です。

Amazon 🔴 楽天 📝 書評を読む

ベストセラー

世界一流エンジニアの思考法

難易度

実用性

思考法

こんな人におすすめ： 全エンジニア、生産性を上げたいリーダー

技術スキル以上に大切な「考え方」をアップデートできる。世界基準の効率的な仕事術が学べます。

Amazon 🔴 楽天

文系社会人のためのIT資格の歩き方: 文系のあなたに最適な道をご提案します (YKcreate kiki)

難易度

実用性

キャリア度

こんな人におすすめ： どの資格から取ればいいか迷っている文系出身者

ロードマップが非常に明確。キャリアプランを見据えた、無駄のない学習順序を提案してくれます。

Amazon

エンジニアを説明上手にする本 相手に応じた技術情報や知識の伝え方

難易度

実用性

コミュ力

こんな人におすすめ： 非エンジニアへの説明に苦労している技術者

「伝える技術」もエンジニアの重要なスキル。相手の視点に立った、具体的な説明のコツが満載です。

Amazon 🔴 楽天

技術広報入門 ー テックブログから始めるエンジニアカルチャーのつくり方

難易度

実用性

独自性

こんな人におすすめ： 技術リーダー・CTO、組織のカルチャー変革に取り組みたい人

テックブログを入口にエンジニア組織の文化をどう設計し、育てていくかという実践論が学べます。

Amazon 🔴 楽天 📝 書評を読む

📚 ITエンジニア向けおすすめ技術書・関連書籍まとめはこちら

ウェブブラウザで Web サイトを閲覧する際、長年にわたりインターネットを支えてきた通信プロトコルが HTTPHTTP [エイチティーティーピー]HyperText Transfer Protocol。Webでのデータ転送プロトコル（Hypertext Transfer Protocol） です。現在、私たちが日常的に利用している Web の裏側では、新たな標準規格である HTTP/3 への移行が急速に進んでいます。

HTTP/3 の最大の特徴は、従来の HTTP/1.1 や HTTP/2 が前提としていた TCPTCP [ティーシーピー]Transmission Control Protocol。信頼性の高い通信プロトコル（Transmission Control Protocol） を捨て、トランスポート層に UDP（User Datagram Protocol） をベースとした新プロトコル QUIC（クイック） を採用した点にあります。

「信頼性の高い TCP をやめて、なぜ信頼性のない UDP を使うのか？」「通信はどうやって高速化されているのか？」と疑問に思う方も多いのではないでしょうか。

この記事では、HTTP/3 と QUIC の基本概念から、UDP を採用した深い理由、HTTP/2 のボトルネックを解消する仕組み、そしてブラウザとサーバーが HTTP/3 で通信を確立する流れまで、図解を交えて分かりやすく解説します。

HTTP/3とQUICとは？プロトコル階層の大きな変革

HTTP/3 は、2022 年 6 月に RFC 9114 として正式に標準化された HTTP の第 3 世代メジャーバージョンです。そして、その通信の土台（トランスポート層）を担うのが 2021 年 5 月に RFC 9000 で標準化された QUIC（UDP をベースとした、低遅延・多重化対応のトランスポートプロトコル） です。

従来の HTTP と HTTP/3 の最大の違いを理解するために、まずはプロトコルスタック（階層構造）の比較を見てみましょう。

プロトコルスタックの比較

従来の HTTPSHTTPS [エイチティーティーピーエス]HTTP Secure。暗号化されたHTTP（HTTP/1.1 や HTTP/2）と HTTP/3 では、下位層の組み合わせが大きく異なります。

従来の Web 通信（HTTPS）では、TCPとUDPの違い にあるように、コネクションの信頼性を担保する TCP の上で、暗号化を担う TLSTLS [ティーエルエス]Transport Layer Security。SSLの後継となる安全性の高い暗号化通信プロトコル 1.2 / TLS 1.3 （TLSハンドシェイクの仕組み）が動作し、その上で HTTP/1.1 や HTTP/2 がやり取りされていました。

一方、HTTP/3 では UDP の上に QUIC というトランスポートプロトコルを構築しています。QUIC 自体が TLS 1.3 のハンドシェイクと暗号化機能、さらに ストリームの多重化・順序制御・再送制御・輻輳制御 を統合しているため、従来のように TLS を独立した層として QUIC の上に重ねる構成にはなりません。なお、HTTP/3 ではヘッダー圧縮方式として QPACK が採用されています。

なぜTCPではなく「UDP」を採用したのか？2つの理由

ネットワークを学ぶ際、「Web 通信のように 1 バイトの欠落も許されない通信には TCP を使う」と教わった方も多いはずです。では、なぜ HTTP/3 は TCP ではなく UDP を選んだのでしょうか。そこにはインターネットの構造的な課題がありました。

1. プロトコルの硬直化（Ossification）の壁

TCP は 1970 年代から使われている非常に古いプロトコルです。世界中のルーター、ファイアウォール、ロードバランサーなどの通信機器（ミドルボックス）は、TCP のパケット構造（フラグやヘッダー形式）を前提に最適化・フィルタリングを行っています。

もし TCP そのものに新しい暗号化機能やマルチストリーム機能を追加しようとすると、世界中に無数に存在する古いネットワーク機器が「未知の不正なパケット」とみなして通信を破棄（ドロップ）してしまいます。これをネットワークの プロトコル硬直化（Protocol Ossification） と呼びます。

一方、UDP は「送信元ポート番号」「宛先ポート番号」「パケット長」「チェックサム」の 4 つのフィールドからなる、8 バイトのシンプルなヘッダーを持ちます（チェックサムは IPv4IPv4 [アイピーブイフォー]インターネットプロトコル第4版。32ビットでIPアドレスを表現する では省略可能ですが、IPv6IPv6 [アイピーブイシックス]インターネットプロトコル第6版。128ビットでIPアドレスを表現し枯渇問題を解決する では原則として必須です）。UDP は既存のネットワーク環境で広く利用されているため、その上に新しいトランスポートプロトコルを構築しやすいという利点があります。

また、QUIC ではトランスポート層の制御情報の多くが暗号化されるため、ネットワーク機器が特定のヘッダー構造やフィールドの値に依存しにくくなります。こうした設計によって、従来の TCP を直接変更する場合と比べて、新しい機能や仕様を導入しやすくしています。ただし、UDP 通信自体がファイアウォールなどによって遮断される可能性はあります。

2. OSカーネル依存からの脱却と迅速なアップデート

一般的な TCP の実装は、LinuxLinux [リナックス / ライナックス]オープンソースのOSカーネル や Windows などの OSOS [オーエス]Operating System。基本ソフトウェア カーネル内部 にあります。そのため、標準的な TCP スタックの機能やアルゴリズムを変更・拡張するには、カーネルや OS 側の対応が必要になることが多く、広く普及させるには時間がかかります。

しかし、UDP 上に構築された QUIC は、一般的な実装では ユーザー空間（アプリケーション側） で動作させることができます。そのため、ブラウザ（Chrome, Firefox, Safari 等）や Web サーバー（NginxNginx [エンジンエックス]高性能なWebサーバー・リバースプロキシ, Caddy, Cloudflare 等）に QUIC 実装ライブラリを組み込むことで、OS のカーネル更新を待たずに機能改善を進められます。

HTTP/3とQUICが解決するWeb通信の3大課題

HTTP/2 でもストリームの多重化によって通信の並行処理が行われていましたが、依然として解消できない課題が残されていました。HTTP/3 と QUIC は、以下の 3つの課題 に取り組んでいます。

課題1：TCP層のHead-of-Line（HoL）ブロッキングの解消

HTTP/2 では、1 本の TCP コネクションの中で複数のリクエストやレスポンスを「ストリーム」として多重化して送受信していました。

しかし、下位層が TCP である以上、TCP はすべてのデータを 1 つの連続したバイトストリーム として順序どおりにアプリケーションへ引き渡す仕組みを持っています。そのため、通信経路でパケットロス（パケットの紛失）が発生すると、後続のデータが正常に到着していても、欠落したデータが再送されて順序が揃うまで、アプリケーションへのデータの引き渡しがブロックされます。

これを TCP 層の Head-of-Line（HoL）ブロッキング と呼びます。不安定なモバイル回線や Wi-Fi 環境では、1 つのパケットロスによって Web ページ全体の読み込みがピタッと止まってしまう原因になっていました。

QUICによる解決アプローチ

QUIC は、トランスポート層自体が 独立した複数のストリーム を直接管理します。

QUIC ではストリームごとに独立して順序制御が行われるため、あるストリームでパケットロスが発生しても、別のストリームでは欠落したデータの再送を待たずに受信データを処理できます。これにより、回線品質が悪い環境でも表示速度の低下を抑えられます。

ただし、同一ストリーム内では欠落したデータが再送されるまで後続データをアプリケーションに引き渡せません。また、輻輳制御などはコネクション単位で行われるため、パケットロスが他のストリームの通信速度に影響する場合もあります。

課題2：ハンドシェイク遅延の短縮（1-RTT / 0-RTT接続）

従来の HTTPS 通信を開始するには、TCP の接続確立と TLS の暗号化ハンドシェイクを別々に行う必要がありました。

1. TCP 3ウェイハンドシェイク: 1 往復（1-RTT）
2. TLS 1.3 ハンドシェイク: 1 往復（1-RTT ※TLS 1.2 のフルハンドシェイクなら 2-RTT）

つまり、ブラウザが最初の HTTP リクエスト（GET 等）を送信できるまでに、最低でも 2-RTT（2 往復） の待機時間（遅延）が発生していました。地球の裏側のサーバーと通信する場合、RTT が 150ms だとすると、最初のデータを送るだけで 300ms 以上待たされる計算になります。

QUIC では、トランスポート層のパラメータ交換と TLS 1.3 の暗号化ネゴシエーションが統合 されています。そのため、パケットロスなどが発生しない通常の環境では、初回接続でも 1-RTT（1 往復） で暗号化通信を開始できます。

なお、QUIC の Initial パケットは暗号化されていますが、その鍵は通信相手以外でも導出できるため、完全な機密性はありません。機密性が確保されるのは、TLS ハンドシェイクによって確立された鍵を利用する通信です。

さらに、過去に接続したことがあり、TLS 1.3 のセッション再開に利用できるチケット（PSK：事前共有鍵）を保持している場合、サーバー側が早期データの受け入れに対応していれば、接続要求の最初のパケットから HTTP リクエストを送信する 0-RTT（Zero Round-Trip Time） 接続も利用できます。

ただし、0-RTT には注意点もあります。0-RTT で送信されたデータは、攻撃者によって再送される リプレイ攻撃（Replay Attack） のリスクがあります。そのため、決済やデータ削除など、重複実行によって問題が発生する可能性のある処理には、適切なリプレイ対策が必要です。0-RTT は、リプレイされても問題が生じないリクエストに限定して利用することが重要です。

課題3：IPアドレス変更時の通信切断（コネクションマイグレーション）

従来の TCP 通信では、コネクションを以下の 4つの要素の組み合わせ（4-tuple） で識別していました。

• 送信元 IPIP [アイピー]Internet Protocol。インターネット通信の基本プロトコル アドレス
• 送信元ポート番号
• 宛先 IP アドレス
• 宛先ポート番号

スマートフォンを持ち歩いて外出する際、自宅の Wi-Fi から携帯キャリアの 4G/5G 回線に切り替わると、スマートフォンの 送信元 IP アドレス が強制的に変わります。IP アドレスが変わると従来の TCP コネクションは破綻するため、接続は切断され、最初からハンドシェイクをやり直す必要がありました（動画再生が止まったり、ダウンロードが失敗する原因）。

コネクションID（CID）による解決

QUIC は、IP アドレスやポート番号だけでなく、パケットヘッダーに含まれる コネクションID（Connection ID: CID） を利用して通信セッションを識別します。そのため、通信経路が変わって IP アドレスやポート番号が変更されても、同じコネクションとして通信を継続できる設計になっています。

※図中の CID は説明用の値です。実際の QUIC では送信側が任意の値を自由に選ぶのではなく、通信相手からあらかじめ払い出された CID を使用します。意図的な経路変更時には新しい CID へ切り替えることが推奨されており、これにより第三者が異なる経路間の通信を関連付けにくくなります。

ただし、新しいネットワーク経路で通信を継続するには、Path Validation（経路検証） などの処理が必要です。また、サーバー側の設定やネットワーク環境によってはマイグレーションできない場合もあります。したがって、IP アドレスが変更されても必ず通信が維持されるわけではありません。この機能を コネクションマイグレーション（Connection Migration） と呼びます。

HTTP/1.1・HTTP/2・HTTP/3の比較まとめ

それぞれのバージョンの特徴と技術仕様を整理した比較表です。

ブラウザはどうやってHTTP/3と通信するのか？（Alt-Svcの仕組み）

ここで疑問が生じます。「ブラウザが特定の URLURL [ユーアールエル]Uniform Resource Locator。Webページのアドレス にアクセスする際、そのサーバーが HTTP/3 に対応しているかどうかを事前にどうやって知るのか？」という点です。

UDP パケットはネットワーク環境によってブロックされている可能性があるため、ブラウザがいきなり UDP ポート 443 へ通信を試みるのはリスクがあります。

そこで使われるのが Altalt [オルト / アルト]alternateの略。画像が表示されない場合の代替テキストを指定する属性-Svc（Alternative Services: 代替サービス） という仕組みです。

サーバーは HTTP/2 などのレスポンスヘッダーに次のような記述を含めてブラウザに通知します。

1
Alt-Svc: h3=":443"; ma=86400

• h3=":443": ポート 443 で HTTP/3（QUIC）を提供していることを示します。
• ma=86400: Max-Age（有効期間）を秒単位で示します（86400 秒 = 24 時間）。

ブラウザはこの情報をキャッシュし、次回以降のアクセスでは優先的に QUIC（UDP）での接続を試みます。UDP 通信がブロックされて QUIC 接続に失敗した場合、ブラウザは通常、HTTP/2 や HTTP/1.1 などの TCP ベースの HTTP へフォールバックします。ただし、接続の再試行に伴う遅延が発生する場合があり、必ずしもユーザーが遅延を感じないとは限りません。

curlコマンドでHTTP/3の対応を確認する方法

HTTP/3 に対応したビルドの curl コマンドを使用すると、コマンドラインから HTTP/3 の疎通確認が行えます。なお、--http3 は HTTP/3 接続に失敗した場合に HTTP/2 や HTTP/1.1 へフォールバックする仕様のため、HTTP/3 のみで接続を確認したい場合は --http3-only オプションを使用します（--http3-only は curl 7.88.0 以降で利用可能です）。

1
# HTTP/3 のみを使用して通信をテスト
2
curl --http3-only -I https://cloudflare.com/

実行例（HTTP/3 対応サーバーからのレスポンス）:

1
HTTP/3 200
2
date: Fri, 13 Nov 2026 12:00:00 GMT
3
content-type: text/html; charset=utf-8
4
server: cloudflare
5
alt-svc: h3=":443"; ma=86400

ステータス行が HTTP/3 200 と表示され、正常に QUIC プロトコル経由で通信が行われたことが確認できます。使用している curl が HTTP/3 に対応しているか確認するには、次のコマンドで出力に HTTP3 が含まれているかを確認してください。

1
curl -V

実務で押さえておくべき注意点とデメリット

HTTP/3 は非常に優れたプロトコルですが、実務導入や運用にあたっては注意すべき点もあります。

1. 企業のファイアウォールによるUDP遮断

一部の企業ネットワークや学校などの閉域網では、セキュリティ上の理由から UDP 443 番ポート（または UDP 通信全般）を一律遮断しているケースがあります。

前述のとおり、ブラウザは UDP が遮断されても HTTP/2 や HTTP/1.1 にフォールバックしますが、フォールバックの検知にわずかなタイムラグが発生し、初回表示が体感で一瞬遅く感じられる場合があります。

2. サーバー側のCPU負荷の増大

TCP のパケット処理やチェックサム計算の多くは、近年の NIC（ネットワークカード）にハードウェアレベルでオフロード（処理軽減）される仕組みが整っています。

一方、QUIC はユーザー空間でパケットの組み立てや暗号化・復号、パケット番号の管理などを行う実装が多く、従来の TCP と比べて CPUCPU [シーピーユー]Central Processing Unit。コンピュータの頭脳となる中央演算処理装置 負荷が高くなる場合 があります。ただし、実際の負荷は QUIC ライブラリの実装や NIC のオフロード機能（UDP の GRO/GSO など）、通信環境などによって異なります。大規模なトラフィックを処理するサーバーでは、CPU 使用率やスループットを実測して評価することが重要です。

まとめ：HTTP/3がもたらす次世代Web通信

HTTP/3 と QUIC の登場は、インターネット黎明期から続いてきた「Web は TCP 上で動くもの」という常識を塗り替える大きな技術革新です。

本記事の重要ポイントを振り返りましょう。

• プロトコルの組み合わせ: 従来の「TCP + TLS + HTTP/2」から、「UDP + QUIC（TLS 1.3 統合） + HTTP/3」へと刷新された。
• UDP採用の理由: QUIC の制御情報を暗号化しつつ既存のネットワーク上で展開しやすくし、一般的な実装ではユーザー空間で迅速に機能改善を進めるため。
• TCP層のHoLブロッキング解消: QUIC がストリームを独立して管理するため、あるストリームでパケットロスが発生しても別ストリームの受信データを処理できる（同一ストリーム内の順序制御やコネクション全体の輻輳制御は残る）。
• 低遅延ハンドシェイク: トランスポート層の接続確立と TLS 1.3 の暗号化ネゴシエーションを統合し、通常時は 1-RTT（再接続時はリプレイ攻撃に注意した上で 0-RTT 早期データ送信も可能）で通信を開始できる。
• コネクションマイグレーション: コネクションID（CID）により、経路検証（Path Validation）やサーバー側の対応などの条件を満たせば、IP アドレス変更時も同じ接続を継続できる。
• 段階的な移行: Alt-Svc ヘッダーにより HTTP/3 対応を通知でき、QUIC 接続に失敗した場合も TCP ベースの HTTP へフォールバックできる。

主要な CDNCDN [シーディーエヌ]Content Delivery Network。コンテンツを高速配信するネットワーク（Cloudflare や AWSAWS [エーダブリュエス]Amazon Web Services。Amazonのクラウドサービス CloudFront など）やモダンブラウザでは HTTP/3 のサポートが進んでおり、利用できる環境が広がっています。ただし、実際に HTTP/3 で通信できるかどうかは、サーバー側の設定やネットワーク環境にも依存します。仕組みとメリット・注意点を正しく理解し、Web システムのパフォーマンス向上やネットワークトラブルシューティングに役立ててください。

おすすめ この記事に関連する技術本

世界一流エンジニアの思考法

Amazon 🔴 楽天

この記事を書いた人

Z (ITナレッジライフ)

現役のITエンジニア。Linux、プログラミング、IT用語など、日々の業務で得た「痒いところに手が届く」技術情報を発信しています。

プロフィールと編集ポリシーを見る →