DEEP DIVE: WEBTRANSPORT

WebTransport：HTTP/3時代の低遅延双方向通信

WebSocketには「1本のTCPストリームに全部を詰め込む」という構造上の限界があります。QUIC（HTTP/3）の上に構築された新しいブラウザAPI・WebTransportは、ストリームの多重化とデータグラムという2つの武器で、この限界を乗り越えようとしています。WebSocketとの違い、WebRTC DataChannelとの役割分担を軸に詳説します。

WebSocketの限界：なぜ1本のストリームでは足りないのか

WebSocketはTCPコネクションの上に構築された、ブラウザとサーバー間の双方向通信の標準的な手段です。TCPは「送った順に、抜けなく届ける」ことを保証してくれる信頼性の高いプロトコルですが、この保証こそがWebSocketの弱点でもあります。TCPは論理的に単一のバイトストリームであり、WebSocket上でどれだけ多くの独立したメッセージを送っていても、輸送の実体は1本の管でしかありません。途中のパケットが1つでも失われると、TCPはその欠けたパケットが再送されて届くまで、後続のすべてのバイトをアプリケーションに渡さずに待たせます。これがHead-of-Line（HoL）ブロッキングです。チャット・ゲームの状態更新・ファイル転送を同じWebSocket接続に相乗りさせていた場合、たった1つのパケットロスがそのすべてを巻き込んで足止めしてしまいます。

さらにWebSocketには、そもそも「信頼性を捨てる」という選択肢がありません。オンラインゲームのプレイヤー座標や、リアルタイム音声のフレームのように、多少欠けても構わないから、とにかく最新の値を最速で届けたいというデータには、再送や順序保証はむしろ足かせになります。古い座標が再送されてきても、届く頃には次の座標がすでに新しく送られているのなら意味がありません。しかしTCPの上に立つWebSocketには、この「信頼性を意図的に下げて遅延を削る」という調整の余地がなく、アプリケーション側は不要な再送を待たされ続けることになります。こうした構造的な限界に対する回答として登場したのが、HTTP/3の上に構築される新しいAPI・WebTransportです。

WebTransportとは：HTTP/3（QUIC）の上のブラウザAPI

WebTransportは、IETFとW3Cが共同で策定を進めているプロトコル兼ブラウザAPIで、HTTP/3、その基盤であるQUICの上に構築されています。QUICはGoogleが開発しIETFで標準化されたトランスポートプロトコルで、TCPではなくUDPの上に実装されている点が最大の特徴です。UDP自体には信頼性も順序保証もありませんが、QUICはその上に独自のストリーム多重化・再送・輻輳制御・暗号化を実装することで、TCP+TLSに匹敵する信頼性を、TCPが抱える構造上の制約なしに実現しています。WebTransportは、このQUICの能力をブラウザからJavaScriptで直接扱えるようにしたAPIです。

UDPベースの多重化: QUICの複数のストリームは、OSやネットワーク機器から見ればすべて同じUDPコネクションの一部だが、ストリームごとに独立して管理されるため、1本のストリームでパケットが失われても他のストリームは影響を受けない。TCPのように「1本の管を共有する」構造そのものを持たないため、HoLブロッキングがトランスポート層レベルで解消されている。
0-RTT再接続: 過去に接続したことのあるサーバーに再接続する場合、QUICは以前のセッション情報を使って最初のパケットからすぐにデータを送信できる（0-RTT）。TCP+TLSのハンドシェイクのように複数回の往復を待つ必要がない。
コネクションマイグレーション: TCPの接続はIPアドレスとポート番号の組で識別されるため、Wi-Fiからモバイル回線に切り替わるとIPアドレスが変わり、接続が切断されてしまう。QUICは接続をコネクションIDという論理的な識別子で管理しているため、IPアドレスが変わっても同じ接続を維持したまま通信を続けられる。
TLS 1.3が内蔵: QUICは暗号化を後付けのオプションではなく、プロトコルの必須構成要素として設計時から組み込んでいる。ハンドシェイクの往復もTLSの往復と統合されているため、平文のQUIC接続というものは仕様上存在しない。

3つの通信モード：ストリームとデータグラムの使い分け

WebTransportがWebSocketと最も大きく異なるのは、用途に応じて通信の性質を選べる点です。1つの接続の中に、性質の異なる3種類の通信路を同時に開くことができます。

双方向ストリーム（Bidirectional Stream）: 信頼性があり、順序も保証される、TCPライクな通信路。1つの接続の中に何本も同時に開くことができ、しかもストリームごとに独立して管理されるため、あるストリームでパケットロスが起きても他のストリームはブロックされない。ファイル転送やAPIリクエストのように「確実に、正しい順序で」届けたいデータに向く。
単方向ストリーム（Unidirectional Stream）: 双方向ストリームと同じく信頼性・順序が保証されるが、送信方向が一方向に固定されている。サーバーからクライアントへ一方的に流し続けるログやイベント通知のように、返信を必要としないデータストリームに向く。
データグラム（Datagram）: 信頼性も順序も保証されない、UDPパケットに近い性質の通信単位。再送も並び替えも行われないため、遅延は最小限に抑えられる。ただし完全にQUICの外側にあるわけではなく、輻輳制御（ネットワークの混雑状況に応じた送信レートの調整）はQUICのコネクション全体で一括して行われるため、他のストリームやデータグラムと帯域を公平に分け合う。

使い分けの直感はシンプルです。「確実に届けたいもの」はストリームへ、「最新の値だけが意味を持ち、古い値を再送されても困るもの」はデータグラムへ、と考えれば大枠を外しません。プレイヤーの位置座標や音声フレームのように、次の更新がすぐ来ることが分かっているデータは、欠けたら諦めて次を待つ方が体感の遅延が小さくなります。一方でチャットメッセージやアイテム取得イベント、スコアの確定通知のように、1件も欠かしてはいけないデータは、迷わず双方向ストリームに乗せるべきです。1つのWebTransportセッションの中で、この2つを同時に、目的別に使い分けられることこそが最大の特長です。

WebSocket・WebTransport・WebRTC DataChannelの比較

観点	WebSocket	WebTransport	WebRTC DataChannel
トランスポート	TCP	QUIC（UDPベース、HTTP/3）	SCTP over DTLS over UDP
多重化	なし（1本のストリームのみ）	あり（複数ストリームを独立管理）	あり（複数チャネルを独立管理）
信頼性の選択	常に信頼性あり（選べない）	ストリーム/データグラムを用途で選べる	チャネルごとに信頼性・順序を設定可能
接続形態	クライアント–サーバー	クライアント–サーバー	ピア間（P2P）が主目的
NAT越え・シグナリング	通常のHTTPと同様、不要	通常のHTTPと同様、不要	NAT越えとICE/STUN/TURN、シグナリングサーバーが必要

WebRTC DataChannelとの関係：競合ではなく役割分担

WebTransportとWebRTC DataChannelは、どちらも「信頼性を選べる低遅延データ通信」を提供する点でよく似ており、しばしば比較の対象になります。しかし両者は競合というより、想定する通信形態がそもそも異なります。WebRTCはブラウザ同士がピア対ピアで直接データをやり取りすることを主眼に設計されています。そのためには、相手の接続先候補を交換するシグナリングと、双方が異なるNATの背後にいても直接経路を開通させるNAT越え（ICE/STUN/TURN）という、決して軽くないセットアップの手間が伴います。対してWebTransportは素直なクライアント–サーバー型で、通常のHTTPS接続と同様にサーバーのURLへ接続を張るだけで済み、シグナリングもNAT越えの調整も不要です。

この違いは、P2Pメタバースのようなシステムのアーキテクチャ選択に直結します。プレイヤー同士が直接データをやり取りするフルメッシュ型・P2P型のトポロジーを目指すなら、確立されたエコシステムを持つWebRTC DataChannelが自然な選択です。一方で、多数のクライアントが1つの権威あるサーバー（またはリレーサーバー）と通信し、サーバー側が状態同期やAOI（Area of Interest）管理の中心を担うクライアント–サーバー型のアーキテクチャもあります。その場合は、シグナリングの手間がなくHTTP/3のインフラにそのまま乗るWebTransportの方が実装も運用もシンプルになります。実際には、ピア同士の直接通信にWebRTC、権威サーバーとの同期にWebTransportというように、1つのシステムの中で両者を使い分けるハイブリッドな構成も十分にあり得ます。

主なユースケース

クラウドゲーミング: 入力操作の送信とゲーム状態の受信を低遅延に保ちつつ、映像・音声ストリームとは別のチャネルとして制御データを扱う。
ライブ配信: 低遅延な映像・音声チャンクの配信に加え、視聴者からのチャット・リアクションのような双方向データを同じ接続に統合できる。
リアルタイム共同編集: ドキュメントの差分（オペレーション）は確実に届ける必要があるため双方向ストリームで、カーソル位置のような頻繁かつ即時性が優先される更新はデータグラムで、と使い分けられる。
IoTテレメトリ: 大量のセンサーデバイスから断続的に送られてくる計測値を、コネクション確立のコストを抑えつつ（0-RTT）効率よく収集する。
メタバースの状態同期: プレイヤーの位置・姿勢のような高頻度で上書きされる値はデータグラムで、アイテムの取得やチャットのような欠落が許されないイベントはストリームで送る、という設計がそのまま当てはまる。

課題と現状

標準化の途上: WebTransportはIETFとW3Cの双方で仕様策定が進められており、コアとなるプロトコルやAPIの大枠は固まりつつあるものの、関連仕様には長期間ドラフトの状態が続いているものもある。仕様の細部は今後も変わり得る前提で追跡する必要がある。
ブラウザ実装の差: 主要ブラウザでの実装は着実に進んでいるが、対応状況や細かな挙動には差があり、本番投入にあたってはターゲットとするブラウザでの動作検証が欠かせない。
UDPをブロックするネットワークへの対応: 企業ネットワークや一部のモバイル網など、UDPトラフィックを制限・遮断する環境は珍しくない。こうした環境でも通信を継続できるよう、HTTP/2ベースでWebTransport相当のセマンティクスを提供するフォールバック仕様も別途検討されている。
サーバー側エコシステムの若さ: WebSocketに比べると、QUIC/HTTP/3およびWebTransportをサポートするサーバー実装やライブラリ、運用ノウハウの蓄積はまだ発展途上であり、既存インフラとの統合には相応の検証が必要になる。