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

by DeNA_Tech

Slide 1

Slide 1 text

TechTalk ビデオ通話システムの謎を解け！佐藤琢斗

Slide 2

Slide 2 text

2 突然ですが

Slide 3

Slide 3 text

3 ビデオ通話サービスって便利ですよね

Slide 4

Slide 4 text

4 生活に欠かせないツールとなったビデオ通話サービス

Slide 5

Slide 5 text

5 これらを実現するビデオ通話システムどういう背景・技術で成り立っているか気になりませんか？

Slide 6

Slide 6 text

このTechTalkを聴くと身に付けられる知識 • ビデオ通話システムの裏側をなんとなく想像できる最低限の知識 • 仕組みの詳細を話すのはつまらない • （完全理解してない） • なぜその技術が使われているのか？の背景知識 • 身近な技術から、ボトムアップに考えていく 6

Slide 7

Slide 7 text

7 やっていきます

Slide 8

Slide 8 text

そもそも、ビデオ通話システムを作るための要件って？ • 双方向通信であること • 一方向に語りかけるのは通話と呼ばないよね • リアルタイム性があること • 自分・相手の声が届くのに数十秒かかっていたら、通話にならない • ライブ配信は一方向・ある程度の遅延が許されるサービス • ビデオ通話システムとは根本的に違う 8

Slide 9

Slide 9 text

9 身近な技術から考えてみる

Slide 10

Slide 10 text

10 みんな大好き

Slide 11

Slide 11 text

11 みんな大好き HTTP！

Slide 12

Slide 12 text

HTTP • クライアントからサーバに問い合わせることでコンテンツを取得する通信手段 • 一方向だ... • 双方向を実現する手法もある！ • ポーリング • 定期的にリクエストし、擬似的に双方向通信 • リアルタイム性△ • 通信のたびにコネクション張る。オーバーヘッド大 • WebSocket • コネクション張りっぱなしにして、ソケット通信 • 双方向！リアルタイム性◯ • では、WebSocketでよさそう…？ 12 ポーリング WebSocket

Slide 13

Slide 13 text

WebSocketに想いを馳せる • UpgradeメッセージでHTTPを拡張 • 最初のリクエストで確立したコネクションを繋ぎっぱなしにする • そのコネクション内で双方向にメッセージを送受信 • ベースがHTTP、つまりTCP • あれ、TCPで良いんだっけ...？ 13 WebSocket

Slide 14

Slide 14 text

え？TCP? • TCPは信頼性の高い通信を実現するためのプロトコル • 第4層 - トランスポート層 • HTTPより下 • HOGEと送ったら必ずHOGEと伝わる • HGEOにもHGEにもならない • 順序を保証したり、足りないデータを再送する仕組みがある • パケットを正確に受信できるまで、次のパケットを待つ • これビデオ通話に必要でしょうか？ 14 第7層アプリケーション層第6層プレゼンテーション層第5層セッション層第4層トランスポート層第3層ネットワーク層第2層データリンク層第1層物理層

Slide 15

Slide 15 text

音声・映像は、多少乱れても問題ない • 多少データが欠損しても、情報は伝わる • 通話中、ちょっと音声・画質荒くても大きな問題はないはず • つまり、正確に全てのパケットを受信する必要はない • むしろ、厳密に順序の保証・再送していると遅延の原因に • HOL Blocking • そこでUDP • 順序保証も再送も、何もしない • 送って終わりの方法 15

Slide 16

Slide 16 text

ここまでまとめると... • ビデオ通話システムに必要なのは • 双方向通信 • リアルタイム性 • HTTPで考えてみる • WebSocketなら双方向・リアルタイムで通信できそう、良さそう • しかし、TCP上のプロトコルであるため大容量を高速に配信するのは辛い • UDPで双方向・リアルタイム通信できる方法さえあれば... 16

Slide 17

Slide 17 text

17 あります

Slide 18

Slide 18 text

18 ありますそれが

Slide 19

Slide 19 text

19 ありますそれが WebRTC

Slide 20

Slide 20 text

WebRTC • 双方向に、リアルタイムで、UDPで通信する技術 • 色々な機能が詰め込まれている技術 • 音声・映像の圧縮 • マイク・カメラ等のデバイス認識・選択 • UDP上で独自の再送制御など • P2P（１対１）で通信 • クライアント同士でコネクションを張る • どうやってクライアント同士繋ぐのか？ 20

Slide 21

Slide 21 text

WebRTC コネクション確立まで • まずは、通信したい相手の情報を知る必要がある • IPアドレスは？ • 音声・映像の形式は？ 21 A B

Slide 22

Slide 22 text

WebRTC コネクション確立まで • まずは、通信したい相手の情報を知る必要がある • IPアドレスは？ • 音声・映像の形式は？ • これらの情報（SDP）を交換するためのサーバが必要 • シグナリングサーバ 22 A B シグナリングサーバ

Slide 23

Slide 23 text

WebRTC コネクション確立まで • まずは、通信したい相手の情報を知る必要がある • IPアドレスは？ • 音声・映像の形式は？等 • これらの情報を交換するためのサーバが必要 • シグナリングサーバ • 交換後、コネクション確立 23 A B シグナリングサーバ

Slide 24

Slide 24 text

シグナリングサーバ、実際に作ってみた • singo • tockn/singo: Simple WebRTC Signaling Server written in Go • signal (信号) + Go = singo • P2Pフルメッシュで複数人とコネクション確立できるシグナリングサーバ • Starしてね⭐ 24

Slide 25

Slide 25 text

これでZoom作れんの？ • 結論から言うと、無理 • 繋がらない問題 • シグナリングサーバだけでは繋がらない場合がある • シンメトリックNATなど • P2Pフルメッシュ辛い • クライアント側が人数分のコネクションを持つことになる • 全員へ個別に音声・映像を送信 • 人が増えるたびに処理が重くなる... 25

Slide 26

Slide 26 text

接続数増加の対応 • P2Pフルメッシュの代替案として • MCU • SFU • これら二つがある 26

Slide 27

Slide 27 text

MCU (Multipoint Control Unit) • サーバで映像を合成しちゃう技術 • 複数人相手でも、クライアントはコネクション一つで済む • デメリット • サーバの負荷大 • リアルタイム映像合成 • クライアント側で映像を弄れない • 特定の映像を大画面にしたりとか 27 MCUサーバ 4つの映像を1つの映像に合成

Slide 28

Slide 28 text

SFU (Selective Forwarding Unit) • サーバが映像を転送する技術 • 複数人相手でも、クライアントはコネクション一つにできる • 一つのコネクション内に複数の映像を入れる • マルチストリーム • デメリット • 仕組み・実装が複雑 • MCUよりはクライアントに負荷 28 SFUサーバ一つのコネクションに複数の映像を転送（マルチストリーム）

Slide 29

Slide 29 text

29 はい。

Slide 30

Slide 30 text

30 HTTP TCP・UDP WebRTC MCU・SFU

Slide 31

Slide 31 text

（再掲）このTechTalkを聴くと身に付けられる知識 • ビデオ通話システムの裏側をなんとなく想像できる最低限の知識 • 仕組みの詳細を話すのはつまらない • （完全理解してない） • なぜその技術が使われているのか？の背景知識 • 身近な技術から、ボトムアップに考えていく 31

Slide 32

Slide 32 text

32 Thank you!