WebRTCはどのように機能しますか？
ブラウザでのピアツーピア接続に興味があります。これはWebRTCで可能であると思われるので、それがどのように機能するかについて疑問に思っています。
私はいくつかの説明を読み、それについての図を見ました、そして今、私は接続確立がサーバー上で機能することは明らかです。サーバーは、相互に接続しようとするクライアント間でデータを交換しているように見えます。これにより、サーバーとは関係なく、直接接続を開始できます。
しかし、それは私が理解していないことの免除です。これまで、接続を作成する唯一の方法は、コンピューターAのポートをリッスンし、コンピューターBからそのポートに接続することであると考えていました。しかし、これはWebRTCの場合とは異なります。どのクライアントもポートで待ち受けを開始しないと思います。どういうわけか、ポートをリッスンして接続を受け入れることなく、接続を作成できます。クライアントAもクライアントBもサーバーとして機能し始めません。
しかし、どうやって？クライアントが相互に接続するために使用できるWebRTCサーバー経由で交換されるデータは何ですか？
このためのあなたの説明をありがとう:)
編集
this の記事を見つけました。これはWebRTCとは関係ありませんが、私の質問の一部に答えると思います。わかりません、タフです。誰かが私に説明してくれて、リンクを追加してくれたら、それでもかっこいいです。
WebRTCは、クライアントのJSアプリにSDPオファーを提供し（JSアプリが望んでいる場合は）、他のデバイスに送信し、それを使用してSDP回答を生成します。
トリックは、SDPにICE候補が含まれていることです（事実上、「このIPアドレスとこのポートで私に話しかけてみてください」）。 ICEは、ファイアウォールで開いているポートをパンチします。ただし、両側が対称NATである場合、一般的には不可能であり、（TURNサーバー上の）代替候補を使用できます。
直接（または実質的にはパケットミラーであるTURNを介して）話していると、DTLS接続を開き、それを使用してSRTP-DTLSメディアストリームをキーイングし、DTLS経由でデータチャネルを送信できます。
編集：頭字語はこちら： http://blog.1click.io/10-jargons-abbreviations-for-webrtc-fans/ 残りはGoogleです。これらのほとんどはIETFによって定義されています（ http://ietf.org/ ）
編集2：FirefoxおよびChrome（および仕様）はICE候補の「トリクル」の使用に移行したため、ICE候補は通常、PeerConnectionに後から追加され、独立して交換されます最初のSDP（最初の候補者が準備ができるまで待ってからオファーを送信し、それらをまとめることができます） https://webrtcglossary.com/trickle-ice/ および を参照してください。 https://datatracker.ietf.org/doc/draft-ietf-ice-trickle/
P2p WebRTC接続の確立には3つのステップがあります（10.000フィートの概要）。
手順1：Signaling：両方のピアがシグナリングサーバーに接続し（80/443、コメット、SIPなどのWebソケットを使用）、情報を交換します（メディア機能、パブリックIP：ポートペアが利用可能になったときのペアなど）
手順2：Discovery：LANまたはモバイルネットワークに接続されたデバイスは、到達できるパブリックIP（およびポート）を認識しないため、使用できますパブリックインターネット上にあるSTUN/TURNサーバーは、ip：portペア（ICE候補）を検出します。その過程で、ステップ3で使用されるNAT /ルーターに穴を開けます。
ステップ3：P2P接続：ICE候補が初期シグナリングチャネルを介して交換されると、各ピアは互いのip：portを認識します（およびホールがNAT /ルーターでパンチされるため、ピアツーピアUDP接続を確立できます。
上記のスキームは、2つのデバイスがローカルネットワークに接続されているプロセスを説明しています。これは 接続の問題のトラブルシューティング を扱った私が書いた記事の一部ですが、WebRTCのしくみを説明するのに役立ちます。
この本で非常に良い説明を見つけることができます http://chimera.labs.oreilly.com/books/1230000000545/ch03.html#STUN_TURN_ICE これは、WebRTCがICEテクノロジーを使用する方法の基礎を提供します。
特に、STUNサーバーのIPアドレスがわかっている場合、WebRTCアプリケーションは最初にバインディング要求をSTUNサーバーに送信します。 STUNサーバーは、パブリックネットワークから見たクライアントのパブリックIPアドレスとポートを含む応答で応答します。
これで、アプリケーションは、パブリックIPとSDPを介して他のピアに送信できるポートタプルを検出します。 （SDPは外部シグナリングチャネルを介して送信されることに注意してください。f.i。websocketはWebサービスを通じて確立されます）
このメカニズムを使用すると、2つのピアがUDPを介して相互に通信する場合は常に、確立されたパブリックIPおよびポートタプルを使用してデータを交換できます。
残念ながら、場合によっては、UDPがファイアウォールによってブロックされることがあります。この問題に対処するために、STUNが失敗した場合はいつでも、NAT（TURN）プロトコルのリレーを使用したトラバーサルをフォールバックとして使用できます。他のすべてが失敗した場合、UDPで実行し、TCPに切り替えることができます。
WebRTCの仕組み
このドキュメントでは、WebRTCの概要をすばやく簡単に紹介します。 WebRTCの詳細については、このドキュメントの最後にある「参考文献」セクションをご覧ください。
WebRTC
WebRTC（Webリアルタイム通信）は、ブラウザー間のピアツーピアの二重リアルタイム通信用に開発された一連のテクノロジーです。その名前が示すように、それはWebと互換性があり、 W3Cの標準 です。WebRTCの重要な機能の1つは、NATアドレスの背後でも機能することです。
WebRTCはいくつかのテクノロジーを使用して、ブラウザー間のリアルタイムのピアツーピア通信を提供します。これらのテクノロジは* SDP（Session Description Protocol） * ICE（Interactive Connection Establishment） * RTP（Real Time Protocol）
WebRTCを実行するにはSignalling Serverが必要です。ただし、シグナリングサーバーの実装には、明確な基準はありません。各実装は独自のスタイルを作成します。このセクションの後半で、Signaling Serverについての詳細を説明します。
上記のテクノロジーについて簡単に説明します。
SDP（セッション記述プロトコル）
SDPは単純なプロトコルであり、ブラウザでサポートされているコーデックに使用されます。たとえば、WebRTCを介して接続される2つのピア（Client AおよびClient B）があると仮定します。 。クライアントAおよびクライアントBサポートするコーデックを定義するSDP文字列を作成します。たとえば、クライアントAは、ビデオ用のH264、VP8、およびVP9コーデック、オーディオ用のOpusおよびPCMコーデックをサポートします。クライアントBは、ビデオではH264のみ、オーディオではOpusコーデックのみをサポートします。この場合、Client AとClient Bの間で使用されるコーデックはH264とOpusです。ピア間に共通のコーデックがない場合、ピアツーピア通信を確立できません。
これらのSDP文字列が相互に送信される方法について質問がある場合があります。これは、Signaling Serverが行われる場所です。
ICE（インタラクティブ接続の確立）
ICEは、ピアがNATの背後にある場合でもピア間の接続を確立する魔法です。もう一度Client AおよびClient Bが接続され、ICEがどのように使用されるかを見てみましょう。
クライアントAは、STUNサーバーを使用してローカルアドレスとパブリックインターネットアドレスを見つけ、これらのアドレスをクライアントBに送信しますシグナリングサーバーを介して。 STUNサーバーから受信した各アドレスはICE候補と呼ばれます
![]()
上の画像では、2つのサーバーがあります。 1つはSTUNで、もう1つはTURNサーバーです。
STUNサーバーは、クライアントAにすべてのアドレスを学習させるために使用されます。この例を挙げましょう。私たちのコンピューターは一般に192.168.0.0ネットワークに1つのローカルアドレスを持ち、接続すると2番目のアドレスがあります www.whatismyip.com 、このIPアドレスは実際にはインターネットゲートウェイ（モデム、ルーターなど）のパブリックIPアドレスなので、STUNサーバーを定義しましょう。 STUNサーバーは、ピアにパブリックIPアドレスとローカルIPアドレスを知らせます。ところで、Googleは無料のSTUNサーバー（stun.l.google.com:19302）を提供しています。
イメージにはもう1つのサーバー、TURN Serverがあります。 TURN Serverは、ピア間でピアツーピア接続を確立できない場合に使用されます。 TURNサーバーはピア間でデータを中継するだけです。
クライアントBは同じことを行い、STUNサーバーからローカルIPアドレスとパブリックIPアドレスを取得し、これらのアドレスをクライアントAに送信しますシグナリングサーバーを介して。
クライアントAはクライアントBのアドレスを受け取り、接続を作成するために特別なpingを送信して各IPアドレスを試しますClient B。クライアントAが任意のIPアドレスから応答を受信した場合、そのアドレスを、応答時間とその他のパフォーマンス資格情報と共にリストに入れます。最後にクライアントAパフォーマンスに応じて最適なアドレスを選択します。
クライアントBは、クライアントAに接続するために同じことを行います
RTP（リアルタイムプロトコル）
RTPは、リアルタイムデータを送信するための成熟したプロトコルです。 UDPに基づいています。オーディオとビデオは、WebRTCのRTPで送信されます。 RTP通信でQoSを提供するRTCP（Real-time Control Protocol）という名前のRTPの姉妹プロトコルがあります。 RTPはRTSP（リアルタイムストリーミングプロトコル）でも使用されます
シグナリングサーバー
最後の部分は、WebRTCで定義されていないシグナリングサーバーです。上記のように、Signaling Serverは、Client AとClient Bの間でSDP文字列とICE候補を送信するために使用されます。また、シグナリングサーバーは、どのピアが相互に接続するかを決定します。 WebSocketテクノロジは、一般的にシグナリングサーバーで通信に使用されます。
互換性
過去1年間で、Safari、Edgeを含むすべてのブラウザーがWebRTCをサポートする新しいバージョンをリリースしました。 Chrome、Firefox、およびOperaは、しばらくの間、すでにWebRTCをサポートしています。ブラウザーに共通のビデオコーデックはH264です。オーディオの場合、Opusはブラウザーで一般的です。 PCMはオーディオコーデックにも使用できますが、ライセンスの問題により、すべてのブラウザーでAACがサポートされている場合でも、AACは使用されません。 IPカメラは通常、ビデオコーデックにはH264、オーディオコーデックにはPCMまたはAACをサポートしています。
参考文献と参考文献
ところで、私は Ant Media Server の開発者です。これは、スケーラブルな1対多のWebRTCおよびピアツーピアWebRTC接続をサポートしています