ビデオ通話が繋がる0.2秒で何が起きているのか

MIERUNE BBQ #19 で使用した資料です。

Transcript

1. 2026-07-15 MIERUNE BBQ #19 ビデオ通話が繋がる0.2秒に、何が起きてい るのか? 宮本直幸@MSprzk
2. $ cat profile.service [Unit] Description=Self Introduction [Profile] Name="Miyamoto Naoyuki" Twitter="@Msprzk" Affiliation="北海道情報大学2年" Interest="Network",”Security”,”WebRTC”
3. https://jozankei-time-map.supurazako.com
4. 突然ですが、
5. Google Meet使ったことありますか?
6. Google Meetとは - Googleが提供する無料のオンライン会議・ビデオ通話 ツール - ブラウザから使える - 内部ではWebRTCという技術が使われている (新しいアイコンは見つからず...)
7. ※1: Zoomは独自実装(Not WebRTC)が基本、しかし、Zoom Video SDKにはWebRTC Modeというものもある. (https://developers.zoom.us/docs/video-sdk/web/) WebRTCとは - リアルタイム通信技術 - Zoom※1, Discord, オンラインゲームなどで 使われている - 基本的に、P2P前提※2 ※2: もちろん、P2Pだけではリアルワールドのサービスは成り立たないので、サーバクライアントモデルをできるようにSFUと 呼ばれるものが存在したりする
8. Google Meetで通話が開始される流れを理解する 今日やること
9. 1: ページを開く Google MeetをWebアプリとして読み込む 2: 参加前の準備をする カメラ・マイクを使える状態にする 3: 接続条件を交換する 音声・映像・暗号化の条件を決める 全体の流れ 4: 通れる経路を探す 実際に通信できる道を選ぶ 5: 鍵を作って流す 音声・映像を暗号化して送る 6: 繋がった後 通話品質を測りながら調整し続ける
10. 裏で起きること 1. 名前から接続先を探す 2. 安全な通信経路をつくる 3. Meetの画面と会議情報を読む 1: ページを開く 見えていること ブラウザで meet.google.com を開く
11. $ dig +short meet.google.com (DNSで見る) meet.google.com → ページ表示の実測 142.251.23.102 142.251.23.113 … $ curl -I -L https://meet.google.com HTTP/2 200 - dig: DNSに「この名前のIPは?」と聞く - curl: HTTPSでページにアクセスして応答を見る - HTTP/2 200: Meetのページが返ってきている
12. 裏で起きること - ブラウザがカメラを開く - ブラウザがマイクを開く 2: 参加前に準備する 見えていること - 自分のカメラ映像 - マイク入力レベル getUserMedia = ブラウザにカメラ・マイクを使わせてもらうAPI
13. request カメラ・マイクを使いたい 116.5ms audio request 387.8ms audio track result 1226.7ms video request 2663.4ms video track result Track result 使える音声・映像が返ってくる カメラ・マイクの実測 参加前に、ローカル側の準備は実際に走っている
14. 接続条件を交換する - いきなり音声・映像を送らない! - 通話を始める前に、まず「打ち合わせ」をする - 「この条件なら通話できる」というメモを交換する SDP = 通話を始めるための接続条件メモ 3. 接続条件を交換する
15. SDPは... 音声・映像だけの情報ではない 通話前の打ち合わせメモのようなもの - 音声を使うか - 映像を使うか - 使える圧縮形式 - ネットワーク接続の情報 - 暗号化に必要な情報 m=audio … m=video … m=application … webrtc-datachannel SDP(Session Description Protocol)に入るもの
16. SDPは作るだけでは相手に届かない signaling → SDPを相手に届けるやり取り WebRTCは、SDPの中身は扱うが、SDPの運び方はアプリ側に任せる e.g. - WebSocket - HTTP - MQTT - etc… signaling
17. 接続条件が決まっても、まだ通信できるかは分からない! e.g. - 自宅 Wi-Fi - 大学・会社 - モバイル回線 4. 通れる経路を探す
18. 実際に通る道を探すのがICE ICE → 通れる通信経路を探す仕組み ICE; Interactive Connectivity Establishment 候補A 候補B 候補C どれが通れる？
19. 実測では、使えそうな道が複数見えていた - UDP - TCP - 443 番ポート - Google 側の候補 ここから1つを選ぶ 候補を集めて試す
20. 候補を全部使うわけではない! 疎通確認の結果、実際に使う1本が選ばれる selected path: protocol: UDP round trip time: about 24ms 選ばれた経路
21. そのまま音声・映像を流すわけではない! 暗号化をする 5. 鍵を作って流す ICE 通る経路を決める DTLS 相手確認と鍵交換 SRTP 音声・映像を暗号化
22. DTLS: Datagram Transport Layer Security UDP上で相手確認と鍵交換をする SRTP: Secure Real-time Transport Protocol その鍵で音声・映像を暗号化して送る DTLS / SRTP
23. DTLS: Datagram Transport Layer Security UDP上で相手確認と鍵交換をする SRTP: Secure Real-time Transport Protocol その鍵で音声・映像を暗号化して送る DTLS / SRTP 通話開始できた！！ めでたしめでたし...
24. DTLS: Datagram Transport Layer Security UDP上で相手確認と鍵交換をする SRTP: Secure Real-time Transport Protocol その鍵で音声・映像を暗号化して送る DTLS / SRTP ではない！
25. 接続したら終わりではない! ブラウザは通話中も品質を測り続ける なぜなら、接続後も通話の状態は変わり続ける 6. 繋がった後 実測例 audio: codec: Opus video: codec: AV1 frame size: 320x180 fps: 31 見る値 - stats: 通話中の測定値 - codec: 圧縮形式 - fps :1秒あたりのコマ数
26. カメラで撮った映像が、そのまま相手に送られるとは限らない camera request: 1280x720 actual outbound video: 320x180 Meet側で品質調整が入る 解像度はそのまま送られない
27. 「ビデオ通話が繋がる0.2秒の間」 では、こんなことが起きている! まとめ 1. ページ表示 2. デバイス準備 3. 接続条件交換 4. 経路探索 5. 鍵交換 6. メディア送受信
28. HTTP/3, QUIC curl -I -L https://meet.google.com HTTP/2 200 alt-svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000 ページ表示側では HTTP/3 の案内も返っていた。 おまけ