WebRTC QUIC Client/Server が WebTransport として再出発したようなのでまとめておく。
一般的な説明についてはいかが詳しいので以下を読むのをおすすめしたい。
WebTransport はもともと WebRTC QUIC Client/Server という P2P 目的ではない QUIC の利用方法を検討していたのから派生した仕組みになる。
そもそも WebRTC QUIC P2P は NAT 越という問題があることから ICE が必須になる。RTCIceTransport というのがあり、それを RTCQuicTransport に食べさせるという仕組み。
WebRTC と書いて入るが QUIC を P2P で使うための仕組みと考えて良い。
そこからそもそも P2P ではなく Client/Server で QUIC を直接使う仕組みとして用意されていたのが WebRTC QUIC Client/Server だった。この機能自体は実装すらされていなかった。
P2P の方は Chrome の Origin Trial として RTCQuicTransport としてすでに利用可能だ。
HoL Blocking しない WebSocket over TLS がほしかったので QUIC 使って WebSocket を用意してみたという以上の話はなさそうというのが正直な印象。WebRTC DataChannel はまぁ一般的じゃないからそれを Client/Server にするくらいなら QUIC にすべきだという話でもあるようだ。
ストリーミングやゲームに利用したいという方針のようで、確かに実際 WebSocket はゲームにも使われるくらいブラウザの外からでも利用されるようになった。ただ再送しないという選択肢が WebSocket では取れないこともあり、WebTransport の再送ありなしの選択肢は良さそうだ。
WebTransport の課題は UDP が通らないところをどうするかというところだろうか。実際 WebRTC をやっていると TCP/TLS のみの環境によくである。この辺については WebSocket にフェールオーバするのかとか色々楽しそうではある。
自分個人としては WebTransport はとても期待している。特にネットワークの切り替わりで切断が発生しないというのは本当に良い。アドレスマイグレーションへの対応だけでも使う価値がある。
QUIC や HTTP/3 の知識が前提とはなるが、追いかけてみるのは良い技術だと思う。
追いかける量がはんぱなくなるので、仕事以外ではかなり辛くなると思うのが … 。
