Skip to content

Instantly share code, notes, and snippets.

@voluntas
Last active May 21, 2024 13:55
Show Gist options
  • Save voluntas/a9dc017ea85aea5ffb7db73af5c6b4f9 to your computer and use it in GitHub Desktop.
Save voluntas/a9dc017ea85aea5ffb7db73af5c6b4f9 to your computer and use it in GitHub Desktop.
詳解 WebRTC

詳解 WebRTC

更新:2017-09-26
作者:@voluntas
作者サイト:http://voluntas.github.io/
バージョン:1.2.1
セッション日時:2017-09-24 14:20 - 15:00
セッション場所:5号館3F
発表時間:40 分
公式セッション情報:http://events.html5j.org/conference/2017/9/session/#e3
公式スピーカー紹介:http://events.html5j.org/conference/2017/9/speaker/index.html#voluntas

この資料は 2017-09-24 に行われた HTML5 Conference 2017発表者メモ です。

ショートURL は http://bit.ly/u-w-i です。understanding-webrtc-internals です。

この資料の間違いについては Twitter で @voluntas までリプライをお願いします。

おすすめ書籍

この資料では WebRTC API については説明していません。一通りの知識を得たい場合の本をオススメしておきます。

わか(った気にな)るWebRTC 電子版のみ - Route 312 - BOOTH(同人誌通販・ダウンロード)

個人が書かれている本ですが、とてもキレイにまとまっておりますのでオススメです。アップデート版も今後でるそうなので期待しておきましょう。

予習

これらの WebRTC の章を呼んでから、この話を聞きに来るとより、楽しいかもしれません。

自己紹介

時雨堂の方から来ました。Erlang/OTP でミドルウェアを書いて 10 年くらいご飯を食べています。 専門は認証、課金、暗号(使う方)、そしてリアルタイム配信です。興味があるのは継続的負荷試験です。 最近は WebRTC 用の負荷試験ツールをちまちま作ったりしています、そのうち売り出す予定です。

時雨堂は Let’s Encrypt スポンサーです。

概要

今回は WebRTC API の話は一切しません。ブラウザが 通信している部分の仕組み を中心に話をします。

今回持って帰っていただきたいのは「 WebRTC はこんな複雑なんだな」ということです。

この資料自体は公開されますので、写真とかは取らなくて大丈夫です。

注意

  • WebRTC のデータチャネルについては解説しません
    • 単に自分が詳しくないのと DTLS-SCTP を解説してると時間が足りないから
  • WebRTC API については解説しません
    • 知りたい人は沢山資料があるのでぐぐってください

WebRTC 概要

このイベントに来ていて WebRTC を知らない人はいないと思うので解説しません。

  • TLS の基本的な知識
  • WebRTC は P2P という技術を利用している
  • WebRTC は暗号化されている
  • WebRTC はリアルタイムに音声や映像を相互に送りあえる

これは知っている前提で話をします。

WebRTC で利用されているプロトコルを簡単に紹介する

実は WebRTC というのは沢山のプロトコルが絡み合ってできています。

  • UDP
  • DTLS
  • RTP / RTCP
  • SRTP / SRTCP
  • STUN / TURN / ICE
  • SDP

まずは簡単に利用している主なプロトコルの説明をしていきます。

UDP

HTTP は TCP です。 WebRTC は UDP を利用します。

DTLS

WebRTC で利用されている主なプロトコルは暗号を書けるための MasterSecret を得るために利用するデータグラム向けの TLS です。 基本的には ECDHE-ECDSA で AES-GCM-128 が利用されます。

RTP

WebRTC の音声や映像をこの RTP というプロトコルに詰め込んで送ります。リアルタイムアプリケーション用のプロトコルです。 UDP 上のプロトコルです。

RTCP

RTP と対になるプロトコルです。ただこちらは RTP をコントロールするプロトコルです。RTP は UDP ベースのためパケロス、遅延など色々な問題が起きたことに気付くのがわかりません。それを気づかせるためのプロトコルです。

SRTP

RFC 3711 - The Secure Real-time Transport Protocol (SRTP) RFC 7714 - AES-GCM Authenticated Encryption in the Secure Real-time Transport Protocol (SRTP)

SRTP は RTP を暗号化するプロトコルです。 DTLS で交換した MasterSecret を利用します。 RTP のヘッダー自体は暗号化しません。さらに HMAC によるハッシュチェックも追加されます。これにより改ざんを防ぐことができます。

暗号には AES-CTR が利用されます。最近では AES-GCM も実装されました。

AES-GCM は Chrome では chrome://flags で有効にすることで実現できます。そのうち AES-GCM が標準になるかもしれません。

SRTCP

SRTCP は RTCP を暗号化するプロトコルです。少し SRTP と違うのは RTP にはあったシーケンス番号が RTCP にはないため、SRTCP ように SRTCPIndex というのが用意されています。さらに 32 ビットではなく 31 ビットで、1 ビットだけ E フラグという暗号化しているのかされているのかという判断用のフラグが用意されています。

こちらにもハッシュチェックは存在しています。

DTLS-SRTP

WebRTC では DTLS を普通の使い方せず Applicaiton Data は利用しません。あくまでマスターシークレットだけを活用します。

マスターシークレットからクライアントとサーバの AES-CTR 用の鍵、ハッシュ関数用のシークレットを生成します。これが AES-GCM n場合は AES-GCM 用の鍵を生成するだけです。

STUN

RFC 5389 - Session Traversal Utilities for NAT (STUN)

相手から見た、自分の IP を知るためのプロトコルです。そんなの自分で知ってるのでは?と思われがちですがそんなことはないです。インターネッツはそんな単純ではありません。

これは STUN サーバというのをグローバルに置くことで、そこに自分 STUN パケットを送り、相手が受け取ったときの自分の IP アドレスとポート番号を繰り返してもらいます。これを利用して自分が今どんなネットワーク状況にいるのかを知ります。

TURN

RFC 5766 - Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)

TURN は STUN のお仲間ですが、役割が違います。STUN で確認した自分の状況で「あきらかにこれは相手と直接やり取りするのは難しそう ... 」と判断した際に利用します。

直接やり取りをせず、通信をやり取りするためのプロトコルです。

これは UDP と TCP 、そして TLS over TCP が WebRTC では採用されています。

ICE

RFC 5245 - Interactive Connectivity Establishment (ICE): A Methodology for Network Address Translator (NAT) Traversal for Offer/Answer Protocols

ICE は STUN と TURN を組み合わせたプロトコルで、どうにかして相手とやり取りをするためにいろいろな策を打つためのプロトコルです。

この話をするだけで 1 日使える位な世界なので、今回は詳しくは話しません。

SDP

RFC 4566 - SDP: Session Description Protocol

これはお互いにやり取りをする時の条件を決めるためのプロトコルです。 SDP は WebRTC の通信上でやり取りはしません。

WebRTC の仕様で決められていない、第三者を経由して相手と SDP を交換します。この第三者のことをシグナリングサーバと呼びます。

WebRTC 実装の現実

プロトコルの仕様が膨大

先程のプロトコルの紹介のときに、全てに RFC が割り当てられているのにお気づきかと思います。先ほど紹介したのは基本の RFC だけです。応用となると大変な数があります。

その大変な量の RFC またはドラフトと呼ばれるまだ確定していない仕様をそれぞれのブラウザが独自で実装しています。

大変な量 ... というのがどのくらいかは全てではありませんが一部をまとめてあります。

WebRTC スタックを一から実装する場合読んでおくべき資料まとめ

通信プロトコルの確定した仕様はない

実は WebRTC の具体的な仕様は決められていません。仕様があるのは WebRTC API の方です。

WebRTC 1.0: Real-time Communication Between Browsers

繫がらない時の問題解決がやっかい

WebRTC はネットワークの問題で繫がらない事があります。ブラウザから見たら「ちょっとしたエラーメッセージがでているだけ」ですが、実際はおもったより深刻なネットワーク問題だったりもします。

うまくいかない時、 WebRTC はブラウザから突然別世界へ連れて行かれます。

ブラウザの現状

全てのブラウザで WebRTC API の対応が違う以前に、内部実装も異なります。 内部実装は全て違います。重要な事なので二回言いました。

現時点で WebRTC に対応している主要なブラウザは 4 つです。これ以上は増えないと考えて良いでしょう。

  • Chrome
  • Firefox
  • Edge
  • Safari

やっと 2017 年で出揃いました。

コーデックウォー

RFC 7742 - WebRTC Video Processing and Codec Requirements

WebRTC API やプロトコル以外に、 WebRTC では コーデック という概念があります。音声や映像を圧縮する仕組みです。

コーデックが問題になるのは、大きく2つの点です。 一つはライセンスです。そしてもう一つはハードウェアアクセラレータの必要性です。

ライセンス問題は色々めんどくさいのですが、 Safari を例に取ると大変良くわかります。

  • Safari 11 では H.264 というコーデックしか対応しない
    • Safari が使える端末には H.264 のハードウェアアクセラレータが必ず載っている
  • H.264 を使うにはライセンス費用がかかる
    • OpenH264 というライブラリをシスコが出しており、シスコがライセンス費用の全額を負担している
  • WebRTC では VP8 と H.264 両方に対応するべきという方針になった
  • VP8 上位版である VP9 は VP8 のビットレートを半分にして、同等の画質が得られる
    • ただし CPU 使用率は 30% アップ
  • VP8 と VP9 は Google がオープンに開発しているコーデック

もうめんどくさそうなのわかりますか? RFC は強制ではありません。

H.265 という特許の闇

8265 - Add H.265 support for iOS - webrtc - Monorail

iOS が H.265 に対応したことにより、WebRTC で H.265 を採用する可能性が出てきました。 H.265 は VP9 と同じ立ち位置に有り、 H.264 の半分のビットレートで同じ画質を実現可能になります。

ただ、闇は多く特許がとても複雑です。詳細は H.265/HEVC特許暗黒時代 - Qiita を御覧ください。

アップルは特許ホルダー側なのでいいですが、ブラウザ側は色々手の出しようがありません。さてさて。

コーデックと RTP

これまためんどくさい世界で、それぞれで仕組みが違います。

コーデックの未来

AV1 というコーデックがあります。これは AOM (Alliance for Open Media) という団体で開発されているコーデックです。これは H.265 とは違いパテントフリーです。いろいろな企業がパテントに疲れたのでしょう ... 。

VP9 に比べて 50% 効率が良いらしいですが、実際使ったこと無いのでよくわかりませんが、かなり気合い入れて開発はしているようです。

libwebrtc の存在

WebRTC Native APIs | WebRTC

これは何かというと、Chrome で利用されている WebRTC 実装です。 Firefox と Safari はこのライブラリを利用しています。ただし、Chrome のように常に最新版のタグを使っているわけではなく、少し遅れている感じです。 Edge は独自です、間違いなく。

Edge は厳しい

さてここで Edge の WebRTC について、一言言わせてください。仕様がクローズドな上にソースもクローズドです。そして WebRTC の仕様は明確にされていない。現時点での Edge の WebRTC 実装は使い物にならないというのが現状です。

WebRTC の凄さ

いままで説明してきたプロトコルの話を 知らなくても利用できる というのが WebRTC の凄いところです。

JavaScript API だけで利用が可能になりました、特に WebRTC がブラウザに搭載されるまでは音声や映像でリアルタイムにやり取りをする場合は専用アプリを作る必要がありました。これらがブラウザで完結できるようになりました。

また WebRTC はブラウザに搭載されているという技術でしかないため、 iOS/Android 、さらにはラズパイなどでブラウザ無しでの WebRTC を動かすことも可能です。

WebRTC は 双方向で音声や映像をやりとりするなんでも入りのライブラリ です。いままでこのレベルでまとまっているものはありませんでした。これが全てオープンソース公開されているのはとても凄いことです。

WebRTC の今後

規格統一

ブラウザごとの WebRTC API の仕様は統一されていくそうです。だからといって、プロトコルレイヤーは統一されていくことは無いでしょう。

ただ、正直全てのブラウザが同一の仕様になる日は来ないと考えています。開発ペース、動作するハード、条件が色々違いすぎます。このあたりを吸収するのは難しいと考えています。

例えば Edge はソースコードがクローズだったり、そもそも Skype をブラウザで動かすことが目的だったりと WebRTC を他のブラウザとやりとりすることはあまり考えられていない印象があります。

また Safari は動作する環境が Apple 側で決められるため、それに最適化した仕様になってしまいます。Chrome/Firefox は中立といえば中立でしょうか。

正直どうなるかは読めません。

RTMP の代替

Flash が 2020 年に終わるということで、今まで Flash で利用してきた音声や映像を配信する技術は今後は WebRTC または HLS/MPEG-DASH に切り替わっていくでしょう。

とはいえ、 WebRTC はあくまで P2P の技術であり、 RTMP のように多くのユーザに配信する技術ではありません。そもそも RTMP は CDN が使えます。

つまり、そう簡単に RTMP から WebRTC への置き換えはできない、というのが現状です。

Safari の登場

Safari 11 で WebRTC に対応しました。今まで iOS のモバイル Safari では WebRTC が動かないため、iOS の場合は専用アプリを作る必要がありました。

ただ、これが必要なくなるため、ブラウザベースで十分という人が増えることで気軽に利用可能です。この流れは大きく、スマホアプリを作らなくても iOS に対応可能というのは、 WebRTC の利用範囲を押し上げると思います。

まとめ

ざっと WebRTC で利用されているプロトコルから、 WebRTC の仕組み。さらにはなぜ WebRTC が難しいのか、なぜ凄いのか。そして今後を見てきました。

実際に WebRTC を利用したアプリケーションを使う場合はこれらを意識する必要は一切ありません。ユーザ側はとても便利です。ただアプリケーションを開発したり、運用シていく場合はこのあたりの知識を持っていたほうが良い場合は多いです。

WebRTC のようなリアルタイムな双方向通信は Skype や Facetime 、さらには LINE のようなメッセンジャーツールが実現している事もあり、簡単な技術と取られることが多いです。ただ実際は複雑な仕組みになっています。この複雑な仕組みは好きで複雑になっているわけではありません。

ネットワーク環境、マシン環境、ブラウザバージョンなど様々な条件は使う人全てが同じわけではありません。そんな中で遅延が 1 秒を切る世界を実現するには、かなり幅広いところまで考えておく必要があるのです。

今後もし WebRTC の話題が出た時に「あ、これ実は凄い複雑で難しい技術だよね」なんて話をしてもらえれば今回の発表の目的は達成できたと思います。

以上で発表を終わります。

広告

WebRTC SFU Sora

WebRTC SFU Sora

商用の WebRTC SFU です。価格は同時 100 接続で年間利用料ライセンス 60 万円です。毎年かかります。製品のサポート料金込みです。200 接続だと年間 120 万円です。

複数人数での会議や、 数百人への配信、一対一の面談など様々な用途に利用可能です。

パッケージで提供しますので、自社で運用が可能です。 AWS だろうが GCP だろうが、オンプレだろうがなんでも好きな環境で動かすことができます。

サーバさえあれば起動までは 10 分です。デモ機能が内蔵しているので動かすまで 15 分です。

  • 大変多くのお客様に採用いただいております
  • とにかく 落ちないこと を目的に作っています
  • とにかく 繋がること を目的に作っています
  • とにかく 手間がかからないこと を目的に作っています
  • 最新ブラウザのアップデートに追従しています
  • シグナリングサーバ内蔵ですので別途立てる必要はありません
  • TURN サーバ内蔵ですので別途立てる必要ありません
  • 日本語によるサポート対応しています
  • フルスクラッチ自前実装なのですべて把握しています
  • 1:1 の双方向に対応しています
  • 1:300 の片方向に対応しています
  • 3:300 といった配信者が複数の片方向にも対応しています
  • スポットライトという機能を利用することで 50 人以上の会議に対応しています
  • 録画機能があります
  • Chrome / Firefox / Edge / Safari といった主要ブラウザ全てに対応しています
  • Apache 2.0 ライセンスで JavaScript と iOS と Android のクライアント SDK を公開しています
  • Apache 2.0 ライセンスで React Native 向け WebRTC ライブラリを公開しています
  • 既存システムとの連携を重視しており、Web フック機能を利用して簡単に連携が可能です
    • 認証や、クライアントの接続切断などもすべて HTTP での通知を既存のシステムに送ることができます

興味のある方はお気軽に sora at shiguredo.jp までお問い合わせください。

紹介や検討資料も公開しております。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment