前の部分の概要を説明した後、P2P オーディオおよびビデオ インタラクションのプロセスの一般的な理解が必要です.プロセスが面倒で、ネットワークの最下層が含まれていると感じるかもしれません. でも心配はいりません。WebRTC は私たちに多くのことをしてくれ、オーディオとビデオの開発を容易にしてくれました。では、WebRTCとは正確には何ですか?
WebRTC (Web Real-Time Communications) は、ネットワーク アプリケーションまたはサイトが、仲介者なしでブラウザ間にピア ツー ピア (ピア ツー ピア) 接続を確立して、ビデオ ストリーミングおよび/または伝送を実現できるようにするリアルタイム通信テクノロジです。オーディオストリームまたはその他の任意のデータの。WebRTC に含まれるこれらの標準により、ユーザーは、プラグインやサードパーティ ソフトウェアをインストールすることなく、ピア ツー ピア (ピア ツー ピア) のデータ共有と電話会議を作成できます。
WebRTC は Google 独自の技術ではありません。2010 年、Google は VoIP ソフトウェア デベロッパーの Global IP Solutions を約 6,820 万ドルで買収し、同社が所有する WebRTC テクノロジを取得しました。現在、インターネットの音声およびビデオ通信サービス技術は、Skypeなどの独自技術が一般的であり、通信機能を実現するにはプラグインまたはデスクトップ クライアントをインストールする必要があります。Google は、Web 開発者がブラウザでビデオまたはボイス チャット アプリケーションを直接作成できることを望んでいます. Global IP Solutions は以前に、Android、Windows Mobile、および iPhone 用の WebRTC ベースのモバイル クライアントを作成しました。今回、Google は WebRTC をオープン ソースにしました。これは、ブラウザ メーカーがテクノロジをブラウザに直接埋め込んで、Web 開発者を容易にすることを望んでいるためです。
コンセプト補足
前述の概念に加えて、関連する概念をいくつか追加します。
インタラクティブリンク機能
Interactive Connectivity Establishment (ICE): ブラウザがピア ブラウザとの接続を確立できるようにするプロトコル フレームワーク。実際のネットワークでは、A から B への単純な直接接続を希望どおりに完了できない理由は多数あります。これには、接続の確立を妨げるファイアウォールをバイパスし、デバイスに一意に見えるアドレスを割り当てる必要があります (通常、ほとんどのデバイスには固定のパブリック ネットワーク アドレスがありません)。ルーターがホストの直接接続を許可しない場合は、サーバーはデータを転送します。この ICE は、STUN や TURN などの以前の接続方法の要約であることに気付いたかもしれません.正式には、ICE フレームワークにより、開発作業が大幅に簡素化され、ICE は優先度に応じて接続方法を自動的に選択します。
シグナリング サーバー
シグナルサーバー（シグナルサーバー）：ピア間で通信アドレスを交換し、STUNを介して独自の通信アドレスを取得した後、シグナルサーバーに登録してデバイス間で通信アドレスを交換し、P2P接続を完了します。
セッション記述プロトコル
セッション記述プロトコル(Session Description Protocol、SDP): 解像度、フォーマット、エンコード、暗号化アルゴリズムなど、マルチメディア接続の内容を記述するプロトコル。P2P 接続を開始する前に、双方がサポートするセッション プロトコルをネゴシエートする必要があります。ユーザーが別のユーザーへの WebRTC 呼び出しを開始すると、オファーと呼ばれる特定の説明が作成されます。説明には、発信者によって提案された通話構成に関するすべての情報が含まれます。受信者は、通話終了の説明である応答を返します。このように、2 つのデバイスは、メディア データを交換するために必要な情報を互いに共有します。SDP は、このようにコンテンツを記述します ("="両側にスペースを入れることはできません)。
v=0
o=- 212360934117607227 2 IN IP4 127.0.0.1
s=-
t=0 0
m=audio 9 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 110 112 113 126
a=rtpmap:111 opus/48000/2
......
m=video 9 UDP/TLS/RTP/SAVPF 96 97 98 99 100 101 102 121 127 120 125 107 108 109 35 36 124 119 123 118 114 115 116
a=rtpmap:96 VP8/90000
......
SDP 記述はセッションと複数のメディア記述で構成されます. セッション記述は v= から最初のメディア記述まで (1-4 行) であり, メディア記述は m= から次のメディア記述まで (5-6 行— - オーディオ、ライン 8 ～ 9 - ビデオ)。
セッションレベルの説明
多くのセッション説明フィールドがあり、最も重要なものは 4 つのフィールドです
- v=: マイナー バージョンを除く UDP バージョン番号* o=: セッション開始者の説明 > o=*
<username>: ユーザー名、ユーザー名を気にしない場合は、代わりに "-" を使用できます; *<session id>:数値文字列, セッション全体で一意である必要があり, NTP タイムスタンプを使用することをお勧めします. *<version>: バージョン番号, バージョン値はセッション データが変更されるたびに増加します. *<network type>: ネットワーク タイプ, 通常は "IN",これは「インターネット」を意味します; *<address type>: アドレスの種類、通常は IP4; *<address>: IP アドレス - セッション名: セッションを示します * t=: 開始時刻と終了時刻の説明、
t=<start time> <stop time>両方のイベントが 0 の場合、永続的なセッションを意味します ##### WebRTC の SDP
WebRTC の SDP にいくつかの変更が加えられ、オリジナルに基づいていくつかの説明が追加されました。
// 音频使用9端口收发;
// UDP / TLS / RTP / SAVPF 表示使用 dtls / srtp 协议对数据加密传输;
m = audio 9 UDP / TLS / RTP / SAVPF 111 103 104 9 0 8 106 105 13 110 112 113 126
// 网络描述, webRTC不使用
c = IN IP4 0.0.0.0
// 设置rtcp地址和端口, webRTC不使用
a = rtcp: 9 IN IP4 0.0.0.0
// 安全验证信息
a=ice-ufrag:duP8
a=ice-pwd:/7pIrSvgESATKPZUVzHhLQ0E
a=ice-options:trickle
// 音频流媒体描述
a=rtpmap:111 opus/48000/2
a=rtcp-fb:111 transport-cc
a=fmtp:111 minptime=10;useinbandfec=1
a=rtpmap:103 ISAC/16000
a=rtpmap:104 ISAC/32000
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:106 CN/32000
a=rtpmap:105 CN/16000
a=rtpmap:13 CN/8000
a=rtpmap:110 telephone-event/48000
a=rtpmap:112 telephone-event/32000
a=rtpmap:113 telephone-event/16000
a=rtpmap:126 telephone-event/8000
メディアの説明
- m=: セッションを示します
m=<media> <port> <transport> <fmt list>*<media>: オーディオ/ビデオなどのメディア タイプ; *<port>: ポート; *<transport>: トランスポート プロトコル、RTP/AVP と UDP の 2 種類があります; *<fmt list>: メディア フォーマット、つまり、データ ペイロード タイプ (Payload Type ) リスト。 - a=*:
a=<type>またはa=<type>:<value>、タイプには rtpmap と fmap の 2 つのタイプがあります
ここで、前のゲートウェイの回路図を改善し、ここにいくつかの概念を追加しましょう
候補住所を集める
いわゆる候補アドレスの収集は、前述の STUN サーバーを介して独自の通信可能なアドレスを取得することです。
| の種類 | エイリアス | ピアに送信する方法 | 利用方法 |
|---|---|---|---|
| 主催者候補 | ホスト | シグナリング サーバー | ネットワーク カードから取得したローカル トランスポート アドレス。このアドレスが NAT の背後にある場合は、イントラネット アドレスです。 |
| サーバー リフレクション候補 | srflx | シグナリング サーバー | stun サーバーに送信された Binding チェックから取得されたトランスポート アドレス。このアドレスが NAT の背後にある場合は、最も外側の NAT のパブリック ネットワーク アドレスです。 |
| ピアリフレクション候補 | prflx | スタンバインドリクエスト | ピアによって送信された Stun Binding 要求から取得されたトランスポート アドレス。これは、接続チェック中に発生する新しいタイプの候補です。 |
| リレー候補生 | リレー | シグナリング サーバー | メディア リレー サーバーのトランスポート アドレス。TURN Allocateリクエストで取得 |
交換候補アドレス
A は最初のステップで収集した候補アドレスをシグナリング サーバーを介して B に送信し、B も収集した候補アドレスを A に送信します。B のすべての候補アドレスを受信した後、A は自身の候補アドレスとピア候補アドレスを比較します。完全な配置を作成し、状態テーブルに保存します。例えば、この時のAさんのホストは192.168.0.100:60000、srflxは11.102.30.3:30110、Bさんのホストは192.168.0.15:10001、srflxは1.10.108.25:30110、ステータステーブルは以下の通り
| ローカル ネットワーク カード アドレス | ピア アドレス | 州 |
|---|---|---|
| 192.168.1.105:60001 | 192.168.0.204:40001 | スタンチェック未実施 |
| 172.16.40.6:60003 | 192.168.0.204:40001 | スタンチェック未実施 |
| 192.168.1.105:60001 | 11.92.14.8:50002 | スタンチェック未実施 |
| 172.16.40.6:60003 | 11.92.14.8:50002 | スタンチェック未実施 |
| 192.168.1.105:60001 | 192.168.0.181:40003 | スタンチェック未実施 |
| 172.16.40.6:60003 | 192.168.0.181:40003 | スタンチェック未実施 |
この時点では、すべてのレコード ステータスが STUN チェックされているわけではなく、次のステップで各レコードの STUN チェックが実行されます。
STUNチェック
以前STUN検査プロセスを紹介しましたが、忘れた場合はp2p穴あけを見直すことができます
接続、起動メディア
STUN チェックが完了すると、接続が準備されます。この時点で、P2PTransportChannel のステータス テーブルには、各レコードのコストが記録されています (Stun 要求を送信してから応答を受信するまでの経過時間など、多くの要因が関係しています。. .)。
**送信するビデオ Rtp データがある場合、ステータス テーブルの最初のレコードを確認し、ステータスが送信可能であると判断された場合は、この Connection を使用して送信します。それ以外の場合は、送信タスクを直接放棄します。**つまり、メディア モジュールのタスクは接続状態の影響を受けず、送信しようとしているときにステータスを確認し、接続されていない場合は送信を断念します。
メディア セッション中に NAT マッピングおよびフィルタリング ルールがタイムアウトにならないようにするために、ICE は使用中の候補に対してスタン接続チェックを継続的に送信します。簡単に言えば「ポーリング」です.STUNの応答がタイムアウトすると、コストが増加し、優先度が下がるにつれてステータステーブルに反映されます.つまり、P2PTransportChannelステータステーブルはリアルタイムです.
やっと
75のJSの高頻度インタビュー質問を整理し、回答と分析を提供しました.これは、JSに関するインタビューアーの質問に基本的に対処できることを保証できます.
困っている友達は、下のカードをクリックして無料で受け取り、共有できます