WebTransportという技術、気になります

WebTransportという技術、気になります TechRAMEN 2025 Conference 2025/07/26 宮本直幸 @MSprzk

はじめに ● この説明は、正確さよりもわかりやすさを優先しているため、 間違っている箇所、厳密には違う場所があります ● 「WebTrasnportってなんとなくこんな感じなんだ」くらいの温度感 で聞いていただけるとありがたいです ● 質問、疑問等あれば発表後少し時間がありますので、お聞きください

軽く自己紹介 名前: Msprzk (x.com/Msprzk) *Miyamoto Naoyukiと呼ばれることもある 北海道情報大学のキラキラ1年生 ライブ配信をする、見る、関連技術を触ることが好き →どれくらい好きかというと...

• http://x.com/Msprzk

https://nicomado.com

• https://nicomado.com

WebTransportとは

WebTransportは「リアルタイム/双方向通信技術」

そもそもリアルタイム通信ってどういうもの クライアントとサーバー間で常に接続が維持され、ユーザーの操 作を待たずにデータの送受信が即座に行われる通信方式 活用場所の例: Zoom, Discord, Slack, オンラインゲーム ...and more

WebTransportは「リアルタイム通信技術」 ● 不安定なネットワーク環境に強い ● 高信頼性(低速)と低信頼性(高速)の2つのモードを選べる ● とても新しく、まだ規格はinternet-draft段階

最初のcommitが 2019年!

リアルタイム通信の歴史

特性 ポーリング/ロング ポーリング WebSocket WebRTC WebTransport 基本プロトコル HTTP/1.1 TCP UDP (SCTP/DTLS) UDP (QUIC/HTTP/3) 通信モデル リクエスト/レスポンス 全二重 全二重 全二重 主たるアーキテクチャ クライアント・サーバー クライアント・サーバー ピアツーピア クライアント・サーバー 接続オーバーヘッド 高い（リクエスト毎） 低い（初回のみ） 高い（シグナリング） 非常に低い（ QUIC） ストリーム多重化 不可 不可（HOLブロッキン グ） 可 可（HOLブロッキングな し） 信頼性モデル 信頼性のみ 信頼性のみ 信頼性/非信頼性を選択 可 信頼性/非信頼性を選 択可 Web Worker サポート 可 可 不可 可

リアルタイム通信の歴史 2011〜 2021〜 W 3 † t or グ ン †1 t sp an 2 † ke oc TC R Tr eb eb S eb W W グ リ ン ー リ ー ポ ポ ング ロ †1: RFC 6455で標準化 †2: RFC 8825で標準化 †3: 2025年7月現在, ドラフト段階 future〜...?

ポーリング サーバー クライアント 更新ある〜？ (定期的に聞く)

ポーリング ポーリングの問題点 更新がない場合でもリクエストを送信しつづけてしまう →ネットワークトラフィックとサーバー負荷が増える

WebSocket サーバー クライアント (サーバー) 更新あるヨ TCP connection (クライアント) パケット求む ↔双方向リアルタイム通信↔

WebSocket WebSocketがもたらしたもの 🔥 サーバーはクライアントからのリクエストを待つ必要なく、好きなと きにデータをプッシュできるようになった！ (活用先) チャットアプリ, オンラインゲーム, 金融取引プラットフォームなど

WebSocket WebSocketの課題🤔 HOLブロッキング(TCP) 順番通りに届かないデータがあったとき、後続のデータの 処理も待たされるという事象

HOLブロッキング(トランスポート層) サーバー クライアント パケット 4 パケット 3 パケット 2 パケット 1

HOLブロッキング(トランスポート層) サーバー クライアント 2ない！！ 2来るまで他のパケットも処理しないよ〜 パケット 4 パケット 3 パケット 1 パケット 2 🚨2をなくした!🚨

HOLブロッキング(トランスポート層) サーバー クライアント 2を再送したよ〜 パケット 4 パケット 3 パケット 2 パケット 1 📦2を再送

WebSocket WebSocketの課題🤔 HOLブロッキング→高信頼性で1つのデータストリームなら👍 しかし... 多重化したストリームのとき、1つのストリームで発生したパケット ロスが無関係のストリームも遅延させてしまう (e.g. ゲーム内チャットとプレイヤーの位置情報などを扱う場合)

WebRTC (Web Real-Time Communication) Aさん 🏎 Bさん ブラウザ間で直接 低レイテンシでデータを交換

WebRTC WebRTCのいいところ ● 遅延が少ない(>10ms が出ることもある) ● P2P通信である ● 順序保証、信頼性をストリームごとに設定できる†1 活用場所 Discordの通話やZoomなどで使用されている†2 †1: TCPとUDPの両方の性質をいい感じに使えるSCTPというプロトコルのおかげ †2: ZoomはWebRTC Datachannel を使い、独自実装しているため、厳密にはP2Pではないかも

🏎 順序保証, 信頼性をストリームごとに設定 (オンラインゲームの例) Aさん Bさん プレイヤー位置データ 低信頼性, 順序制御なし イベントデータ (スコアやアイテム取得など) 高信頼性, 順序制御あり

WebRTC WebRTCの課題 “P2P通信向けに設計されている” NAT越え, 暗号化, データ転送に複数のプロトコルが必要 多人数通信を実現するためにはサーバー側の実装が複雑になってしまい がち & P2Pのような複雑なものよりもシンプルなクライアント・サーバー型の方で 十分なケースが多い

課題点まとめ ● HOLブロッキングによって、無関係のストリームが 遅延してしまうことを避けたい ● 複雑なP2Pよりもシンプルなサーバー・クライアン ト方式で通信を行いたい

WebTransportとは

WebTransportとは ● QUICとHTTP/3を使ったブラウザとサーバー間の双方向かつ低遅延な 通信API ○ QUICは、UDP上に作られた高速で安全な通信プロトコル 接続の速さ・途切れにくさ・並列処理のしやすさが特徴 TCP/IPではトランスポート層にあたる ○ HTTP/3は、QUICの上にあるいい感じのプロトコル (HTTP/1, HTTP/2はTCPの上)

WebTransportの価値†1 ● 低遅延でサーバーと通信できる仕組みを提供 ● さまざまな用途に使える現代的なAPIを提供 ● 順序あり/なし、信頼性あり/なしのデータ送信を柔軟に選択できるように ● WebSocketと同等のセキュリティ（TLSやオリジン制御）を確保 †1: IETFの標準化目標に記載されている https://github.com/w3c/webtransport/blob/main/explainer.md

• https://github.com/w3c/webtransport/blob/main/explainer.md

†1: https://developer.mozilla.org/en-US/docs/Web/API/WebTransport_API

WebTransportは通信環境が悪い場所に強い！！ 比較データ ● WebSocket, WebTransport(信頼性モード, 非信頼性 モード)の3つを比較 ● パケットロス発生率が 0%, 5%, 15% の通信速度 ● メッセージが届いた数 元データ出典: C. Gulliksson, “Empirical analysis of the impact of packet loss on WebTransport using Socket.IO”, Umeå Univ., 2024.

遅延の比較(パケットロス率0%のとき) プロトコル 平均RTT (ms) 総送受信時間 (ms) 受信/送信メッ セージ数 WebSocket 0.17 4091.0 1000 / 1000 WebTransport (Reliable) 0.29 4086.8 1000 / 1000 WebTransport (Unreliable) 0.16 4086.2 1000 / 1000 元データ出典: C. Gulliksson, “Empirical analysis of the impact of packet loss on WebTransport using Socket.IO”, Umeå Univ., 2024.

遅延の比較(パケットロス率5%のとき) プロトコル 平均RTT (ms) 総送受信時間 (ms) 受信/送信メッ セージ数 WebSocket 50.70 4257.0 1000 / 1000 WebTransport (Reliable) 1.09 4102.0 1000 / 1000 WebTransport (Unreliable) 0.45 4065.9 899 / 1000 元データ出典: C. Gulliksson, “Empirical analysis of the impact of packet loss on WebTransport using Socket.IO”, Umeå Univ., 2024.

遅延の比較(パケットロス率15%のとき) プロトコル 平均RTT (ms) 総送受信時間 (ms) 受信/送信メッ セージ数 WebSocket 1456.10 4734.7 1000 / 1000 WebTransport (Reliable) 2.20 4107.5 1000 / 1000 WebTransport (Unreliable) 0.20 4076.2 724 / 1000 元データ出典: C. Gulliksson, “Empirical analysis of the impact of packet loss on WebTransport using Socket.IO”, Umeå Univ., 2024.

今までの課題 ● HOLブロッキングによって、無関係のストリームが遅延してしまうこ とを避けたい(WebSocketの課題) →QUICを使用しているため、ストリームを多重化しても HOLブロッキングは起きない &信頼性あるなし、順序あるなしも選べる ● 複雑なP2Pよりもシンプルなサーバー・クライアント方式で通信を行 いたい(WebRTCの課題) →WebTransportは、サーバー・クライアント方式

課題

課題 ● Safariが対応していない！ ○ 現状は、フォールバックが必要 ● HTTP/3を扱えるサーバーが必要 ● QUIC-LBなど、高度なロードバランサーが必要 既存のインフラからの移行コスト高め

WebTransportの活用

活用の例 ● 対戦型オンラインゲーム ● クラウドゲーミング ○ クラウドサーバーにSSHして、そこでゲームをするみたいなイメージ ● ライブ配信 ○ Twitch(ライブ配信プラットフォーム)では、「Warp」という WebTransport上で実行されるライブ配信プロトコルを作っ ている†2 †1: ゲーム機の代わりにインターネット越しのサーバーでゲームを動かし、映像と操作だけをやり取りするサービス †2: https://www.ietf.org/archive/id/draft-lcurley-warp-00.html

結論 WebTransportは... ● リアルタイム通信をより良くしてくれる...かも ● Safariが対応していないなど課題はある