ビデオ通話システムの謎を解け！

リモートワークが一般的になり爆発的な普及を見せたビデオ通話サービス。今ではリモートワークだけでなく、リモート飲み会など生活にも溶け込むものとなりました。では、そんなビデオ通話サービスの裏側では一体どのような技術が使われているのでしょうか。また、他の技術では何が問題となるのでしょうか。

そこで今回、HTTPという身近な技術からメリット・デメリットを考えていき、なぜWebRTCが使われているのか？を段階的に紹介させていただきました。資料の後半ではWebRTCでは何が問題になるのか、それを解決するための手法はどのようなものがあるのかについても説明します

Transcript

1. TechTalk ビデオ通話システムの謎を解け！ 佐藤琢斗
2. 2 突然ですが
3. 3 ビデオ通話サービスって 便利ですよね
4. 4 生活に欠かせないツールとなった ビデオ通話サービス
5. 5 これらを実現するビデオ通話システム どういう背景・技術で成り立っているか 気になりませんか？
6. このTechTalkを聴くと身に付けられる知識 • ビデオ通話システムの裏側をなんとなく想像できる最低限の知識 • 仕組みの詳細を話すのはつまらない • （完全理解してない） • なぜその技術が使われているのか？の背景知識 • 身近な技術から、ボトムアップに考えていく 6
7. 7 やっていきます
8. そもそも、ビデオ通話システムを作るための要件って？ • 双方向通信であること • 一方向に語りかけるのは通話と呼ばないよね • リアルタイム性があること • 自分・相手の声が届くのに数十秒かかっていたら、通話にならない • ライブ配信は一方向・ある程度の遅延が許されるサービス • ビデオ通話システムとは根本的に違う 8
9. 9 身近な技術から考えてみる
10. 10 みんな大好き
11. 11 みんな大好き HTTP！
12. HTTP • クライアントからサーバに問い合わせることでコンテンツを取得する通信手段 • 一方向だ... • 双方向を実現する手法もある！ • ポーリング • 定期的にリクエストし、擬似的に双方向通信 • リアルタイム性△ • 通信のたびにコネクション張る。オーバーヘッド大 • WebSocket • コネクション張りっぱなしにして、ソケット通信 • 双方向！リアルタイム性◯ • では、WebSocketでよさそう…？ 12 ポーリング WebSocket
13. WebSocketに想いを馳せる • UpgradeメッセージでHTTPを拡張 • 最初のリクエストで確立したコネクションを繋ぎっぱなしにする • そのコネクション内で双方向にメッセージを送受信 • ベースがHTTP、つまりTCP • あれ、TCPで良いんだっけ...？ 13 WebSocket
14. え？TCP? • TCPは信頼性の高い通信を実現するためのプロトコル • 第4層 - トランスポート層 • HTTPより下 • HOGEと送ったら必ずHOGEと伝わる • HGEOにもHGEにもならない • 順序を保証したり、足りないデータを再送する仕組みがある • パケットを正確に受信できるまで、次のパケットを待つ • これビデオ通話に必要でしょうか？ 14 第7層 アプリケーション層 第6層 プレゼンテーション層 第5層 セッション層 第4層 トランスポート層 第3層 ネットワーク層 第2層 データリンク層 第1層 物理層
15. 音声・映像は、多少乱れても問題ない • 多少データが欠損しても、情報は伝わる • 通話中、ちょっと音声・画質荒くても大きな問題はないはず • つまり、正確に全てのパケットを受信する必要はない • むしろ、厳密に順序の保証・再送していると遅延の原因に • HOL Blocking • そこでUDP • 順序保証も再送も、何もしない • 送って終わりの方法 15
16. ここまでまとめると... • ビデオ通話システムに必要なのは • 双方向通信 • リアルタイム性 • HTTPで考えてみる • WebSocketなら双方向・リアルタイムで通信できそう、良さそう • しかし、TCP上のプロトコルであるため大容量を高速に配信するのは辛い • UDPで双方向・リアルタイム通信できる方法さえあれば... 16
17. 17 あります
18. 18 あります それが
19. 19 あります それが WebRTC
20. WebRTC • 双方向に、リアルタイムで、UDPで通信する技術 • 色々な機能が詰め込まれている技術 • 音声・映像の圧縮 • マイク・カメラ等のデバイス認識・選択 • UDP上で独自の再送制御など • P2P（１対１）で通信 • クライアント同士でコネクションを張る • どうやってクライアント同士繋ぐのか？ 20
21. WebRTC コネクション確立まで • まずは、通信したい相手の情報を知る必要がある • IPアドレスは？ • 音声・映像の形式は？ 21 A B
22. WebRTC コネクション確立まで • まずは、通信したい相手の情報を知る必要がある • IPアドレスは？ • 音声・映像の形式は？ • これらの情報（SDP）を交換するためのサーバが必要 • シグナリングサーバ 22 A B シグナリングサーバ
23. WebRTC コネクション確立まで • まずは、通信したい相手の情報を知る必要がある • IPアドレスは？ • 音声・映像の形式は？等 • これらの情報を交換するためのサーバが必要 • シグナリングサーバ • 交換後、コネクション確立 23 A B シグナリングサーバ
24. シグナリングサーバ、実際に作ってみた • singo • tockn/singo: Simple WebRTC Signaling Server written in Go • signal (信号) + Go = singo • P2Pフルメッシュで複数人とコネクション確立できるシグナリングサーバ • Starしてね⭐ 24
25. これでZoom作れんの？ • 結論から言うと、無理 • 繋がらない問題 • シグナリングサーバだけでは繋がらない場合がある • シンメトリックNATなど • P2Pフルメッシュ辛い • クライアント側が人数分のコネクションを持つことになる • 全員へ個別に音声・映像を送信 • 人が増えるたびに処理が重くなる... 25
26. 接続数増加の対応 • P2Pフルメッシュの代替案として • MCU • SFU • これら二つがある 26
27. MCU (Multipoint Control Unit) • サーバで映像を合成しちゃう技術 • 複数人相手でも、クライアントはコネクション一つで済む • デメリット • サーバの負荷大 • リアルタイム映像合成 • クライアント側で映像を弄れない • 特定の映像を大画面にしたりとか 27 MCUサーバ 4つの映像を1つの映像に合成
28. SFU (Selective Forwarding Unit) • サーバが映像を転送する技術 • 複数人相手でも、クライアントはコネクション一つにできる • 一つのコネクション内に複数の映像を入れる • マルチストリーム • デメリット • 仕組み・実装が複雑 • MCUよりはクライアントに負荷 28 SFUサーバ 一つのコネクションに 複数の映像を転送 （マルチストリーム）
29. 29 はい。
30. 30 HTTP TCP・UDP WebRTC MCU・SFU
31. （再掲）このTechTalkを聴くと身に付けられる知識 • ビデオ通話システムの裏側をなんとなく想像できる最低限の知識 • 仕組みの詳細を話すのはつまらない • （完全理解してない） • なぜその技術が使われているのか？の背景知識 • 身近な技術から、ボトムアップに考えていく 31
32. 32 Thank you!