WebRTC over QUIC

とりあえず、Google の記事を読んでください。

WebRTC over QUIC は WebRTC DataChannel を QUIC で置き換えた実装になっています。さらに RTCPeerConnection や SDP といったものが消え去った API になっています。

RTCQuicTransport を使って QUIC の接続を確立します。ただ P2P なので ICE が必要なので RTCIceTransport が必要になります。

そのため Candidate を取得して、シグナリング経由でお互い投げつける。SDP が出てこないだけでこの辺は WebRTC と一緒ですね。

ただ、ちょっと違うのが QUIC 側が PSK を交換する前提になっています。これはおそらくですが 0-RTT を利用するためでしょう。なので Listen 側に PSK をシグナリングで渡しています。つまり「再接続状態」をシグナリングを利用して実現し、0-RTT をいきなり利用可能にしています。

ちなみに IceParameters は普通に STUN パケットによる、UDP ホールパンチング用です。中身は username/password です。


QUIC が start して connect/listen で接続が確立したらあとは、createStream を呼び出す必要があります。

QUIC ではストリームを動的に生成できます。それをコントロールする必要があります。とはいえ DataChannel でも同じような感じだったので気にならないと思います。

Stream を作ったらあとは送受信ですが送信は write で、read は onquicstream で上がってきた RTCQuicStream に waitForReadable や waitForWriteBufferedAmountBelow があるのでそれを使ってうまいことやっていく必要があります。

ここでお気付きかと思いますが QUIC と DataChannel は大きな差があります。DataChannel はリトライ回数やリトライ時間、順序などがいくつか決められたのから選べばよかったのですが、QUIC の場合はそうも行きません。

まず順番保証がしたかったら 1 ストリームしか使ってはいけません。複数ストリームを利用した場合は順番保証はされません。動的にガンガンストリームを作って送り続けるというのが問題ないため、順番保証をきにしないのであればサーバが許す限りストリームを作って送ることができます。

パケロスについても DataChannel よりめんどくさいです。ガンガン送ってあとはストリームを閉じてしまえばいいです。再送はストリーム単位で発生するためです。

この辺は DataChannel よりは不便ですが「自分でコントロールできるようになる」というのが QUIC の強みなので、そのあたりはバッファリング機能として提供されています。使うだけでもいろいろノウハウが必要なのがやっかいです。


今回の RTCQuicTransport は WebRTC DataChannel をより自分で好きにコントロールできる仕組みと考えるのが無難です。もともと QUIC がその方向性なので特に違和感はありません。

かなりうまく QUIC に Web API をつけたというのが自分の印象です。RTCQuicTransport は WebRTC というよりかは QUIC をブラウザの API からP2P で利用できるようにした仕組みと考えて良いです。


これに Media を乗せるにはより細かいコントロールが必要になります。例えば再送制御や輻輳制御も MediaChannel ではやっていました。どこまで QUIC がやるのかはわかりませんが、WebRTC NV では低レイヤーの API を提供するのが目的と Google がプレゼンで言っていたので、もしかすると PLI を送れたり Generic Nack を送れたりする Web API が登場するかもしれません。

まずは DataChannel が大好きだった人は RTCQuicTransport を使ってみるといいかもしれません。

おまけ

Chrome Canary M74 での動作サンプル