WebSocket から WebRTC DataChannel へのマイグレーション (1)
自社の WebRTC SFU にあまり見ない機能をいろいろ作り込んでるので記録して残しておく。
モチベーション
自社 WebRTC SFU はシグナリングなどでプッシュでメッセージを送るための仕組みに WebSocket を張っている。ただ WebRTC が基本的に over UDP なため、WebSocket の方が詰まって応答しなくなるという問題が存在する。
WebSocket を切断して再接続してもいいが、あまり良い解決方法に思えなかった。そこで WebRTC DataChannel を活用することにした。
- アプリ利用者は一切何も気づけないようにしたい
- アプリ開発者は SDK をアップデートするだけで利用できるようにしたい
- プッシュでメッセージを受信するのに WebRTC DataChannel を利用したい
- WebRTC が確立するまでは WebSocket を使って楽にやりとりをしたい
- WebRTC が確立した後は WebSocket から WebRTC DataChannel へマイグレーションしたい
- WebRTC DataChannel は複数チャネルを用意できるので用途によってチャネルをわけたい
- メッセージングに力を入れていきたい
- E2EE メッセージを DataChannel に載せたい
- DataChannel か WebTransport を選択可能にしたい
- Wifi <-> LTE で切れなくしたい
DataChannel は over TURN 上で動くというメリットが実はとても大きい。つまり UDP が通らなくても TURN がうまいことフォールバックしてくれる。フォールバックを意識しなくていいのはとても大きい。
SCTP 自前実装
WebRTC DataChannel は SCTP (DataChannel 拡張) over DTLS over UDP 実装となるが、基本的に SCTP を利用する場合は usrsctp ライブラリを利用するのが最短距離。
ただし、自社製品では NIF (C 拡張) を利用せず全て Erlang/OTP でコードを書いている。つまり SCTP を自前実装する必要がある。
DataChannel 実装現状
- SCTP で順番保証（再送含む）は実装した
- 商用レベルに持って行くにはテストや検証は必要
- DataChannel で複数チャネルを作る仕組みは実装した
意図的な制限
そもそも DataChannel は使いどころがとても難しい。順番保証いらないとか再送が一定回数とかにしてしまうとアプリケーション側の課題が多くなる。そこでまずは順番保証あり、再送ありで限定して実装してみることにした。
さらにクライアント側から DataChannel を作れないように制限した。つまり WebRTC SFU 側が定義した DataChannel 以外は使えない。
感想
実装して思ったが SCTP はとにかくめんどくさい、本当にめんどくさい。皆 QUIC (WebTransport) に行きたいわけだ。
もちろん DataChannel を商用で安定的に動かすには相当なテストが必要で、これから頑張っていく。あまり活用できていなかったプロパティテストも導入していくつもりだ。
WebRTC DataChannel over TURN は今後 5 年は残るだろう。実際に Google Duo や Google Meet は WebSocket を使わず DataChannel をうまく活用している。
2021 年はメッセージングに力を入れていきたいと思っている。WebRTC SFU をメッセージングルーターとして使えるようにしたい。そのためには DataChannel (WebTransport) は必須だろう。
今後はマイグレーション機能の設計と実装について書いていく。商用で利用可能になるまで続けていくつもり。
