2026.08.06 プロトコル

QUIC（通信プロトコル）とは？HTTP/3を支える仕組みとTCPとの違いを実装視点で解説

QUIC（通信プロトコル）とは？HTTP/3を支える仕組みとTCPとの違いを実装視点で解説

QUICは、UDPの上にストリームの多重化と暗号化と再送制御をまとめて載せたトランスポートプロトコルです。TCPとTLSが分担していた仕事を1つの層へ畳み込んだ結果、接続確立の往復が減り、パケットが1つ落ちても他のストリームが止まらなくなりました。その上でHTTPをやりとりする仕様がHTTP/3です。この記事では、RFC 9000系とRFC 9114の役割分担、HTTP/2から変わる範囲、TCPと並べて変わる点、Connection IDで接続が切れなくなる原理、導入時に詰まるUDP遮断・CPU使用率・可観測性の3点を実装視点で整理します。見送るべき条件も代案とセットで示します。

まとめ｜QUICを採用する条件とTCPのままで足りる境界

結論から置きます。QUICが効くのは、回線品質が安定しない相手へ、公開インターネット越しに配信している場合です。モバイル回線の利用者が多い、往復遅延が大きく損失も出る。この条件なら、接続確立の往復が1つ減る効果と、損失が全ストリームを止めない効果が体感差になります。

逆に、データセンター内やVPN内で完結するサーバ間通信なら、TCPのままで構いません。遅延も損失もほぼ無い経路では、QUICが解いている問題がそもそも起きていないためです。そこへ持ち込むと、CPU使用率の増加とパケットキャプチャで中身が読めなくなる不便だけが残ります。

導入の労力にも境界があります。自前で終端するとUDPバッファやGSOの設定、証明書とライブラリの制約が一式ついてくる。まずはCDNやロードバランサ側でHTTP/3を有効化して効果を測り、差が出てから自前終端へ踏み込む順序が現実的です。アプリケーション側のコードは、HTTPのメソッドやステータスコードの意味論がHTTP/1.1から変わらないため、原則そのまま動きます。書き換えが要るのは通信基盤側だけだと理解しておくと、見積もりの粒度を誤りません。

QUICの定義とHTTP/3の関係｜UDPの上に載る新しいトランスポート層

名前だけ聞くと「速いUDP」に見えますが、実態はTCPの仕事を作り直したものです。

QUICが解こうとした課題とプロトコルスタック上の位置づけと範囲

QUICは、UDPを土台にして、ストリームの多重化・信頼性のある配送・輻輳制御・暗号化までを1つの層で提供するトランスポートプロトコルです。仕様はRFC 9000「QUIC: A UDP-Based Multiplexed and Secure Transport」（2021年5月・Proposed Standard）。同RFCはQUICを名称であって略語ではないと明記しています。Googleの初期実装がQuick UDP Internet Connectionsを語源としていた経緯から略語として説明されることもありますが、IETF版は名称です。仕様書そのものを読む手順に不安があるなら、通信規約の3要素とRFCの読み方を先に押さえると、以降のRFC番号が地図として機能します。

QUICが置き換えるのはTCPとTLSの2つ。TCP/IPの4階層モデルにおけるトランスポート層の役割で言えば、従来はここにTCPが座り、その上にTLSを重ねてHTTPを載せていました。QUICはUDPという土台を借り、その上に自前で信頼性と暗号化を実装します。7階層で考える場合の対応はOSI参照モデルの各層と役割と読み替えてください。UDPを選んだ理由は性能ではなく、経路上の機器に手を入れずに新しいトランスポートを配備するための回避策です。

QUICとHTTP/3は別物｜RFC 9000系とRFC 9114の役割分担

混同されやすい点をここで切り分けます。QUICはトランスポート層のプロトコル、HTTP/3はその上でHTTPをやりとりするための仕様であり、別のRFCです。

  • RFC 9000：QUICのトランスポート本体（ストリーム、パケット、フレーム、接続管理）
  • RFC 9001：TLSとの統合。QUICの暗号化はTLS 1.3のハンドシェイクを内側に取り込む形で規定される
  • RFC 9002：損失検出と輻輳制御。再送判定やペーシングの既定動作を定める
  • RFC 9114：HTTP/3。HTTPのセマンティクスをQUICのストリームへ写像する（2022年6月）
  • RFC 9204：QPACK。HTTP/3のヘッダフィールド圧縮を定める（2022年6月）
  • RFC 9369：QUIC v2（2023年5月）。中身はv1とほぼ同一で、経路上の機器の固着を防ぐための版

実務上の意味は、QUICの用途がHTTPに限らないことです。DNS over QUICやSMB over QUIC、独自プロトコルを載せる設計も成立します。DNSをHTTPSに載せる方式との違いはDNS over HTTPSとDoQの比較で整理しました。「HTTP/3対応」と書かれた製品を選ぶときは、QUICの終端まで含むのか、上流へHTTP/2で流し直すだけなのかを確認してください。既知のバージョン番号だけを通すミドルボックスは、将来の版で通信を落とす側に回ります。

HTTP/3とはHTTPの第3版｜h3の識別とHTTP/2から変わる範囲

ここからは、QUICの上に載る側を単独で見ます。「HTTP/3にすると何が変わるのか」への答えは、意外なほど限定的です。

HTTP/3の定義とALPNのh3｜RFC 9114が定める範囲の確認

HTTP/3は、HTTPのやりとりをQUICのストリーム上で運ぶための仕様です。RFC 9114「HTTP/3」（2022年6月・Standards Track）が規定しており、接続確立時のTLSハンドシェイクでALPNトークンh3を選ぶことでHTTP/3だと識別されます。h2ならHTTP/2、http/1.1ならHTTP/1.1で、この1つのトークンが版の決定そのものです。

中身の構造も押さえておきます。HTTP/3では、リクエストごとに1本の双方向ストリームを使い、その上をフレームが流れます。RFC 9114が定めるフレーム種別は、DATA（type=0x00）、HEADERS（0x01）、CANCEL_PUSH（0x03）、SETTINGS（0x04）、PUSH_PROMISE（0x05）、GOAWAY（0x06）、MAX_PUSH_ID（0x07）。HTTP/2に対応するものが多く、枠組みとしては連続しています。

逆に変わらない範囲のほうが実務では効きます。メソッド、ステータスコード、ヘッダフィールドの意味論はHTTPのセマンティクスとして版から独立しており、HTTP/3でも同じ。つまりアプリケーションのコードは書き換え不要で、変更は通信基盤の層に閉じます。「HTTP/3対応」を機能改修として見積もると、実態と桁がずれます。

ヘッダ圧縮がHPACKからQPACKへ変わる理由と設定の要点

HTTP/2からの実質的な変更点の1つが、ヘッダ圧縮の方式です。HTTP/2のHPACKは、過去に送ったヘッダを共有の動的テーブルへ積み、2回目以降は索引番号だけを送る仕組みでした。これはTCPが全体の順序を保証していたから成り立ちます。

QUICはストリームごとに独立しているため、ストリーム間の到着順が保証されません。動的テーブルの更新が届く前に索引参照だけが到着する状況が起こり得ます。RFC 9204「QPACK: Field Compression for HTTP/3」（2022年6月・Standards Track）は、この順序の問題を前提に設計し直した仕様です。エンコーダストリーム（type=0x02）とデコーダストリーム（0x03）という専用の単方向ストリームでテーブルの状態を同期し、Required Insert Countによって「どこまで届いていれば解釈できるか」を明示します。

設定として現れるのは、動的テーブルの容量と、テーブル待ちでブロックしてよいストリーム数の2つです。テーブルを大きく使うほど圧縮率は上がりますが、未到着のエントリを参照する確率も上がり、ヘッダ解釈待ちが発生します。ヘッダが小さいAPI主体のサービスなら、動的テーブルを絞って待ちを避ける側へ倒すほうが読みやすい挙動になります。

優先度制御がRFC 9218へ分離した経緯とサーバプッシュの扱い

もう1つの変更点が、どのリクエストを先に返すかの指定方法です。HTTP/2はストリーム間の依存関係と重みをツリーで表現する方式を持っていましたが、RFC 9218「Extensible Prioritization Scheme for HTTP」（2022年6月・Standards Track）は、その方式が複雑で展開が限られ相互運用性の問題を抱えたこと、より単純な方式でも実運用で同等の性能特性に達すると実験で示されたことを理由に挙げ、HTTP/2の改訂で非推奨になった経緯を記しています。

後継は、パラメータを2つだけ持つ単純な形です。urgency（u）が優先度で既定値は3、incremental（i）が部分的に届いた分から処理してよいかの指示で既定値はfalse。これらをPriorityヘッダフィールドやPRIORITY_UPDATEフレームで伝えます。HTTPの版に依存しない設計のため、HTTP/2でもHTTP/3でも同じ考え方で扱えます。

サーバプッシュは、RFC 9114にPUSH_PROMISEフレームとして規定が残っています。ただしHTTP/2の時点でブラウザ側の扱いが見直された経緯があり、実際に効く前提で設計するのは避けたほうが安全です。先読みさせたいリソースがあるなら、rel=preloadのようなヒントを使う設計に寄せ、プッシュの有無に性能が依存しない形にしておいてください。

HTTP/3の対応状況を実測する手順とcurlでの確認の順序

対応状況は数字で押さえます。ブラウザ側はCan I useのHTTP/3の集計で2026年9月時点のグローバル対応率が94.53%、既定で有効になった版はChromeとEdgeが87、Firefoxが88、Safariが16.0です。サーバ側はW3Techsの集計で2026年9月時点の提供率が40.8%。ブラウザ相手なら対向の心配はほぼ無く、判断材料は自社側の運用コストへ移っています。

自分の環境で確かめるならcurlが手早い方法です。curl公式のHTTP/3ドキュメントによれば、--http3はHTTP/3を試してHTTP/2やHTTP/1.1へ戻る動き、--http3-onlyはHTTP/3だけを使う動きです。ビルド条件もあり、ngtcp2とnghttp3を組み合わせる構成は実験的扱いを外れていて、TLS側にOpenSSL 3.5.0以降・GnuTLS・wolfSSLのいずれかが要ります。quiche構成は実験的のままです。

# HTTP/3だけで接続し、実際に使われた版を表示する
curl --http3-only -s -o /dev/null \
  -w "version=%{http_version} code=%{http_code}\n" \
  https://www.example.com/

# 対応版をcurl自身が持っているかの確認
curl --version | grep -i "HTTP3\|ngtcp2\|quiche"

手順は上から順です。まずcurl --versionでHTTP3の記載を確かめ、次に--http3-onlyで到達するかを見る。ここで落ちるなら経路のUDPが塞がれている可能性が高く、次節の切り分けへ進みます。表示されたversionが3なら、ALPNでh3が選ばれた状態です。

TCPとの違い｜ハンドシェイクの往復数とヘッドオブラインブロッキング

QUICの効果はほぼ2点に集約されます。接続が早く立ち上がることと、損失が全体を止めないことです。

1-RTTで暗号化まで終わる接続確立と0-RTTを使ってよい条件

TCPでHTTPSを話す場合、まずTCPの3ウェイハンドシェイクで1往復、続いてTLS 1.3のハンドシェイクでもう1往復かかります。データを送り始められるのは2往復後です。QUICはこの2つを1つの手順へ統合しており、初回接続でも1往復で暗号化されたデータの送信に入れます。TLS 1.3のハンドシェイクとバージョン選定の詳細はTCP側と共通ですが、QUICではトランスポートの内側に組み込まれている点が違います。

再接続時にはさらに短縮する0-RTTがあります。以前の接続で得た情報を使い、往復ゼロで最初のデータを載せる方式です。ただし0-RTTのデータはリプレイ攻撃への保護が弱く、RFC 9001も適用範囲を限定するよう求めています。判断は単純で、副作用のない冪等な要求だけに限ること。参照系のGETは許容できますが、決済や更新系を0-RTTで送る設計は避けてください。nginxで0-RTTを有効化するにはOpenSSL 3.5.1以上かBoringSSL系が要る点も、実装前の確認事項です。

ストリーム単位で独立する再送処理とHoLブロッキングが消える理由

HTTP/2はTCPの1本のコネクション上で複数のストリームを多重化しますが、TCPから見ればすべては1本の連続したバイト列です。途中のパケットが1つ落ちると、そのパケットが再送されて届くまで、後続のデータは受信バッファに溜まったままアプリケーションへ渡せません。無関係なストリームまで巻き添えで止まる。これがヘッドオブラインブロッキングです。

QUICはストリームをトランスポート層の概念として持っています。あるストリームのパケットが失われても、他のストリームのデータは順序が揃い次第アプリケーションへ渡されます。画像1枚の再送を待つ間もCSSやJavaScriptの配送が進む。損失率が数%出る経路ほど差が開き、損失がほぼ無い経路では差が出ません。効果の大小が回線品質に依存するのは、この原理から導かれます。

TCP+TLS 1.3とQUICを同じ観点で並べた場合の差の出方

観点 TCP + TLS 1.3 QUIC
接続確立 3ウェイ後にTLS 暗号込みで1往復
再送の単位 接続全体のバイト列 ストリームごと
暗号化の範囲 ペイロード中心 ヘッダも含め大半
経路の変更 4タプルで切れる IDで維持できる
実装の場所 OSカーネル 主にユーザ空間
輻輳制御の差替 OS設定に依存 アプリ側で選べる
ヘッダ圧縮 HPACK（HTTP/2） QPACK（HTTP/3）

表の輻輳制御の行は見落とされがちですが、影響は小さくありません。TCPの輻輳制御はカーネル設定で、サーバ全体に効きます。QUICはユーザ空間の実装なので、アプリごとに別のアルゴリズムを選べる。輻輳制御のアルゴリズムが混雑をどう捌くかを理解していれば、この自由度は調整の余地として使えます。

コネクションIDと接続移行｜IPが変わっても通信が切れない仕組み

QUICで実務上いちばん効くのに、解説記事で軽く流されがちなのがこの機能です。

Connection IDで経路に依存せず接続を識別し続ける仕組み

TCPの接続は、送信元IP・送信元ポート・宛先IP・宛先ポートの4つ組で識別されます。どれか1つでも変われば別の接続として扱われ、既存の接続は切れる。QUICは接続をConnection IDという識別子で管理し、この識別子はIPアドレスやポートから独立しています。パケットの送信元アドレスが変わっても、Connection IDが一致すれば同じ接続として処理が続きます。

Wi-Fiとモバイル回線の切り替えで接続が維持される範囲と限界

効果が出る典型が、ユーザーが建物を出てWi-Fiからモバイル回線へ切り替わる場面です。TCPなら接続が切れ、再接続とTLSハンドシェイクをやり直すことになる。QUICなら経路検証を挟んで同じ接続が継続し、ダウンロードもストリーミングも途切れません。長時間の転送や動画配信を持つサービスほど、体感に直結します。

限界も押さえておきます。移行できるのはクライアント側の経路が変わる場合で、サーバ側のアドレス変更は仕様上サポートされません。また、途中のNATやファイアウォールがUDPのマッピングを短いタイムアウトで破棄する環境では、無通信区間の後に到達しなくなることがある。キープアライブの間隔は明示的に設計してください。

マルチパス拡張はRFC発行前｜実務の通信設計で前提にできない現在地

Wi-Fiとモバイル回線を同時に束ねるマルチパス拡張は、draft-ietf-quic-multipathとして標準化が進んでいます。2026年9月22日に確認した時点では、2026年3月17日更新のdraft-21がRFC Editor Queueにあり、IESGの承認は済んでいるもののRFC番号はまだ付いていません。設計上は当てにしない前提を置いてください。現時点で使えるのは「1本の経路が別の経路へ移る」接続移行までです。

QUIC導入で詰まる箇所｜UDP遮断とCPU負荷と可観測性の低下

ここからが、用語解説には出てこない実装側の話です。トラブルの発生源はほぼこの3つ。

UDP 443が塞がれる環境とAlt-SvcやHTTPS RRでの発見と退避

QUICはUDPの443番を使いますが、企業ネットワークや一部のISPではUDPの外向き通信が制限されています。HTTP/3が使えない環境は現実に存在するため、TCP側のHTTP/2やHTTP/1.1へ確実に落ちる設計が前提になります。

発見の仕組みは2系統です。1つはAlt-Svcレスポンスヘッダで、最初の応答時に「このオリジンはh3も話せる」と広告し、クライアントが次回以降QUICを試す方式。もう1つはDNSのHTTPSリソースレコードで、RFC 9460（2023年11月・Proposed Standard）が定めるalpnパラメータにh3を含めておけば、最初の接続からHTTP/3を選べます。前者は初回がTCP経由、後者はDNS側の設定が要る違いです。なお2026年9月1日公開のFirefox 155はQUIC version 2の交渉に対応したため、前段で版を絞る設定が残っていないかはFirefox 155のQUIC version 2対応と確認ポイントで確かめられます。

# HTTPS RRにh3が入っているかをDNS側で確認する
dig +short HTTPS www.example.com

# Alt-Svcヘッダが返っているかをTCP側で確認する
curl -sI https://www.example.com/ | grep -i alt-svc

運用で確認すべきなのは、フォールバックが起きた事実がログに残るかどうか。QUICが到達せずTCPへ落ちた状態は、性能が出ないだけで機能は動くため、気づかないまま放置されがちです。アクセスログにプロトコル名を出力し、HTTP/3の比率を見る仕込みを最初に入れてください。

ユーザ空間実装で上がるCPU使用率とGSO/GROによる緩和の手順

TCPの処理はカーネルが担い、多くの部分がハードウェアオフロードの恩恵を受けます。QUICはユーザ空間で動くため、パケット単位の処理と暗号化がCPUに乗る。arXivの「QUIC on the Highway」をはじめとする測定でも、高速リンクではACK処理・送信処理・暗号化がボトルネックになり、システムの制約がCPU側へ移ると報告されています。

緩和策は概ね次の順で効きます。

  1. UDPの送受信バッファサイズを引き上げる（既定値のままだと取りこぼしが出る実装が多い）
  2. UDP GSOを有効にし、複数パケットを1回のシステムコールでまとめて送出する
  3. 受信側でGROを有効にし、小さなUDPパケットを結合してから上位へ渡す
  4. ACK送出の頻度を調整し、往復あたりの処理回数を減らす

nginxの場合、GSOに対応するquic_gsoディレクティブの既定値は公式ドキュメント上offです。既定のままでは2番目の緩和策が効いていないため、有効化してからCPU使用率を比べてください。GSOには副作用もあり、まとめて送る性質からトラフィックがバースト気味になります。Tailscaleの検証記事でも触れられているとおり、スループットは伸びる一方でバーストが混雑を悪化させる場面があるため、前後でスループットと再送率の両方を見てください。UDPソケットの生成とオプション設定の手順を押さえておくと、この層の調整は自分で追えます。

経路上で中身が見えなくなる代償とqlogで可視性を取り戻す手順

QUICはトランスポート層のヘッダまで含めて大半を暗号化します。TCPならtcpdumpでシーケンス番号やウィンドウサイズを追えましたが、QUICでは経路上のキャプチャからほぼ何も読めません。ロードバランサやIDSが接続状態を把握する前提で作られていると、その前提が崩れます。

代わりに使うのが、実装側が出力する構造化ログです。多くのQUIC実装はqlog形式でパケットの送受信・損失検出・輻輳ウィンドウの推移をJSONへ出力でき、可視化ツールへ読ませれば従来と同等以上の情報が得られます。損失検出と輻輳制御の既定動作はRFC 9002に定義されているため、ログの数値はそちらと突き合わせて読みます。Wiresharkで復号したい場合は、セッションキーをSSLKEYLOGFILEへ書き出して読み込ませる手順です。

設計時に決めておくのは、qlogを本番で常時出すかどうか。出力コストは無視できないため、既定は無効にして障害時だけ特定の接続に有効化できる作りが扱いやすい形になります。

QUICの有効化手順｜nginxでの設定とCDN側で終端する選択

実際に動かすまでの距離は、どこで終端するかによって大きく変わります。

nginx 1.25.0以降でquicリスナを立てる設定と確認の順序

nginxはバージョン1.25.0でngx_http_v3_moduleを追加しました。公式ドキュメントにはHTTP/3への対応が実験的である旨の記載が残っており、ビルド時に--with-http_v3_moduleの指定が要ります。既定のパッケージには含まれません。Known Issuesの項にWin32では構築できないと明記されています。

server {
    listen 443 quic reuseport;
    listen 443 ssl;
    http3 on;

    ssl_certificate     /etc/nginx/certs/server.crt;
    ssl_certificate_key /etc/nginx/certs/server.key;

    add_header Alt-Svc 'h3=":443"; ma=86400';
}

確認は順番に進めます。まずTCP側の443が従来どおり応答するかを確かめ、次にUDPの443が外部から届くかを試験する。そのうえで前節のcurl --http3-onlyで接続し、ネゴシエートされたプロトコルがh3かを見ます。TCP側とQUIC側で同じポート番号を使うのは、互換性のために公式ドキュメントも勧める構成です。

CDNやロードバランサ側で終端する選択と自前終端に踏み込む境界

ビルドと調整を抱えたくない場合、終端を前段へ寄せる選択があります。主要なCDNやクラウドのロードバランサはHTTP/3対応を設定項目として持っており、有効化はほぼスイッチ1つ。エッジまでがHTTP/3、そこからオリジンまでは従来どおりという構成になります。前段の機器そのものの選び分けはロードバランサーの種類と振り分け方式を先に見ておくと、どこで終端すべきかの判断が早まります。

この構成でも効果の大半は得られます。QUICが効くのは遅延と損失のあるラストマイルで、その区間はまさにユーザーとエッジの間だからです。CDNの配置とキャッシュ制御の考え方を整理したうえで有効化すれば、オリジン側には手を入れずに済みます。

自前終端へ踏み込む理由になるのは、CDNを経由できない要件、独自プロトコルをQUICの上に載せる要件、輻輳制御アルゴリズムまで自分で選びたい要件の3つ。当てはまらないなら前段へ寄せたままで足ります。

効果を実測する指標の決め方とネットワーク条件別の比較の組み立て

有効化しただけで満足すると、後で「速くなったのか」に答えられません。測る対象を先に決めてください。見るべきは平均値でなく分布です。

  • 接続確立からの初回応答までの時間（中央値と95パーセンタイル値）
  • ページやAPI応答の完了時間の分布
  • プロトコル別のリクエスト比率（h3が実際に何%使われているか）
  • 再送率とフォールバック発生率

指標そのものの定義から詰めたい場合は、TTFBやFCPなどWebパフォーマンス指標の使い分けを先に揃えると、前後比較の軸がぶれません。条件分けも要ります。損失0%・遅延10ミリ秒の社内環境で比較しても差は出ません。遅延100ミリ秒・損失1%といったモバイル相当の条件を意図的に作って比較すると、QUICが効く領域がはっきり見えます。実測なしに「HTTP/3にしたから速い」と説明すると、後から数字を求められて答えに詰まります。

QUICを採用する現場と見送る現場｜受託開発での判断基準と代案

ここまでを、案件で使える判断へ落とします。

モバイルや高遅延・損失のある経路でQUICの効果が出やすい条件

採用を勧められるのは、次の条件が重なる場合です。エンドユーザーが公開インターネット越しに接続する。モバイル回線や海外からのアクセスが一定割合ある。1画面あたりのリクエスト数が多いか、長時間の転送がある。

この条件下では、往復の短縮とストリーム単位の再送、接続移行の3つが同時に効きます。特に接続移行は他の手段で代替できず、移動中の利用が多いサービスなら選ぶ理由として単独で成立する。W3Techsの2026年9月時点の集計では全ウェブサイトの40.8%がHTTP/3を提供しており、対向が追いつかない心配はブラウザ相手なら概ね解消しました。

社内LANやUDP制限のある環境でQUICを見送るべき条件と代案

見送るべき条件も明確です。通信がデータセンター内やVPN内で完結する。利用者のネットワークでUDPが制限されている。パケットキャプチャによる調査を運用手順に組み込んでいる。監視機器やWAFがQUICを解析できない。

これらに当てはまるなら、TCPのままHTTP/2を使うか、TLS 1.3とセッション再開の設定を見直すほうが投資対効果は上です。見直しの具体はTLS 1.3の有効化手順と0-RTTを使ってよい条件にまとめています。QUICが解くのは遅延と損失に由来する問題で、それが起きていない経路には改善の余地がありません。「新しいから」で持ち込むと、CPUの増加と調査手段の喪失だけが残ります。

API連携でHTTP/3を前提にしてよいかを見極める判断の順序

サーバ間のAPI連携でHTTP/3を前提にするかは、ブラウザ向けと分けて判断してください。サーバ間通信は経路が安定していることが多くQUICの利点が出にくい一方、対向のクライアントライブラリが未対応の場合も残ります。gRPCなど既存スタックのHTTP/3対応も、実装ごとに成熟度の差があります。

双方向のリアルタイム通信が要件なら、比較対象はQUIC単体ではありません。WebSocketのハンドシェイクと運用上の判断を先に押さえ、HTTP/3の上に載るWebTransportまで含めて並べる順序になります。サーバから一方向に流すだけで足りるのかどうかはSSEとWebSocketの違いと使い分けで切り分けられます。既存資産と対向の対応状況からWebSocketを選ぶ判断も、現時点では十分に合理的です。

方式の選定が案件の要件と絡んで決めきれない場合は、通信方式だけを単体で比較しても答えが出ません。API開発・システム連携の設計を相談するほうが、対向システムの制約や運用体制まで含めた形で先に片付きます。プロトコルの選択は、連携全体の設計が決まったあとに従うものです。

よくある質問

QUICとHTTP/3の検討でよく挙がる質問を、実装と運用の観点から整理しました。

QUICとHTTP/3は同じものですか？

別物です。QUICはUDPの上に載るトランスポート層のプロトコルで、仕様はRFC 9000系。HTTP/3はそのQUIC上でHTTPをやりとりするアプリケーション層の仕様で、RFC 9114（2022年6月）が定めています。QUICはHTTP専用ではなく、DNS over QUICのように他のプロトコルを載せる使い方も可能です。ブラウザからQUICのストリームとデータグラムを直接扱う方式は、WebTransportの通信モデルと実装にまとめています。

HTTP/3にするとHTTP/2から何が変わりますか？

変わるのは下回りで、アプリケーション側の書き方は変わりません。メソッド・ステータスコード・ヘッダの意味論は版から独立しているためです。実質的な差は3つ。土台がTCPからQUICへ替わってHoLブロッキングが消えること、ヘッダ圧縮がHPACKからQPACK（RFC 9204）へ替わること、優先度の指定がRFC 9218の単純な方式へ移ったことです。改修範囲は通信基盤の層に閉じると考えて見積もってください。

QUICを有効にすると必ず速くなりますか？

なりません。効果が出るのは遅延が大きい経路と損失のある経路で、損失がほぼ無い社内ネットワークやデータセンター内では差がほとんど出ません。むしろユーザ空間実装によるCPU使用率の増加が目立つ場合もある。前後で95パーセンタイル値と再送率を条件別に測って判断してください。

UDPを使うのにデータが欠けないのはなぜですか？

信頼性のある配送をQUIC自身が実装しているためです。UDPは土台として使うだけで、パケット番号の付与、損失検出、再送、順序の復元はQUICの層が担います。RFC 9002が損失検出と輻輳制御の既定動作を定めており、TCPが提供していた保証はQUIC内部で再構築されています。

0-RTTは使ってよいのですか？

用途を限定すれば使えます。0-RTTのデータはリプレイ攻撃への保護が弱いため、副作用のない冪等な要求だけに絞ってください。参照系のGETは許容範囲ですが、決済や登録などの更新系を0-RTTで送る設計は避けるべきです。サーバ側の実装でも、0-RTTで受け付けるメソッドやパスを制限できるかを確認しておくと安全に運用できます。

既存システムをQUIC対応にする際の作業量はどれくらいですか？

終端をどこに置くかで桁が変わります。CDNやロードバランサ側で有効化するだけなら設定変更と検証で数日規模。自前のnginxで終端するなら、モジュール付きのビルド、UDPバッファやGSOの調整、監視とログの見直しが加わり、検証を含めて数週間が現実的です。まず前段で有効化して効果を測る順序を勧めます。

関連記事

この記事に関連するサービス

資料請求

RELATED POSTS 関連記事

一覧へ戻る