UDP と QUIC 伝送層

UDP はデータグラムの境界を保持するが、配信、順序、重複排除を保証しない。QUIC は UDP を介して独自の暗号化パケット、確認応答、マルチストリーム機構を伝達し、信頼できるストリームを提供するほか、拡張により信頼性のないデータグラムも伝達できる。これらを選択する際は、UDP を「高速」、QUIC を「常に接続されている」と安易に考えず、メッセージかバイトストリームのどちらが必要か、期限切れの破棄が許容されるか、成功をどう確認するかといったビジネス要件を明確にするべきである。

UDP：8 バイトのヘッダの先に利用責任がある

UDP ヘッダは、ソースポート、宛先ポート、Length（長さ）、Checksum（チェックサム）の 4 つの 16 ビットフィールドで構成される。Length には 8 バイトの UDP ヘッダが含まれる。通常のフィールドの最大値は 65535 だが、オプションなしの IPv4 では IP 総長の制約も受けるため、最大 UDP データは 65535−20−8=65507 バイトとなる。このプロトコル上の上限は、一般的なパスで直接伝達可能なサイズよりもはるかに大きいため、アプリケーションがこれほど大きなデータグラムを送信することは推奨されない。RFC 768：UDP

MTU=1500、オプション/拡張ヘッダなしの場合、IPv4 UDP データは最大 1472 バイト、IPv6 は 1452 バイトとなる。トンネリングや QUIC 自体のオーバーヘッドによりさらに削減される。もし 1 つの UDP データグラムが IP 断片化された場合、通常、すべての断片が正常に再構成されて初めてこのデータグラムが配信されるため、1 つでも断片が欠けるとデータグラム全体が失われる可能性がある。

IPv4 UDP のゼロチェックサムフィールドは、チェックサムが提供されていないことを示す。実際の計算結果がゼロの場合、オンラインではすべて 1 を送信する必要がある。IPv6 UDP ではデフォルトでチェックサムが要求され、特定のトンネル例外やジャンボグラムには独立したルールがあるため、例外を一般的なアプリケーションのデフォルトと見なしてはならない。チェックサムは擬似ヘッダと UDP メッセージをカバーするが、送信者の身元認証は行わない。

アプリケーションは、損失、順序入れ替え、重複、サイズ探査、輻輳制御を処理する必要がある。UDP の connect はローカルのデフォルト相手先やフィルタリングなどのソケット動作を設定できるが、TCP 的なリモートハンドシェイクは実行しない。send の成功は、相手先が受信したことを証明するものではない。リアルタイム業務では、期限切れのデータをあえて破棄することもあるが、それでも送信負荷は制御する必要がある。RFC 8085：UDP アプリケーションガイドライン

QUIC の 4 層オブジェクト

1 つのストリームが多数のパケットに跨ることもあれば、1 つのパケットが複数のストリームのフレームを運ぶこともある。損失発生後の再送では、回復に必要な情報を別のパケットに詰め直して再分割する必要があるため、古いパケットをそのまま再送するわけではない。

ロングヘッダ、ショートヘッダと可視情報

QUIC v1 では、Initial、Handshake、0-RTT はそれぞれロングヘッダを使用し、1-RTT はショートヘッダを使用する。Retry やバージョン交渉には特殊な構造があり、固定のバイトテーブルで全タイプを覆うことはできない。ロングヘッダには Version、接続 ID 長さなどの情報が含まれる。ショートヘッダの宛先 CID 長さは接続コンテキストに依存するため、単独でキャプチャされた孤立したパケットだけでは完全に解析できない。RFC 9000：パケットフォーマット

パケット番号はオンラインでは必要な下位ビットのみが符号化され、受信側がコンテキストと組み合わせて回復する。一部のヘッダフィールドはヘッダ保護を受けており、保護解除前にそれらを平文のフラグとして直接分析することはできない。v1 ベースラインの QUIC Bit ルールにも後続の交渉拡張が存在するため、そのビットの解釈には交渉結果を組み合わせる必要がある。RFC 9287：QUIC Bit 拡張

Spin Bit はオプションの測定信号であり、エンドポイントが提供しない場合もあり、観察は損失、順序入れ替え、パスの影響を受ける。それは、各エンドポイントが厳密に 1 つのタイマーに従って「RTT ごとに 1 回反転する」汎用クロックではなく、アプリケーションのリクエスト遅延も明らかにしない。

再送するのは情報か、それとも元のパケットか？

まずパケット 11 のみを配信し、ストリーム 4 には配信可能なデータがあるが、ストリーム 0 は空のままである。次にパケット 12 を送り、遅延していたパケット 10 を最後に補送する：パケット確認セットは増加するが、一意のストリームデータ量は増加しない。この 2 つの番号空間を統合して理解してはならない。

ハンドシェイクと暗号化レベル

QUIC は TLS 1.3 のハンドシェイクメッセージと鍵交渉を使用するが、TLS レコードを伝送ストリームにそのまま適用するものではない。CRYPTO フレームは、対応する暗号化レベルでハンドシェイクバイトを伝達する。Initial、Handshake、0-RTT、1-RTT の保護と使用条件は異なる。Initial 鍵は公開情報から派生できるため、Initial パケットの保護は、ネットワーク観察者に対してすでに機密である、またはサーバー認証が完了したことを意味しない。RFC 9001：TLS と QUIC

初回のハンドシェイクでは、往復 1 回で対応するアプリケーション通信を開始できる場合が多いが、Retry、証明書サイズ、損失、スケジューリングにより実測時間が変化する。サーバーはクライアントのアドレスを検証する前に増幅攻撃防止の制限を受け、通常、受信したバイト数の 3 倍までしか送信できない。これにより、ハンドシェイクデータを一度に送信し尽くすことが制限される可能性がある。

クライアントが Initial を運ぶ UDP データグラムは、少なくとも 1200 バイトに拡張する必要がある。これは UDP ペイロードを指しており、UDP/IP を加えてちょうど 1200 バイトになることを意味するものではない。オプションなしの IPv6 では、対応する IP パケットは少なくとも 1248 バイトとなり、実際のパスも考慮する必要がある。RFC 9000：データグラムサイズとアドレス検証

0-RTT：早期送信は、早期の完全な保証の獲得ではない

接続を再開する際、クライアントは保存された TLS 回復状態と、沿用が許可された伝送パラメータに基づいて早期データを送信できる。初回アクセスでは、これらの条件を凭空に持つことはできない。サーバーは早期データを拒否する可能性があり、TLS の受領信号が結果を決定する。QUIC にはこの目的のための REJECTED フレームはない。拒否された場合、クライアントはプロトコルとアプリケーションインターフェースに従って元の早期データを処理する必要があり、拒否をビジネスがすでに実行されたものと見なしてはならない。RFC 9001：0-RTT

0-RTT にはリプレイ攻撃のリスクがあり、アプリケーションは操作のセマンティクスとデプロイメントにおけるリプレイ防止を判断する必要がある。HTTP のメソッド名だけでは不十分である。誤実装された GET でも副作用が発生する可能性がある。AEAD の鍵使用上限は暗号学的リスクを制限するが、ビジネスの重複排除や攻撃者のリプレイ回数の制限を提供するものではない。

ストリーム番号とフロー制御：制限は累積上限

ストリーム ID の最下位ビットは開始エンドポイント（0: クライアント、1: サーバー）を表し、下から 2 番目のビットは方向（0: 双方向、1: 単方向）を表す。残りの上位ビットはこのカテゴリのシーケンス番号である。したがって、各カテゴリの ID は 4 ずつ増加する。

双方向ストリームの 2 つの送信方向には、それぞれ独自のバイトオフセットがある。MAX_STREAM_DATA は対応するストリーム方向の累積送信範囲を制約し、MAX_DATA は接続範囲内の対応するストリームデータの累積使用を制約し、MAX_STREAMS は開けることができるストリームの数を制限する。これらは交換可能な「バッファサイズ」3 つではない。RFC 9000：ストリームとフロー制御

例えば、接続の制限が 10000 バイトで、2 つのストリームがそれぞれ 4000 バイトと 3000 バイトを使用している場合、接続にはまだ 3000 バイトの余裕がある。もし対象ストリーム自体に 1000 バイトの余裕しかない場合、新しいデータは最大でもこの 1000 バイトによって制限される。既存のバイトの再送により、新しいフロー制御クォータが重複して消費されることはない。RESET_STREAM の final size も関連する帳簿計算に参加するため、上限を回避するためにリセットを繰り返すことはできない。

独立したストリームは、TCP の単一順序付きバイトストリームに起因するストリーム間の伝送層待機を解消したが、同じストリーム内ではギャップの埋め合わせが必要である。複数のストリームは輻輳制御、接続フロー制御、CPU、パスを共有する。HTTP/3 ではアプリケーションレベルの依存関係もあるため、「QUIC にはヘッドオブブロックが全くない」という記述は依然として正確ではない。

なぜ再送はフロー制御クォータを 1 つ占有しないのか？

接続の総量と対象ストリームを別々に描画して初めて、ボトルネックがどこにあるかを見ることができる。オフセットを維持したまま再送を繰り返すと、線速での重複バイトは増加するが、フロー制御の残高は変わらない。これは無料の帯域幅ではなく、再送も輻輳制御などの他の制約を受ける。

$$credi{t}_0=\min (MS{D}_0-H_0,MD-\sum _i{H}_i)$$

ACK と損失検知：確認応答は読み取りではない

Initial、Handshake、Application Data は 3 つのパケット番号空間であり、0-RTT と 1-RTT はアプリケーションデータ空間を共有する。パケット番号は各自の空間で増加し、再利用されない。ストリームバイトを再パケット化して送信する際には、新しいパケット番号が使用される。ACK は受信済みパケット番号範囲を報告するが、物理的に確認済みで失われたパケットのリストを直接列挙するものではない。

パケット 10 が確認されていないが、より大きなパケットが確認されている場合、それは損失した可能性があるか、単に順序入れ替えしただけの可能性がある。RFC 9002 は、パケット閾値と時間閾値などを使用して推論する。推奨されるパケット閾値は 3 である。時間の参照は 9/8×max(最新_rtt,平滑_rtt) であり、クロック粒度などの条件を考慮し、新しいサンプルと平滑化推定が共同で判定を制約する。判断には、より遅く送信されたパケットの確認など、コンテキストも必要である。RFC 9002：損失検知

PTO（プローブタイムアウト）の期限が到来すると、プローブが手配され、未確認パケットがすべて失われたと直接宣言されるわけではない。アプリケーションデータ空間の簡易推定を例にとると、SRTT=40 ms、RTTVAR=5 ms、max_ack_delay=25 ms、粒度 1 ms の場合、PTO の基本値は 40+max(20,1)+25=85 ms となる。ハンドシェイク空間では同様の ACK 遅延をそのまま適用せず、連続する PTO にはバックオフがある。

輻輳制御は送信負荷を決定し、回復メカニズムはどの情報を補完するかを決定する。RFC 9002 は NewReno に基づく例示の輻輳アルゴリズムを提供しているが、QUIC はすべての実装がそれを使用することを要求しない。CUBIC、BBR などは、プロトコルの制約に準拠する限り、実装によって採用できる。

CID と移行：新しいパスでも検証が必要

受信側は、自身が発行した Connection ID を使用して、新しいアドレスからのパケットを接続に関連付けることができる。CID は永遠不変の 1 ペアの番号ではない。エンドポイントはルールに従って複数の CID を発行、使用、退役でき、ショートヘッダがソース/宛先の両方の CID を同時に運ぶわけではない。ゼロ長さ CID などのデプロイメントの選択は、移行能力を制限する。

クライアントがネットワークを切り替えた後、新しいパス上の保護済みパケットでも、接続認証とパス検証を経る必要がある。PATH_CHALLENGE のランダムデータは PATH_RESPONSE によってエコーされ、帰路の到達可能性を確認するのに役立つ。NAT ポート再バインディングと能動的移行は異なる背景を持つため、能動的移行を禁止するパラメータを、すべてのアドレス変化を拒否するものと単純に理解してはならない。RFC 9000：移行と検証

パスには新しい RTT、容量、MTU がある可能性があり、関連する制御状態はルールに従って処理する必要があり、ビジネスは一時停止または失敗する可能性がある。CID が一致するだけでは、「アプリケーションが中断を全く見えない」と約束するものではない。新しいパスが UDP をサポートしていない、鍵状態が失われた、検証がタイムアウトしたなど、接続が続行できない理由があり得る。

信頼できる STREAM と信頼性のない DATAGRAM

QUIC DATAGRAM 拡張は、アプリケーションデータグラムの境界を保持し、損失データに対して STREAM 的な再送を行わず、STREAM フロー制御も使用しない。接続の輻輳制御や交渉されたサイズなどの制限は依然として適用される。それを含むパケットの ACK を受信しても、アプリケーションがそのメッセージを処理したことを意味しない。リアルタイムデータはこれに基づいて期限切れ破棄のセマンティクスを選択できるが、QUIC 暗号化が含まれていれば確実に信頼できる配信が得られるとは限らない。RFC 9221

HTTP/3、DoQ などは QUIC に対してそれぞれアプリケーションマッピングを定義している。実際の選択では、UDP の到達可能性、実装の成熟度、観測可能性、リソース消費も考慮する必要がある。ユーザー空間の実装は進化的に容易であるが、それが自動的にカーネル TCP よりも CPU を節約するわけではない。

ローカル再計算：番号、フロー制御、プロービング予算

from math import isclose

def stream_id(index,server=False,unidirectional=False):
    return (index<<2) | int(server) | (int(unidirectional)<<1)
assert [stream_id(i) for i in range(4)] == [0,4,8,12]
assert [stream_id(i,True,True) for i in range(4)] == [3,7,11,15]
assert 65535-20-8 == 65507
assert 1200+8+40 == 1248
assert min(10000-4000-3000,1000) == 1000
assert 1200*3 == 3600
srtt,latest,rttvar,ack_delay,granularity = .040,.050,.005,.025,.001
loss_delay = max(granularity,9/8*max(srtt,latest))
pto = srtt+max(4*rttvar,granularity)+ack_delay
assert isclose(loss_delay,.05625)
assert isclose(pto,.085)
# パケット 10 の内容をパケット 14 に再送：ストリームオフセットは変わらず、送信パケット番号が異なる。
sent = {10:(0,1000,500),14:(0,1000,500)}
assert sent[10] == sent[14] and 10 != 14
print('UDP/Initial サイズ、ストリーム ID、クォータ、閾値、PTO 計算例が通過')

これらのアサーションは、局所的なフィールドと予算を検証するが、完全なパケット保護、ハンドシェイク、または損失検知ステートマシンは実装しない。実際の QUIC 接続やネットワーク移行は開始されていない。

継続的な参照

• TCP：バイトシーケンス番号、ウィンドウ、回復の対照。
• ポートと NAT 穿透：マッピング、フィルタリング、パス確立。
• HTTP/3：QUIC 上の HTTP ストリームとアプリケーション依存関係。