WebTransport（HTTP/3上の双方向通信）

WebSocket では足りなかったもの

/network/websocket-protocol/ は「1 本の順序付きメッセージ列を全二重で流す」ための優れた土台ですが、下地が TCP であるため二つの構造的制約を抱えます。第一に、単一の順序付きバイトストリームなので、独立した複数の論理チャネルを 1 接続で扱いたくても、それらは同じ TCP 順序に縛られます。第二に、TCP は欠落セグメントを再送し終えるまで後続データをアプリへ渡さないため、ヘッドオブラインブロッキング（HoL ブロッキング） が避けられません。1 パケットの喪失が、論理的には無関係な後続メッセージまで足止めします。

WebTransport は、この二つを QUIC の力で解く「ブラウザから使えるアプリ層トランスポート」です。HTTP/3 と同じ QUIC 接続の上に、複数の独立したストリームと、順序も再送も持たないデータグラムを同居させ、送信するデータごとに信頼性と順序保証の要否を選べるようにします。土台となる QUIC のストリーム多重化・暗号化・コネクション ID の詳細は /network/quic-internals/ を前提とします。

QUIC が HoL ブロッキングを消す仕組み

WebTransport の中核的な価値は、QUIC がストリームを独立の順序空間として扱う点に由来します。TCP では 1 本のシーケンス番号空間しかないため、番号の穴（欠落）が埋まるまで全体が待ちます。QUIC は各ストリームに独立したフロー制御とオフセットを与え、パケット喪失時の再送もそのストリームのデータだけをやり直します。

横にスクロール

TCP（WebSocket）: [S1-a][S2-a][S1-b(欠落)][S2-b] ...
  → S1-b の再送完了まで S2-b もアプリに渡らない（HoL ブロッキング）

QUIC（WebTransport）: ストリーム1: a → b(欠落・再送) 
                      ストリーム2: a → b  ← 1 の欠落と無関係に進む

したがって「独立した用途は独立したストリームに分ける」のが WebTransport 設計の基本方針になります。ゲームのチャットと状態同期を別ストリームにすれば、片方のパケット喪失がもう片方を止めません。なお TLS 記録層の HoL とは層が異なる話であり、ここで消えるのはあくまでトランスポート層の待ちです。

三つの送信プリミティブ

WebTransport はアプリに三種類の送信手段を与えます。用途に応じて明示的に選ぶのが要点です。

データグラムは QUIC の DATAGRAM フレーム（RFC 9221）を土台とし、HTTP レイヤでは HTTP データグラム（RFC 9297）として運ばれます。再送しないため、古くなった位置情報を律儀に届けるより「次の新しい値」を送る方が有利な用途で威力を発揮します。逆に、順序と確実な到達が必要なら双方向ストリームを使います。両者を同じセッションで同時に使える点が、単一メッセージ列しか持たない WebSocket との決定的な差です。

ブラウザ API モデル

ブラウザからは、セッション・ストリーム・データグラムがそれぞれ Streams API のオブジェクトとして露出します。TCP ソケットのような生バイト列ではなく、ReadableStream / WritableStream を介した非同期モデルです。

// セッション確立（HTTP/3 上に張られる）
const wt = new WebTransport("https://example.com:4433/counter");
await wt.ready;

// データグラム送受信（非順序・非信頼）
const writer = wt.datagrams.writable.getWriter();
await writer.write(new Uint8Array([0x01, 0x02]));

// 双方向ストリーム（順序・信頼あり）
const stream = await wt.createBidirectionalStream();
const sw = stream.writable.getWriter();
await sw.write(new TextEncoder().encode("hello"));

// サーバーが開いた受信ストリームを受ける
for await (const incoming of wt.incomingUnidirectionalStreams) {
  // incoming は ReadableStream
}

セッションはプロトコル上、HTTP/3 の拡張 CONNECT（:protocol = webtransport）で確立されます。これは HTTP/2 の Extended CONNECT（RFC 8441）と同じ発想を HTTP/3 へ持ち込んだもので、通常の HTTP/3 リクエストと同一の QUIC 接続を共有できることを意味します。つまり同じ接続でページ資源を配りながら、その中の一部を WebTransport セッションとして使えます。HTTP/3 が既存 HTTP とどう連続しているかは /network/http-versions/ が背景になります。

WebSocket との使い分け

両者は競合するというより、必要とする性質が違います。順序付き単一チャネルで十分なチャットやシンプルな通知なら WebSocket が依然として簡潔です。一方、多数の独立チャネルを多重化したい、HoL ブロッキングを避けたい、信頼性を犠牲にしても最新値の低遅延到達を優先したい、という要件が一つでも強いなら WebTransport が適します。

低遅延用途での位置づけ

リアルタイムメディアや対戦ゲームの領域では、これまで /network/webrtc-ice-stun-turn/ の DataChannel（SCTP over DTLS）が「ブラウザで非信頼・非順序を選べる」数少ない手段でした。WebTransport は、その選択肢をクライアント・サーバー型に近い簡潔なモデルで提供します。WebRTC が P2P とメディア交渉のために重い ICE/SDP 折衝を要するのに対し、WebTransport はサーバーへの単純な接続で多重化ストリームとデータグラムを得られるため、サーバー集約型の低遅延配信や状態同期では構成が明快になります。

要するに WebTransport は、「順序保証と信頼性は本来アプリが送信ごとに選ぶべきもの」という QUIC の設計思想を、そのままブラウザ API へ引き上げたトランスポートです。全部を順序付き・再送ありで縛る WebSocket と、P2P とメディアに特化した WebRTC の中間で、サーバー型の低遅延双方向通信という空白を埋める位置にあります。