本セッションの登壇者
セッション動画
よろしくお願いします。僕はHTTP3の話はしなくて、WebはWebでもWebRTCという、映像ストリーム的なところでQUICがどういうふうに活用されるのかという話をしたいと思います。LTが8分なのに70枚ぐらいスライド作っちゃったので、ぱっぱぱっぱと早口でLTをやっていきますので、よろしくお願いします。
自己紹介はこんなかんじです。
今日お伝えしたいことはタイトルそのままなんですが、僕はWebRTCを10年ぐらいやってるんですが、そういうWebRTCをずっとやってる人がQUIC Datagramに注目するワケ、それはUDP alternativeだからだよというのが僕なりの答えなんですが、そこらへんのところをお話ししたいと思います。
WebRTCについておさらいと最近のトレンド「Premium LIVE」
まずWebRTCって何でしょうかというところから整理したいんですけれども、答えはビデオ会議用のAPIです。
最近、WebRTC系でどんなトレンドがあるのかというと、「Not onlyビデオ会議」という感じです。
「Not onlyって何ですか」というのは、僕の個人的見解なんですけども、Premium Liveというのがけっこうおもしろくてアツいと思ってます。いろいろと動きがあります。
具体的には、たとえばこれはMPEG-DASHという、今、皆さんがYouTubeライブでご覧いただいているプロトコルに近いやつなんですけれども、HTTPを使ったライブストリーミングです。これの標準化をやってるところがMPEG-DASHというフォーラムなんですが、そこでWebRTCのストリーミングもやっていきましょう、標準化しましょうという話が出ています。
これの発端が何なのかというと、この「Premium Streaming」と書いてありますが、Premium Liveですね、これが発端になっています。
では「Premium Liveって何ですか」というと、双方向的なライブ配信です。ただ見るだけじゃなくて、本当に双方向に視聴者が参加するような、そういうライブ配信のプログラムのことです。
これは2、3年前のデータなんですが、欧米ではすでにけっこう使われていて、いろんな番組プログラムでかなりのスケーラビリティで使われていて、ビジネスとしてすでに確立しているという感じです。
それでは日本は…という話なんですが、ぶっちゃけちょっと遅れているのが現実です。僕はこのSmart vLiveというライブ配信プラットフォームの開発マネージャをやっていて、去年ぐらいにリリースしました。
こんな感じのユースケースをやってます。
日本でも(Premium Liveのビジネスを)やってるよ！という紹介でした。
超低遅延を実現するプロトコルの最適解
Premium Liveは技術的に何がポイントかというと、いろいろあるのですが、ひとつは超低遅延が大きなキーワードです。
では超低遅延とは何かという話なんですが、これです。これはライブストリーミングのプロトコルに対して遅延がどうなるかを表している図なんですが、今日のYouTubeライブはこの「HLS/DASH CMAF with LLC」でやっていて、頑張っても5、6秒から、見る人によっては最大で1分ぐらい遅延がある、つまりけっこうばらつきがあるのが真ん中より左側のプロトコルです。一方、WebRTCをライブストリーミングに使うと、遅延を1秒以内にできます。リアルタイムなどのインタラクティブなライブにはWebRTCがいいよという話です。
このような遅延がどうして起こるかというと、細かく言うとすごく細かいんですが、ざっくり言うとTCPは遅い＆UDPは速いという話です。
なので「UDPベースの低遅延のプロトコル＝WebRTCでライブ」というパターンがけっこう多いのですが、正直、これがベストなのか?と思うところはあります。
そもそもWebRTCって何でしたっけ?というと、冒頭でも言ったようにビデオ会議用のAPIです。ビデオ会議用のAPIというのはメディアから見たときにどういう要求になるかというと、オーディオについてはもう、認識できればいいというレベルです。そしてビデオに関してはカタカタでもいい、紙芝居でもいい、もう音が聞こえればそれでいいというのが基本的にはビデオ会議の映像に対する要件になっています。
そういうものがライブに対して適用できるのか、マッチするのかというと、想像していただきたいんですけど、こんな感じのライブをカッタカタの紙芝居でやったときに人は金を払うのかという話ですね。答えはNoだと思います。
実際、僕がやっているSmart vLiveというサービスでは、WebRTCで配信しているんですが、素のまんまのWebRTCでやってしまうとかなり残念なことになります。ラボなどであれば別にいいのですが、実際にサービス提供となるとかなりキツいケースが多いです。
なので、これは企業秘密なので詳細は申し上げられないですが、WebRTC上でかなりチューニングして、商用品質に耐えるようなクオリティで提供するという作業をやっています。かなりガチでやってます。Hackですね。
しかし、こういうHackみたいなものが未来永劫、リアルタイムWebでずっと動き続けるのかというと、やっぱりそれは違うだろうという気がします。Hackせずに普通にコードを書きたい、やりたいコードをちゃんと書きたい、かつてHTML5がそうであったように…ですね。
QUICは”better UDP”となりうるか
そうなってくるとやっぱりWebRTCに代わる新しいプロトコル、UDPで動くものが欲しくなってきます。
そこに対してQUICにすごく期待しています。なぜならWebの上で動くbetter UDPだからというのが僕の考えです。
Better UDPが何かについてはいろんな観点がありますが、僕の中で重要なもののひとつは、**Congestion Control(輻輳制御)**だと思っています。
Congestion Controlというのは、他の通信と譲り合うことで、UDPにはこれがないんです。
たとえばHTTPでいろいろとやってるときは、インターネットの通信をみんなフェアに分けあって使います。
でもそこにUDPがどかんと流れてくると、譲りあうという概念がないので他を押しのけて流れてしまうんですね。これは大問題です。
QUIC Datagramについては、better UDPなんですけども、このCongestion Controlが入っているのでみんなとちゃんと分け合うことをやります。混雑整理をしてくれるという感じです。
具体的にはRFC 8836でこのあたりのことを「Congestion Control Requirements for Interactive Real-Time Media」と説明しています。
これはアブストラクトを抜き出したものですが、重要なところだけ引用すると、インターネットにおいてCongestion Controlはneeded、つまり「必要」だとしています。インタラクティブな要求に対して、Webページのようなものとは違って、低遅延であったり、”semi-reliable data delivery”、これは映像ストリーミングではすごく重要なキーワードなんですが、こういうものに関してCongestion Controlは「とくに重要」だといっています。
このCongestion Controlに関するQUICについては、RFC 9002にまとまっています。そのCongestion Controlに基づいて、QUICはHTTP3ではbetter TCPとして動いてるし、QUIC Datagramではbetter UDPとして動いています。
RFC 9221では、こんな感じで進んでいます。
僕の期待なんですが、こういうライブ配信みたいなユースケースのときに、サーバからブラウザまでがQUICになってほしいなという感じです。
もうちょっと具体的に言うと、サーバからクライアントに映像ストリーミングを流すときに、メディアサーバのプロセスからQUICで送信してWasmで受けるというのがポイントです。ここでうまいことやって、Web Codecsでデコードして映像を表示する感じですね。こんな感じのパイプラインです。ここはNo Hackです。Wasmで書きたいものを書けばいいという世界です。
まとめ − そう、QUICならね
最後、まとめです。いろいろなリアルタイム通信のアプリをWebに作りたい − そんなときにはHackせずにWasmで普通にコードが書ける そう、QUICならね!
ということで、おしまいです。どうもありがとうございました。
