関連記事
- WebTransport over QUICのサンプルサーバを試してみる - ASnoKaze blog
- WebTransport over HTTP/2 の仕様について - ASnoKaze blog
- WebTransport over QUIC について - ASnoKaze blog
WebTransportという新しい双方向通信フレームワークの議論が始まっている。
GoogleのPeter Thatcher氏らによって、W3C WICGにプロポーザルが投げられています。
discourse.wicg.io
WebTransportは、WebSocketのようなAPIをもち、QUICやHTTP/3上で多重化されたストリームを利用し、ヘッドオブラインブロックのない通信を行えるようにするというのがモチベーションのようです。(実際に使用する"トランスポート"はプラガブルな設計になっている)
また、TCPとは異なり、パケロスしても再送を行わないPartial reliabilityなども使えるようになる。そのようなAPIも改めて定められる。
その他にもコネクションのマイグレーションをサポートしているトランスポートであればIPが変わってもコネクションを維持できる。
WEBRTC-QUICで同様のことは可能だが、ICEを必要とせずクライアント・サーバの通信ユースケースに絞っている。
QUICについては以前簡単に書いたとおり
asnokaze.hatenablog.com
仕様
API
「WebTransport」として、WebRTC-QUICのリポジトリ下に、APIに関する仕様が書かれている。
その中で書かれている例の一つをとりあげると、再送を行わないメッセージの送信は以下のようになっている。
let transport = getTransport(); let messages = getMessages(); for (msg in messages) { transport.createSendStream({disableRetransmissions: true}).write({data: msg, finished: true}); }
プロトコル
プロトコルの仕様としてすでに下記の3つのドキュメントがIETFに提出されている。
1つ目は概要であり、WebTransportのトランスポートが持つ機能要件について書かれている。
例えば、データ通信としてストリーム方式・データグラム方式を持つ(パケットのデータ境界をアプリケーション側で維持するか)などである。
その他にも追加の機能として、トランスポートのストリームの独立性、Partial reliability、コネクションプール (1つのコネクションを再利用し輻輳制御を行える)、Connection mobility (IPが変わってもコネクションが維持可能)といった項目だしを行っている。
2つ目と3つ目はそれぞれ、WebTransportをHTTP/3、QUIC上で行えるようにする仕様を定義している。特にHTTP/3ではサーバからストリームを開始できるうようにWebTransport用のストリームを定義している他、追加のフレームも定義している。
(詳細は機会があればまた今度)
リンク
vせんせいも、WebTransportついて書かれております
medium.com