NET // communication networks
LESSON 33 / 発展編

QUIC と HTTP/3 ─ UDP 上に再設計された信頼性トランスポート

HTTP/2 はアプリ層の HOL ブロッキングを解消したが、TCP の順序保証に起因する トランスポート層 HOL、TCP+TLS の 段重ねハンドシェイクの遅さ、ミドルボックスによる進化の停滞、という3つの限界が残った。QUIC(RFC 9000, 2021)はこれらを根本から再設計し、UDP 上に「信頼性・暗号化・接続確立・多重化・経路移動耐性」を一体で実装した新しいトランスポートである。本講では Google gQUIC(2012〜)から IETF QUIC への発展、ストリームごとの独立順序保証、コネクション ID、TLS 1.3 内蔵による 1-RTT/0-RTT 確立、QPACK、HTTP/3(RFC 9114, 2022)の設計と運用課題までを論文・標準を参照しながら整理する。

学習目標

本講を修めると、QUIC/HTTP3 を「速い HTTP」ではなく トランスポート層の根本的再設計 として理解し、研究レベルの議論ができるようになる。

本講は 標準 TCP(信頼性・フロー・輻輳)、標準 UDP、標準 HTTP/1.1 と HTTP/2 詳細、標準 TLS と PKI を前提とする。標準 で「HTTP/2 でも TCP 層 HOL は残る」と動機を提示した続きを、本講で根本から扱う。輻輳制御の最新動向は 発展 BBR/CUBIC（準備中）、暗号化 DNS は 発展 DoH/DoT（準備中） で扱う。

このレッスンの目次

01 動機と問題設定 QUIC を「ただ速い HTTP」と紹介するのは本質を取り逃がす。QUIC は 30… 02 gQUIC から IETF QUIC へ QUIC は 研究室発の理論 ではなく、Google が自社サービスのために実装し、… 03 QUIC の設計 QUIC を機能で分解すると、UDP の上に (1) 信頼性配送 (2) 暗号化 (… 04 ハンドシェイク比較 最初の HTTP リクエストが流れるまでに何 RTT かかるかを、TCP+TLS 1… 05 ストリームと HOL QUIC のストリームは「バイト単位の独立した順序保証チャネル」として設計されている… 06 コネクション ID と移動耐性 TCP コネクションは (送信元 IP, 送信元 Port, 宛先 IP, 宛先 P… 07 HTTP/3 と QPACK HTTP/3(RFC 9114, 2022)は HTTP セマンティクス(RFC 9… 08 性能と採用状況 QUIC/HTTP3 は理論的にはレイテンシ・HOL の両面で TCP+HTTP/2… 09 課題と関連研究 QUIC は単なる「速い HTTP の運び役」ではなく、 新しい多用途トランスポート… 10 まとめ 本講の重要語句を整理 11 確認問題 理解度を問題でチェック

動機 ─ TCP+TLS は何が遅く、何を進化させられないのか

QUIC を「ただ速い HTTP」と紹介するのは本質を取り逃がす。QUIC は 30 年もののトランスポート層を作り直す 大手術である。なぜそれが必要だったのかを、3つの限界で整理する。
POINT QUIC を生んだ3つの限界:
1. 段重ねハンドシェイクのレイテンシ:TCP 3WHS(1 RTT) + TLS 1.2(2 RTT) または TLS 1.3(1 RTT) で、最初のバイトが流れるまで 2〜3 RTT
2. TCP 層 HOL ブロッキング:1本の TCP に複数論理ストリームを多重化しても、1パケット欠落で全ストリームが配送停止
3. Protocol ossification(プロトコル硬直化):NAT/FW/IDS など中間機器が TCP ヘッダの一部しか想定せず、新フラグ・新オプションが通らない/破損する。標準を変えても現場で使えない

段重ねハンドシェイクを RTT で分解する

HTTPS で「最初の HTTP リクエスト」が送れるまでに必要な RTT 数は次の通り(クライアントから見た所要往復):

RTT が 100 ms の地球規模通信では、3 RTT と 1 RTT の差は 200 ms。これはユーザ体感に直結する大きな数字であり、特にモバイルや国際間トラヒックでは大きい。

Protocol ossification ─ なぜ TCP は変えられないのか

Honda et al. "Is it Still Possible to Extend TCP?"(IMC 2011)は、世界中の経路を実測して衝撃的な結論を出した:TCP の新オプションを使うと多くの中間ノードでパケットが破棄・改変される。NAT・ファイアウォール・LB・IDS 等のミドルボックスが TCP ヘッダの一部しか想定せず、未知のフィールドを「異常」とみなしてしまう。これがプロトコル硬直化(ossification)である。

結果として、TCP Fast Open・MPTCP・新しい輻輳制御フィードバック等の拡張は、標準化されても 現場で安全に使えない。QUIC の設計者はこの問題を逆手に取った:UDP の上にすべての制御情報を暗号化して載せ、ミドルボックスから見えなくする。見えないものは触れないので、ossification を避けて将来も進化できる。

Q. 「HTTP/2 で TCP 層 HOL が残る」とはどういうことか? なぜ HTTP/2 では解けず、トランスポート層を作り直す必要があったのか?

考えてみよう: なぜ「TCP を改造する」のではなく「UDP の上に新トランスポートを作る」という選択になったのか? ヒント:OS カーネルの更新サイクル、ミドルボックスの ossification、デプロイメント可能性の3点を考えよ。

歴史 ─ Google gQUIC から IETF QUIC へ

QUIC は 研究室発の理論 ではなく、Google が自社サービスのために実装し、地球規模のトラヒックで検証してから IETF に持ち込んだ "deploy-first" な標準化 の代表例である。

年表

2012 Google が gQUIC 試験投入 2015 Chrome ↔ Google 本番展開 2016 IETF QUIC WG 設立 2018 draft 進行 interop 試験 2021 RFC 9000 QUIC v1 発行 2022 RFC 9114 HTTP/3 発行 QUIC/HTTP/3 の標準化年表 橙=Google 独自(gQUIC) 青=IETF 標準化中 緑=RFC 発行

図の見方:Google が 2012 年から自社で大規模に運用しながら磨き上げた gQUIC を、2016 年以降 IETF が 互換性を捨ててクリーンに作り直した ものが IETF QUIC。両者は名前は同じでもワイヤフォーマットや暗号スキームが異なり、別物として扱う。

gQUIC と IETF QUIC の関係

Google が 2012 年に展開した最初の QUIC(以下 gQUIC)は、Chrome と Google サーバ間のみで動く独自プロトコルとして実証された。Langley らの SIGCOMM 2017 論文 "The QUIC Transport Protocol: Design and Internet-Scale Deployment" によれば、Google 検索・YouTube のトラヒックの大部分が既に gQUIC に乗り、レイテンシ短縮と再バッファリング率減少の効果が地球規模で実証されていた。

IETF はこの実績を出発点としつつ、より一般的なトランスポートを設計するため QUIC WG(2016 年〜)を立ち上げた。鍵交換を独自方式から TLS 1.3(RFC 8446) に統一し、ヘッダフォーマットを刷新し、HTTP 以外のアプリケーション(WebTransport など)も乗せられるよう汎用化した。RFC 9000(QUIC v1, 2021 年 5 月)、RFC 9001(TLS 統合)、RFC 9002(損失検出と輻輳制御)で本体仕様が完成し、HTTP マッピングは RFC 9114(HTTP/3, 2022 年 6 月)で別途標準化された。

もっと詳しく:gQUIC と IETF QUIC の差分(代表例)

本講で「QUIC」と書くときは、特記なき限り IETF QUIC v1(RFC 9000)を指す。

QUIC の設計 ─ UDP 上に5つの機能を統合する

QUIC を機能で分解すると、UDP の上に (1) 信頼性配送 (2) 暗号化 (3) 接続確立 (4) ストリーム多重化 (5) 経路移動耐性 の5つを 1つのプロトコルとして統合 したものになる。これらは従来 TCP・TLS・HTTP/2 stream・MPTCP/Mobile IP がバラバラに担っていた責務である。

レイヤ構造の比較

プロトコルスタックの再構成 従来:HTTPS over TCP HTTP/2(RFC 9113) TLS 1.3(RFC 8446) TCP(RFC 9293) IP 3つの独立レイヤを段重ね それぞれが独立にハンドシェイク → HTTP/3 over QUIC HTTP/3(RFC 9114) + QPACK QUIC(RFC 9000) 信頼性・TLS 1.3 統合・ 多重化・コネクション ID UDP(RFC 768) IP

図の見方:従来は HTTP/2・TLS・TCP の3層がそれぞれ独立にハンドシェイクしていた。QUIC は TLS と接続管理と多重化を1つの層に統合 し、その下を UDP に置き換える。HTTP は薄いマッピング層(HTTP/3)に痩せ細った。

QUIC の主要要素

もっと詳しく:ヘッダ保護(header protection)とその意義

QUIC ではパケット番号を含む ヘッダの可変部分も暗号化(正確には、パケット番号フィールドを AEAD 鍵から派生したマスクで XOR)する。これは:

固定の Connection ID 部分だけは平文で、ロードバランサがフローを正しいバックエンドに固定するために使える(preferred address や ID rotation の機構あり)。

ハンドシェイク比較 ─ ステップ実行で観察する

最初の HTTP リクエストが流れるまでに何 RTT かかるかを、TCP+TLS 1.3 と QUIC で 並列にステップ実行 しながら観察する。
最初の HTTP リクエストが流れるまでの RTT 比較 TCP + TLS 1.3 = 2 RTT SYN SYN+ACK ACK + ClientHello ServerHello + Cert + Finished Finished + GET / 200 OK + body 3WHS(1 RTT) + TLS(1 RTT) + GET 合計 = 2 RTT で初応答 QUIC(初回) = 1 RTT Initial(ClientHello + 鍵共有) Initial + Handshake(Cert) Handshake + 1-RTT GET / 200 OK + body TLS+接続確立を統合、すぐ GET 合計 = 1 RTT で初応答
STEP 1. どちらもクライアントから最初の1パケットを送る。TCP は SYN だけ(空)、QUIC は すでに ClientHello + 鍵共有を相乗り。出発時点で QUIC が一手得している。
STEP 2. TCP 側はサーバから SYN+ACK が返ってきた段階。まだ TLS は始まっていない。1 RTT 経過。QUIC 側はまだ片道目。
STEP 3. TCP は ACK でハンドシェイク完了 + ClientHello を初めて送る(1 RTT 終了直後)。QUIC はサーバから Initial+Handshake が返ってきて鍵交換完了の手前。
STEP 4. TCP+TLS は ServerHello・証明書・Finished をまとめて受信(2 RTT 目)。ここで初めて鍵が確定。
STEP 5. TCP+TLS:Finished + GET / を送る(2 RTT 完了)。QUIC:Handshake 完了と同時に 同じパケット内 に GET / を載せて送る(1 RTT 完了)。
STEP 6. 両者ともレスポンスが返るが、QUIC は 1 RTT 早く ボディが届き始める。RTT=100 ms なら 100 ms 短縮。0-RTT 再開ではさらに短縮(最初のパケットに HTTP を同梱)。

0-RTT 再開と、その代償

QUIC は過去にハンドシェイクした相手であれば、ClientHello に 事前共有鍵(PSK)で暗号化した HTTP リクエスト を相乗りさせ、サーバ応答を待たずに 1 パケット目から要求を送れる(0-RTT データ)。ただし、PSK で暗号化された 0-RTT データは 前方秘匿性(PFS)を持たない、かつ リプレイ攻撃 に脆弱という重大な制約がある。

もっと詳しく:0-RTT のリプレイ攻撃と運用ガード

攻撃者は過去の 0-RTT パケットをそのまま記録しておき、後で再送することができる。パケット内容(暗号文)は同じだが、サーバから見ると正しい認証コードを持つ「正規のリクエスト」に見える。GET なら冪等なので副作用は薄いが、POST で「商品を購入」「送金」など 非冪等な操作 を 0-RTT で受け付けると、リプレイで二重実行される。

つまり 0-RTT は「速いが、慎重にしか使えない」機能。実運用では 1-RTT 確立がデフォルトの主役で、0-RTT は CDN ↔ 既知ユーザの 2 回目以降などで限定的に活躍する。

ストリーム多重化と HOL の解消

QUIC のストリームは「バイト単位の独立した順序保証チャネル」として設計されている。HTTP/2 と異なり、ストリーム間に カーネルや TCP の順序保証が干渉しない。これがロス時の挙動を根本から変える。

ロス1パケットでの挙動比較(アニメーション)

パケットロス時の挙動 ─ ストリームは独立か? HTTP/2 over TCP s1 s3✗ s5 s7 stream 3 が1パケット欠落 → TCP は s5/s7 もアプリへ渡さず保留 全ストリームが詰まる(TCP 層 HOL) アプリは何も読めない…再送が来るまで待機 HTTP/3 over QUIC stream 1 stream 3 stream 5 ✗ ロス stream 3 だけ再送待ち stream 1/5 はそのまま完走 独立順序保証で HOL なし アプリは s1/s5 を即座に処理可能

図の見方:左の TCP では1ストリームのロスが「全ストリームの詰まり」になる。右の QUIC ではストリームごとに独立した順序保証を持つので、ロスしたストリーム以外は そのまま流れ続ける。これがトランスポート層 HOL の解消。

確認: QUIC が動くトランスポート層プロトコルは次のうちどれか?

正解:B(UDP)。QUIC は UDP データグラムの上に信頼性・暗号化・多重化を再実装する。TCP の上では走らない(走らせる意味もない、TCP の制約を避けるための設計だから)。SCTP は別系統のトランスポートで広く未デプロイ。ICMP はそもそも上位プロトコルを乗せる用途ではない。

コネクション ID と経路移動耐性

TCP コネクションは (送信元 IP, 送信元 Port, 宛先 IP, 宛先 Port) の 5-tuple でしか識別できない。NAT リバインドや Wi-Fi → 4G の切替で IP が変わると、TCP からは 別コネクション として扱われ、再ハンドシェイクが必要になる。QUIC はこの根本問題を解く。
POINT QUIC の コネクション ID(Connection ID, CID) は QUIC ヘッダ内の 0〜20 バイトのフィールドで、5-tuple とは独立にコネクションを識別 する。CID が一致すれば、たとえ送信元 IP/Port が変わっても 同じコネクションの続き として処理される。

モバイル切替時の挙動

Wi-Fi → 4G 切替時のコネクション継続 スマートフォン QUIC サーバ Wi-Fi 経由(IP=192.168.1.5) CID=0xabcd ◀ パケット内に常にこの ID 4G に切替後(IP=10.55.32.7) CID=0xabcd ← 同じ ID で継続 サーバは「IP 変わったが CID=0xabcd だから同じ接続」と判断 → 続きを処理 Path Validation でなりすまし防止 → 新経路を採用 TCP では再ハンドシェイクが必要だった同じ場面で、QUIC は無瞬断に近い切替が可能

図の見方:CID が 5-tuple から独立しているので、IP/Port が変わっても CID が同じなら同じコネクションを続けられる。電車で Wi-Fi が切れて 4G になった瞬間でも、ビデオ会議や HTTP/3 ストリームが切れにくい。

Connection Migration と Path Validation

QUIC は IP 変更を検知すると Connection Migration を発動し、PATH_CHALLENGE / PATH_RESPONSE フレームで新経路の到達性とアドレスのなりすまし防止を確認する(Path Validation, RFC 9000 §8)。検証成功後、輻輳ウィンドウを 初期値にリセット しつつ新経路に切替える(過去の経路特性は新経路では有効でないため)。

つながる知識: Mobile IP や MPTCP も「IP 移動の継続」を狙った技術だが、いずれもデプロイメントが進まなかった。QUIC が成功した本質は、OS 非依存のユーザ空間で、暗号化ヘッダの中に同じ仕組みを入れ込めた こと。標準化の問題ではなく、デプロイメントの問題を先に解いた点で工学的に巧い。

HTTP/3 と QPACK ─ HTTP セマンティクスを QUIC に乗せる

HTTP/3(RFC 9114, 2022)は HTTP セマンティクス(RFC 9110) を QUIC ストリーム上に再マッピングした薄い層である。HTTP メソッド・ヘッダ・ステータスコードといった意味論は HTTP/2 と同じで、変わるのは 運送層 だけ。

3つのプロトコルバージョンを並べて比較

HTTP/2(over TCP+TLS)

HTTP/3(over QUIC)

QUIC ハンドシェイク詳細

QPACK ─ HPACK の HOL 問題をどう解いたか

HPACK は 動的テーブル を持つため、エンコーダとデコーダの状態が 正確に同期 していなければならない。HTTP/2 では1本の TCP に乗っているので順序が保証され問題なかったが、QUIC ではストリームが独立に届く可能性があるため、古いテーブル状態でデコードできない参照 が来てしまうとそのストリームを止めるしかなくなる(再び HOL!)。

もっと詳しく:QPACK と HPACK の差分(RFC 9204)

結果として、動的テーブルを使わなければ完全に並列デコード可能、使う場合でもブロックは 影響を受けたストリームに限定 される。HPACK が孕んでいたヘッダ圧縮起因の HOL は QUIC ストリームの設計と整合する形で消えた。

性能と採用状況 ─ HTTP/3 は常に速いとは限らない

QUIC/HTTP3 は理論的にはレイテンシ・HOL の両面で TCP+HTTP/2 を上回る。しかし実測では 場面により遅くなる こともある。なぜか。

採用状況(2024 年時点の主要事業者・ブラウザ)

カテゴリ事業者・実装状況
CDNCloudflare、Fastly、AkamaiHTTP/3 を全顧客で既定有効
大規模事業者Google、Meta(Facebook)、Microsoft、Apple主要サービスで HTTP/3 を提供
ブラウザChrome、Edge、Firefox、Safari2020〜2022 年に順次有効化
OS / 標準ライブラリWindows(msquic)、Linux(quiche/ngtcp2)、macOS/iOS(Apple URLSession)API レベルで利用可能

Q. HTTP/3 が HTTP/2 より 遅くなる 場面が実測で報告されている。考えられる原因を3つ挙げよ。

知っておくべき実測の傾向

課題と関連研究 ─ QUIC が拓いた新しい地平

QUIC は単なる「速い HTTP の運び役」ではなく、新しい多用途トランスポート基盤 として周辺技術を生みつつある。

運用上の課題

関連プロトコル

主要実装の地図

実装言語主体特徴
quicheRustCloudflare本番運用クラスのライブラリ。BoringSSL ベース。Nginx パッチもあり
msquicCMicrosoftWindows / Linux で広く使用。.NET と連携。クロスプラットフォーム
ngtcp2CTatsuhiro Tsujikawa(独立)研究・実装の参照点。OpenSSL 系と連携。curl/HTTP3 の下層
quinnRustコミュニティRust エコシステム標準。rustls と組み合わせる
lsquicCLiteSpeed商用 Web サーバ向けに最適化された実装
aioquicPythonコミュニティ研究・教育用に読みやすい。プロトタイプに最適

研究の方向性: QUIC は「新しい輻輳制御を地球規模で試す実験場」になりつつある。OS カーネルから切り離されたユーザ空間実装は、発展 BBR/CUBIC のような最新アルゴリズムを 1日で全世界にデプロイ できる。これは TCP の世界では考えられなかった速度であり、輻輳制御研究そのものの研究サイクルが変わりつつある。

まとめと用語チェック

SUMMARY 1. QUIC は UDP 上に 信頼性・暗号化・接続確立・多重化・経路移動耐性 を統合した新しいトランスポート(RFC 9000, 2021)
2. 動機は3つ:段重ねハンドシェイクの遅さ・TCP 層 HOL・ミドルボックスによるプロトコル硬直化
3. TLS 1.3 を内蔵 し 1-RTT 確立。再開時は 0-RTT(ただしリプレイ攻撃のためメソッド限定)
4. ストリームごとに 独立した順序保証 を持ち、ロスの影響をストリーム単位に閉じ込める
5. コネクション ID により 5-tuple 非依存で、Wi-Fi → 4G などの経路移動に強い
6. HTTP/3(RFC 9114, 2022)は HTTP セマンティクスを QUIC に乗せ替えた薄い層。QPACK(RFC 9204)が HPACK の HOL を解消
7. CDN・主要事業者・主要ブラウザが採用済み。実測は多くの場面で速いが、UDP CPU コスト・UDP ブロック・実装成熟度 で常に勝つわけではない
8. 関連:MASQUE、WebTransport、Multipath QUIC、HTTP Datagram。実装は quiche / msquic / ngtcp2 / quinn / lsquic

用語チェック

用語1行説明
QUICUDP 上に再設計された信頼性・暗号化・多重化トランスポート(RFC 9000, 2021)
HTTP/3HTTP セマンティクスを QUIC 上に乗せ替えた版(RFC 9114, 2022)
段重ねハンドシェイクTCP 3WHS の上に TLS ハンドシェイクが乗る、計 2〜3 RTT の遅延
TCP 層 HOL ブロッキング1 TCP に乗せた論理ストリームが、TCP の順序保証で道連れに止まる現象
protocol ossificationミドルボックスが既知のヘッダ形にしか対応せず、新拡張が現場で通らない状態
1-RTT / 0-RTTQUIC の初回 / 再開ハンドシェイク。0-RTT はリプレイ脆弱性のため冪等のみ推奨
QUIC ストリーム独立した順序保証を持つ双方向 / 一方向のバイトストリーム
コネクション ID(CID)5-tuple 非依存にコネクションを識別する 0〜20 バイトの ID
Connection MigrationIP/Port 変更時に CID をキーに同じコネクションを継続する機能
Path Validation新経路のなりすまし防止。PATH_CHALLENGE / PATH_RESPONSE で確認
Header ProtectionQUIC ヘッダの可変部を AEAD 派生鍵で覆う仕組み。観測者から不可視に
QPACKHTTP/3 のヘッダ圧縮(RFC 9204)。HPACK の HOL を解消
MASQUEQUIC 上に UDP/IP トンネルを構築するフレームワーク
WebTransportQUIC ベースの双方向ストリーム + データグラム API(W3C)
Spin BitQUIC で唯一外部観測可能な 1 bit。経路上の RTT 推定に使われる
NEXT: 次回 発展 輻輳制御アルゴリズム(BBR/CUBIC) では、TCP / QUIC のいずれにも乗る輻輳制御の最新世代(BBR、CUBIC、PCC、Copa) を比較する。本講で見た「QUIC ならアルゴリズムを即時にデプロイできる」性質と直結する。

確認問題

問1. QUIC が動作するトランスポート層プロトコルとして正しいものを選べ。

次の選択肢から最も適切なものを1つ選択してください。
A. TCP の上に QUIC ヘッダを足したもの
B. UDP の上で動く独立した信頼性プロトコル
C. SCTP を IETF が改名したもの
D. IP の上で TCP/UDP を介さず動く独自プロトコル
正解:B
QUIC は UDP データグラムの上に 信頼性・暗号化・多重化・接続確立 を再実装した新トランスポート。TCP の上で動かすことは設計上意味がない(TCP の制約から逃れるための設計だから)。SCTP は別系統。IP 直上では NAT/FW を通り抜けにくいため UDP 経由を選んでいる。

問2. HTTP/2 で「TCP 層 HOL ブロッキング」が解消されない理由として最も適切なものを選べ。

次の選択肢から最も適切なものを選択してください。
A. HTTP/2 はストリーム多重化機能を持たないから
B. HTTP/2 は TLS を必須としないから
C. TCP は受信したセグメントを必ず順序通りにアプリへ渡す仕様で、1パケットの欠落で他ストリームの配送も保留されるから
D. HPACK が同期エラーを起こすから
正解:C
HTTP/2 はアプリ層では複数ストリームを多重化(A は誤り)するが、下層の TCP は バイトストリームの順序保証 を強制する。あるストリームのパケットが1つロスすると、後続パケット(別ストリームのものでも)を OS が buffer に貯めるだけでアプリへ渡さなくなる。これは TCP の仕様そのもの。HPACK の問題は別のレイヤ(D は QUIC 文脈で QPACK が解いた問題)。

問3. QUIC のコネクション ID(CID)について最も適切な記述を選べ。

次の選択肢から最も適切なものを選択してください。
A. CID は IP アドレスと同じで、IP が変わると別コネクションとして扱われる
B. CID は QUIC ヘッダにはなく、IP オプションフィールドに格納される
C. CID は TCP のシーケンス番号と同じ役割で、再送のためだけに使われる
D. CID は 5-tuple とは独立にコネクションを識別し、IP/Port が変わっても接続継続を可能にする
正解:D
CID は QUIC ヘッダ内の 0〜20 バイトの ID で、5-tuple とは独立にコネクションを識別する。Wi-Fi → 4G などの IP 切替で 5-tuple が変わっても、CID が一致すれば 同じ接続の継続 として扱える(Connection Migration、PATH_CHALLENGE/RESPONSE で経路検証)。A は逆、B は誤り(IP オプションは未使用)、C は別概念(順序はパケット番号)。

問4. QUIC の 0-RTT データに関する説明として最も適切なものを選べ。

次の選択肢から最も適切なものを選択してください。
A. 過去に確立した接続の鍵情報を再利用して、初回パケットにアプリデータを同梱できる。リプレイ攻撃の懸念から冪等メソッドのみが推奨される
B. 通信を完全に暗号化しないモードで、性能優先のため認証や完全性は提供しない
C. 0-RTT は前方秘匿性(PFS)を強化するために導入された機能である
D. 0-RTT は HTTP/3 では未対応で、QUIC v2 で初めて採用される予定である
正解:A
0-RTT は再接続時に PSK で早期データを暗号化して相乗りさせる機能で、初回 RTT を待たずに HTTP リクエストを送れる。ただし 0-RTT データは 前方秘匿性を持たず、リプレイ攻撃に脆弱 なため、RFC 9001 の指針および主要ブラウザは GET/HEAD など 冪等メソッドのみ を 0-RTT で送る。B(暗号化はあり、認証もあり)、C(逆。むしろ PFS は 1-RTT データのみ)、D(QUIC v1/RFC 9000 で既に規定)はいずれも誤り。

問5. 「HTTP/3 は HTTP/2 より速いとは限らない」と言われる根拠として、最も不適切なものを選べ。

次の選択肢から最も不適切な(=理由として成立しない)ものを選択してください。
A. UDP のパケット処理がカーネルで TCP ほど最適化されておらず、サーバ側の CPU コストが高い
B. HTTP/3 は HTTP セマンティクスを廃止して新しいメソッド体系を導入したため、HTTP/2 サーバと相互運用できない
C. 一部のネットワーク経路で UDP/443 がブロックされ、TCP+TLS にフォールバックすることがある
D. データセンタ内のような低 RTT・低ロス環境では、ハンドシェイク短縮の恩恵が小さく、CPU コストが相対的に目立つ
正解:B(これが不適切=理由として成立しない)
HTTP/3 は HTTP セマンティクス(RFC 9110)を完全に維持 しており、メソッド・ヘッダ・ステータスコードは HTTP/1.1/2 と同じ。変えたのは下層の運送だけ。Alt-Svc / HTTPS RR で同一サーバが HTTP/2 と HTTP/3 を併存提供することは普通。A・C・D は実際に「HTTP/3 が場面によって遅くなる」原因として広く報告されている事実(EPIQ '20 ワークショップ・Cloudflare の運用記事等)。
← PREV
第32回 VLAN
NEXT →
第34回 WebSocket