フロントエンドの少年として、WebRTC を知っていますか?

WebRTC (Web Real-Time Communications) は、オープンソースのクロスプラットフォームのリアルタイム通信テクノロジです。これを使用して、仲介者なしでブラウザでピアツーピア接続 (ピアツーピア) を確立し、実現することができます。オーディオビデオ伝送、画面共有、P2P ファイル共有などの機能。

WebRTC は 2011 年 6 月 1 日にオープンソース化され、Google、Mozilla、および Opera のサポートにより World Wide Web Consortium の W3C 標準に組み込まれました。

1.互換性

caniuse WebRTC

最新のブラウザとモバイルデバイスは、すでに WebRTC を完全にサポートしています。

2. WebRTC アーキテクチャ

WebRTC アーキテクチャは 4 つのレイヤーに分かれています

2.1 WebRTC C++ API レイヤー

WebRTC C++ API (PeerConnection) は、P2P 接続、オーディオとビデオの収集、オーディオとビデオの伝送、非オーディオとビデオのデータ伝送などを実現します。

2.2 セッション管理レイヤー

セッション管理 / 抽象シグナリング (セッション) セッション管理レイヤー。オーディオとビデオ、オーディオとビデオ以外のデータ伝送の管理、および関連ロジックの処理に使用されます。

2.3 エンジンおよびトランスポートプロトコル層

オーディオエンジン (音声エンジン)

- iSAC/iLBC (オーディオコーデック)
- 音声用の NetEQ (ネットワークジッタと音声パケット損失を処理)
- エコーキャンセラー・ノイズリダクション（エコーキャンセラー・ノイズリダクション）

ビデオエンジン

- VP8 (ビデオコーデック)
- ビデオジッターバッファー (ビデオジッターバッファー、ネットワークの理由によるビデオジッターまたはビデオデータ損失の処理)
- 画像強化 (画像強化モジュール、ビデオ画質の向上)

トランスポートプロトコル (トランスポート)

- SRTP (HTTP と HTTPS の関係と同様に、RTP リアルタイムトランスポートプロトコルに基づいてセキュリティメカニズムを追加するセキュアリアルタイムトランスポートプロトコル)
- 多重化（多重化、複数のストリーミングデータ伝送が1つのチャネルを共有して伝送効率を向上）
- P2P STUN+TURN+ICE (NAT 侵入と中継サービス)

2.4 ハードウェア適応層

オーディオキャプチャとレンダリング、ビデオキャプチャ、ネットワーク I/O を含むハードウェアアダプテーションレイヤー。ブラウザメーカーが独自に実装できるこの設計により、WebRTC の柔軟性とクロスプラットフォームが向上します。

3. WebRTCのコアAPI

MediaStream API

- navigator.mediaDevices.getUserMedia (ローカルのカメラとマイクを呼び出す)
- navigator.mediaDevices.getDisplayMedia (スクリーンキャプチャを呼び出します)

RTCPeerConnection API (ピア接続の確立)
RTCDataChannel API (ピア接続間のデータ転送)

mediaDevices を呼び出してメディアストリームを取得する場合、現在の Web ページのプロトコルは localhost または https である必要があります。そうでない場合、navigator.mediaDevices は未定義です。

4. WebRTC がピアツーピア接続を確立します

ピアツーピア接続を確立する前提: 両方の当事者が相手の IP アドレス、サポートされているメディアの種類、オーディオとビデオのエンコード、およびその他の情報を知っている必要があります。

ローカル接続: 2 つのデバイスがローカルエリアネットワーク内にある場合、処理を行う必要はありません。シグナリングサーバーを使用して相手の sdp を取得するだけで、LAN IP を介してピアツーピア接続を実行できます。 .

パブリックネットワーク接続: ローカル接続を除く。P2P通信を実現するためには、双方の通信当事者が互いの公衆網のIPを知っている必要があります。

4.1 パブリックネットワーク IP を取得する方法は?

実際のアプリケーションでは、NAT やファイアウォールなどの理由により、マシンのパブリックネットワーク IP を直接取得することはできません.マシンの対応するパブリックネットワーク IP を取得するには、NAT の侵入が必要です.

NAT (ネットワークアドレス変換、 ネットワークアドレス変換 )は、内部ネットワークと外部ネットワーク間の通信を実現するために、プライベートネットワークの IP アドレスをパブリックネットワークの IP アドレスに変換できます。NAT テクノロジーは、当初、不十分な IPV4 アドレスの問題を解決するために設計されました。

通常、ルーターの WAN ポートにはパブリックネットワーク IP があり、ルーターの LAN ポートに接続されているすべてのデバイスには、プライベートネットワークセグメントの IP アドレス (たとえば、192.168.1.2) が割り当てられます。内部ネットワークデバイスの IP は、ルーターのパブリックネットワーク IP と唯一のポートにマッピングされます. この方法では、各内部ネットワークデバイスに異なるパブリックネットワーク IP を割り当てる必要はありませんが、ルーターによって検出することができます.外部ネットワークデバイス。

NAT トラバーサルの方法:

気絶
振り向く
氷

4.1.1 スタン

STUN (NAT 用のセッショントラバーサルユーティリティ、NAT セッショントラバーサルアプリケーション)。ネットワークアドレス変換 (NAT) の問題を解決するために使用されます。2 つのデバイス間で WebRTC 接続が確立されている場合、それらの間に NAT がある場合は、STUN サーバーを介して自分のパブリック IP アドレスとポート番号を取得する必要があります。これにより、相手が自分自身に直接接続できるようになります。STUN サーバーは、パブリックネットワークの IP アドレスとポート番号を取得するためにのみ使用され、データ転送サイトとしては使用されません。

STUN サーバーは、それ自体を実装する必要があります。無料の STUN サービス。例: stun:stun.l.google.com:19302。

STUN は対称 NAT とファイアウォールを通過できません。

4.1.2 ターン

TURN (リレー NAT、リレーサーバーを使用したトラバーサル)。P2P による直接接続ができない状況を解決するために使用されます。2 つのデバイス間で WebRTC 接続を直接確立できない場合、TURN サーバーを中継サイトとして使用して、デバイス間でデータを転送する必要があります。TURN サーバーは、2 つのデバイス間のリアルタイム通信のために異なるネットワーク間でデータを転送できます。

オープンソースTURNサービス：coturn

4.1.3 アイス

ICE (Interactive Connectivity Establishment、インタラクティブ接続確立) ICE はネゴシエーションフレームワークであり、ICE は、ネットワークの状態やデバイスの能力などの要因に応じて、P2P またはリレー伝送を自動的に選択し、WebRTC 接続の安定性と品質を確保します。

ICE 接続確立プロセス: ICE は最初にエンドツーエンドの直接接続を試行し、接続が失敗した場合、STUN サービスを呼び出して NAT 貫通を実行し、パブリックネットワーク IP を取得します。接続が失敗した場合は、中継送信用TURNサーバー。

[学習アドレス]: FFmpeg/WebRTC/RTMP/NDK/Android オーディオおよびビデオストリーミングメディアの高度な開発
[記事の特典]: より多くのオーディオおよびビデオ学習教材パッケージ、Dachang インタビューの質問、テクニカルビデオ、および学習ロードマップを無料で受け取ります ( C/C++、Linux、FFmpeg webRTC rtmp hls rtsp ffplay srs など) 必要な場合は、 1079654574 をクリックしてグループに参加して受け取ることができます~

4.2 メディアタイプ、オーディオおよびビデオエンコーディングを取得する方法は?

現在のデバイスの SDP を呼び出すRTCPeerConnection.createOffer/取得します。RTCPeerConnection.createAnswer

SDP (Session Description Protocol)は、メディアタイプ、コーデック形式、暗号化アルゴリズム、伝送プロトコルなど、メディアネゴシエーション情報を記述するプロトコルです。2 つのデバイスが WebRTC 接続を確立するとき、SDP をネゴシエートして交換し、互いのメディアパラメータとプロトコル情報を理解できるようにする必要があります。

技術的に言えば、SDP は実際のプロトコルではなく、デバイス間のピアツーピア接続のパラメーターと構成情報を記述するために使用されるデータ形式です。

構造: SDP は 1 行以上の UTF-8 テキストで構成され、各行はそのタイプの文字で始まり、その後に等号 (「=」) が続き、その後に値または説明を含む構造化テキストが続きます。タイプ。特定の文字で始まるテキスト行は、「文字行」と呼ばれることがよくあります。たとえば、メディアの説明を提供する行は「m」タイプであり、「m 行」と呼ばれます。

次の図は、SDP の例です。

5. シグナリングサーバー

上記では、パブリックネットワーク IP、メディアタイプ、オーディオとビデオのエンコーディング、およびその他の情報を取得する方法について説明しました。では、この情報を使用してピアツーピア接続を 2 つの当事者に通知するにはどうすればよいでしょうか。

これは、シグナリングによって実現できます.デバイス間でデバイス情報を送信して、通信プロトコル、メディアコーデック、データ転送方法、および必要なルーティング情報を決定するプロセスは、シグナリング (シグナリング) と呼ばれます。

シグナリングを送信するサーバーをシグナリングサーバーと呼び、受信した情報に対して特別な処理は行わず、データの送受信のみを行います。

5.1 シグナリングサーバーの役割

取引所SDP
制御メッセージの送信: 通信の設定、開始、終了、または例外の処理に使用されます。
メディア機能のネゴシエーション: 通信する両当事者がサポートできるコーデックとメディアデータ形式

SDP 交換後、WebRTC ピアツーピア通信が実際に開始されます。

5.2 シグナリングサーバーの構築

シグナリングサーバーは WebRTC 仕様に属しておらず、自分で構築する必要があります。これは、WebSocket またはポーリング HTTP 要求を介して実行できます。

6. webRTC通信処理

RTCPeerConnection を呼び出してピア接続を作成する
getUserMedia を呼び出してカメラとマイクを開きます
RTCPeerConnection.addTrack を呼び出して、オーディオとビデオのトラックをピアツーピア接続メディアストリームトラックに追加します (ピアツーピア接続が成功した後、ピアに送信されます)。
RTCPeerConnection.createOffer を呼び出して SDP オファーを作成し、setLocalDescription メソッドを呼び出してローカルの説明に sdp を追加します
クライアント A は、ICE サービスを呼び出してパブリックネットワーク IP を取得し、ICE 候補 (ICE 候補) を生成します。
クライアント A は、シグナリングサーバーを介してクライアント B にオファーを送信します。
クライアント B は setRemoteDescription メソッドを呼び出し、受信した SDP オファーをリモートディスクリプションとして設定し、取得したオーディオストリームとビデオストリームを表示します。
クライアント B が getUserMedia を呼び出してカメラとマイクを開く
クライアント B は RTCPeerConnection.createAnswer を呼び出して SDP 回答を作成し、setLocalDescription メソッドを呼び出して sdp をローカルの説明に追加します。
クライアント B は、シグナリングサーバーを介してクライアント A に SDP アンサーを送信します。
クライアント A はそれを受信すると、setRemoteDescription メソッドを呼び出し、受信した SDP アンサーをリモートディスクリプションとして設定し、取得したオーディオおよびビデオストリームを表示します。
これまでのところ、接続は確立されています