WebRTC がリリースされて 10 年以上がたちましたが WebRTC DataChannel を使いこなしている人はほとんどいないと思います。あったとしても多くはファイル転送で大きいファイルを P2P で提供するというものです。
自分も今まではそれくらいしか使い道はないだろうと思っていましたが、WebRTC SFU に DataChannel を積んでみたところ、相当便利な機能だという事がわかりました。
WebRTC SFU と DataChannel の可能性について開発者視点から雑に書いていこうと思います。
まとめ
- DataChannel の性能は悪くない
- WebRTC SFU との相性は悪くない
- 枯れているため、多くのプラットフォームで動く
- 枯れているため、今すぐ誰でも使い始められる
WebRTC DataChannel とは
WebRTC DataChannel は UDP ベースのプロトコルです。MediaChannel のように音声や映像に特化したプロトコルではなく、バイナリデータ（文字列を含む）であればなんでも扱えます。
さらに QUIC のように 1 接続で複数のストリームに分けることができ、ストリーム単位での再送回数や再送時間、さらに順番保証を指定することができます。
なんか万能なプロトコルのように聞こえますが、P2P 以外ではほとんど使われません。WebRTC SFU で DataChannel 対応を売りにしているのはほとんどないと思います。これは実際に開発してみるとなぜ WebRTC SFU + DataChannel が存在しないのかよくわかります。
DataChannel の仕組みが P2P に寄せすぎている
一番の問題は DataChannel は P2P つまり 1:1 での利用を想定している仕組みになっているということです。
どちらのクライアントからも自由にストリームを張ることができ、双方向でやりとりできます。つまりアタックし放題です。P2P であればブラウザ閉じれば終わりですが、WebRTC SFU となるとそうはいきません。
つまり DataChannel はサーバで制御するように考えられていません。そのため、WebRTC SFU で独自の制御を追加する必要があります。
サーバ向け DataChannel には制限が必要
今回 WebRTC SFU に DataChannel を追加するに当たって独自の機能を追加しました。
createDataChannel をクライアントからできないようにした
クライアントに好き勝手にされると大変困るので、クライアント側から createDataChannel を行えないようにしました。実装的には DataChannel の WebRTC Data Channel Establishment Protocol を送ってきても無視または切断するようにしています。
これでクライアントが勝手に設定できるようになっていません。
Label 毎に片方向か双方向かをサーバ側から指定できるようにした
これは別途実装している QUIC を参考にしました。片方向と定義している DataChannel に変なパケットを送ってきた時点で無視または切断するように実装しています。
これでクライアントが勝手にパケットを送ってくる事ができません。
DataChanel の定義は固定＋認証ありきを検討している
この機能はまだ未実装なのですが、DataChanel の Label は WebRTC SFU が利用する固定のもの、あとはシグナリング接続時で以下のように宣言して利用するという方向を検討しています。
{
"type": "connect",
"channel": "sora",
"data_channels": [
{
"label": "spam",
"ordered": true,
"max_packet_life_time": 3000
}
]
}さらにこれは認証時にどんな label を生成しようとしているかのチェックも可能になります。認証成功時にも払い出せるようにします。
PubSub の仕様は完全に独自になる
DataChannel には PubSub の概念はないため、完全独自実装で独自の仕組みが必要になります。これは MQTT をシンプルにした topic による publish/subscribe の仕組みを検討しています。
DataChannels を定義するときにこの Label=Topic として、この Label の DataChannel を張っている人にだけおくるという仕組みです。
上であれば spam という Label を張っているクライアントにメッセージの送受信が可能になります。
もちろんこれらは WebRTC SFU 的なルームの中でだけ利用可能になります。
DataChannel の強み
DataChannel の強みもあまり理解されていません。実際自分もほとんど理解していませんでした。
フォールバックを考えなくていい
DataChannel は WebRTC の一つのため UDP が通らないところでも TURN を利用してフォールバックするのが簡単です。デフォルトでフォールバックが入っている仕組みです。
QUIC や WebTransport は専用のフォールバックの仕組みが必要になります。
多くの環境で安定して動作する
DataChannel を WebRTC SFU に組み込むと便利そうというのは伝わったと思うのですが、ではなぜ DataChannel を使うのでしょうか？ QUIC や WebTransport ではだめなのでしょうか。
DataChannel はほぼすべてのブラウザが標準で対応しているというのが一番大きいです。さらに Unity や iOS や Android アプリとして組み込むときも libwebrtc があるため、WebTransport や QUIC より簡単に組み込むことができます。
クライアント側は libwebrtc のおかげで情報がそろいにそろっているという状況です。
複数ストリームを実現可能
DataChannel は前述したとおり QUIC のように 1 つの接続で複数のストリーム (Label) を持つことができます。
さらにそのストリーム毎に再送回数や再送時間を指定することが可能になっています。
スループットは TCP とほとんど変わらない
WebRTC DataChannel を Go で実装した Pion の Issue に SCTP が TCP とほぼ変わらないスループットが出せるという情報が出ていました。
https://github.com/pion/sctp/issues/62
その上で不安定な回線ではストリーム毎にしか HoL Blocking は発生しませんし、再送設定を行わなければ HoL Blocking すら発生しません。
つまり DataChannel は TCP に近いが出せて、QUIC と QUIC Datagram 拡張に近い機能を併せ持っていることになります。
MediaChannel が付いてくる
DataChannel を使うと音声や映像を MediaChannel で送るということもできます。おまけで付いてくる割にずいぶん便利すぎる機能です。
ただし DataChannel と MediaChannel でのリップシンクはめんどくさいので、WebRTC Encoded Transform を検討しましょう。
DataChannel は枯れている
DataChannel に利用されている SCTP や DTLS は十分利用されてきています。また WebRTC がすでに 10 年経過した技術です。多くの環境で動作してきています。
今後の DataChannel
ブラウザでは単独で QUIC を利用することができないため WebTransport が出てくるまでは DataChannel を利用することが良さそうです。
WebTransport サーバは今後出てくると思いますが、クライアントはいろいろな中で選んでいく必要がありそうです。その点 DataChannel は基本的に libwebrtc か Pion くらいです。
ブラウザ外で使う場合も libwebrtc を載せた SDK は多くありますので、選択肢としては十分でしょう。
WebTransport が広まったとしても DataChannel がすぐに廃止されるということはないと思います。そのため WebRTC SFU で DataChannel を使う選択肢は悪い選択しではないと思います。
宣伝
時雨堂では WebRTC SFU Sora に DataChannel の機能を追加していっています。最終的には DataChannel を利用したリアルタイムメッセージングを実現する予定です。音声と映像以外にメッセージングにも強い製品を目指していきます。
