WebRTC SFU 開発者からみた WebTrasnport の現状
定期的にアップデートしていきます
自分の立ち位置
- 商用 WebRTC SFU のプロトコルスタック実装経験あり
- QUIC プロトコルタック実装経験あり
WebTransport への理解
- WebTransport over HTTP/3 の知識はあり
- WebTransport over HTTP/2 の知識はあり
結論
WebTrasnport を WebRTC 的な利用をする視点からの結論です。
WebTransport は WebRTC のような MediaChannel / DataChannel からみたら圧倒的に仕組みが足りてないので、WebTransport の上にそれらの仕組みを作り込める必要がある。これは Zoom が DataChannel 上に様々な仕組みを作り上げるのと同じことをやる必要がある。
そのため、現時点で WebTransport を学ぶ必要は @flano_yuki のようなプロトコル大好きっ子、またはリアルタイム系のクライアント、サーバ開発者以外は学ぶ必要がない。WebTransport が全てのブラウザで対応してからで十分。
WebTrasnport は WebSocket の QUIC 版という認識で良い。 QUIC はストリーム単位でしか再送の仕組みはないし、QUIC DATAGRAMフレームについてはそれすらない。
いつかでる Real World HTTP 第3版で HTTP/3 や WebTransport について書いてくれるだろうからそれを待てば十分。
メモ
Twitch が WebTransport を実験する話
Twitch の WebTransport 例は WebRTC 的な利用をする場合は参考にしてはならない。
QUIC のカスタム実装を行っており、さらには WebTransport を配信と視聴に採用しようとしている話。
RTMP -> Twitch -> HLS
WebTransport -> Twitch -> WebTransport
ただフォールバック先を配信は RTMP 、視聴は HLS と捉えているため WebTransport のプロトコルを採用するがフォールバックは自分たちで頑張るという感じ。
WebRTC のような利用の場合はフォールバックはとても重要、 TURN を一切意識しなくて良い WebRTC は本当によくできている。
WebTransport の立ち位置
WebTransport over HTTP/3 で行く事が決まっため、 WebSocket over HTTP/2 の HTTP/3 版なんだな、くらいでいい。
フォールバック先は WebTransport over HTTP/2 の可能性が高そう
draft-kinnear-webtransport-http2-02 - WebTransport using HTTP/2
フォールバックは「失敗する」「自分でがんばる(WebSocket など)」「WebTransport oveer HTTP/2」の 3 択にはなっている。