Meine Blog-Beiträge

Was ist WebRTC ?

Was ist WebRTC ?


WebRTC ist ein Open-Source-Projekt, das derzeit in Entwicklung ist, um Peer-to-Peer-Kommunikation zwischen Webanwendungen in Echtzeit bereitzustellen.

WebRTC bietet einfache JavaScript-APIs, mit denen Entwickler Webanwendungen mit Echtzeit-Audio-, Video- und Datenübertragungsfunktionen erstellen können. Die jüngsten Entwicklungen in WebRTC haben auch seine Einbeziehung in lokale Anwendungen sichergestellt. Da es so viel unter der API-Überschrift gibt, ist es wichtig, das Konzept und den Betrieb von WebRTC zu verstehen, um die Vorteile der Technologie voll auszuschöpfen.

Um eine WebRTC-Verbindung herzustellen, müssen wir die folgenden beiden Schritte ausführen:

  1. Suchen Sie einen Peer.

Schritt 1: Suchen eines Peers

Betrachten Sie es als einen Telefonanruf, wenn Sie mit jemandem am Telefon sprechen müssen, wählen Sie die Telefonnummer der anderen Person und verbinden sich mit dieser Person. Dasselbe passiert, wenn dich jemand anrufen will. Bei der Mobilkommunikation verwenden wir Handy-/Telefonnummern als Benutzer-ID. Diese Beschreibung wird auch von Telekommunikationssystemen verwendet, um einen Benutzer zu finden.

Webanwendungen können jedoch nicht nacheinander suchen und suchen. Jedem der Millionen Browser auf der ganzen Welt ist keine eindeutige ID (z. B. eine Telefonnummer) zugewiesen. Dem System mit diesen Anwendungen wird jedoch eine eindeutige IP-Adresse zugewiesen, die zum Auffinden einer Frau verwendet werden kann.

Dieser Prozess ist jedoch nicht so einfach, wie es scheint. Da die meisten dieser Systeme Netzwerkadressübersetzung (NAT) Gerät. hinter ihm sitzen Nat-Geräte sind für Sicherheits- und IPv4-Einschränkungen für verfügbare öffentliche IP-Adressen erforderlich. Ein NAT-Gerät löst IP-Adressen aus, die für Systeme in einem lokalen Netzwerk spezifisch sind. Diese privaten IP-Adressen sind gültig und nur innerhalb des lokalen Netzwerks sichtbar, und Systeme außerhalb des Netzwerks können nicht verwendet werden, um Kommunikationen von der Außenwelt zu akzeptieren, da sie die öffentliche IP-Adresse von Geräten innerhalb des Netzwerks nicht kennen.

Aufgrund der Teilnahme von NAT-Geräten kennt ein Peer seine öffentliche IP-Adresse nicht, da sie durch eine private IP-Adresse maskiert sind, die von NAT zugewiesen wurde. Daher kann sie die öffentliche IP-Adresse nicht mit einem anderen Peer teilen, um Verbindungen zu akzeptieren. Genauer gesagt, wenn Sie möchten, dass jemand Sie anuns anuns tauft, müssen Sie Ihre Telefonnummer der anderen Person geben. In Anwesenheit von NAT werden eingehende Anrufe zum Hotel jedoch an der Rezeption abgewickelt und auf Anfrage auch auf Ihr Zimmer weitergeleitet, z. B. in einem Hotel, in dem die Telefonnummer Ihres Zimmers von der Außenwelt verborgen ist. Diese Art des indirekten Verbindungsformats ist in einer End-to-End-Verbindungstechnologie nicht vorgesehen.

Um darüber hinwegzukommen Interaktive Verbindungsorganisation (ICE) wir verwenden ein Protokoll namens Die Aufgabe von ICE ist es, den bestmöglichen Weg zu finden, die beiden Peers zu verbinden. ICE kann direkte Verbindungen, d.h. in Abwesenheit von NAT und auch indirekte Verbindungen, d.h. in Gegenwart eines NAT, durchführen. Der ICE-Rahmen bietet uns "ICE-Kandidaten". "ICE-Kandidaten" sind nichts anderes als Objekte, die unsere eigene öffentliche IP-Adresse, Portnummer und andere verbindungsbezogene Informationen enthalten.

In Ermangelung von NAT ist ICE ziemlich einfach, da die öffentliche IP-Adresse der Frau fertig ist. In Anwesenheit von NAT, ICE Sitzungsmigrationsdienstprogramme für (STUN) und/oder Verwenden von Relais um NAT (TURN) Übergang auf sogenannten Entitäten basieren.

Ein STUN-Server ermöglicht es einer Frau im Grunde, ihre eigene öffentliche IP-Adresse zu finden. Ehepartner, die ihre öffentliche IP-Adresse kennen müssen, senden eine Anforderung an den STUN-Server. Der STUN-Server antwortet mit der öffentlichen IP-Adresse dieser Frau. Diese öffentliche Adresse kann jetzt mit anderen Kollegen geteilt werden, damit sie Sie finden können. Wenn sich der Peer jedoch hinter einem komplexen NAT und/oder einer Firewall befindet, kann selbst STUN den anfordernden Peer nicht finden und die IP-Adresse angeben. In solchen Fällen vertraut ICE TURN, um die Verbindung herzustellen. TURN ist, wie der Name schon sagt, ein Übertragungsserver und arbeitet als Vermittler für Daten-, Audio- und Videoübertragung, wenn eine direkte Verbindung zwischen zwei Ehepartnern nicht möglich ist.

Der STUN-Server ist nur am gesamten IP-Ermittlungsprozess beteiligt. Nachdem die WebRTC-Verbindung hergestellt wurde, erfolgt die gesamte andere Kommunikation über WebRTC. Im Fall von TURN ist jedoch webrtc im gesamten TURN-Server auch nach dem Herstellen der Verbindung erforderlich.

Ein TURN-Server ist nicht vorgesehen, aber wir müssen uns aufgrund von STUN-Einschränkungen darauf verlassen. Ein STUN-Server ist nur etwa 86 % der Zeit erfolgreich.

"ICE ist kompliziert, weil wir in einer komplexen Welt leben."

Schritt 2: Benachrichtigen einer Frau, eine WebRTC-Verbindung herzustellen

Jetzt, da wir Eiskandidaten haben, besteht der nächste Schritt darin, sie an einen Peer zu senden, mit dem wir uns verbinden möchten. Sitzungskommentare wie Sitzungsinformationen, Zeitbeschreibung, Medienbeschreibung werden mit den Kandidaten gesendet. ICE-Kandidaten und Sitzungsbeschreibungen werden in einem Objekt und Session Disclosure Protocol (SDP) übertragen mit In einigen Fällen werden ICE-Kandidaten nicht einzeln auf dem gleichen Objekt wie die Session Description, die Trickle ICE genannt wird (dies ist ein völlig neues Konzept, lassen Sie uns nicht in die Tiefe gehen für jetzt!).

Ich schrieb, dass wir die Informationen an den anderen Peer "senden" sollten. Wie übertragen Sie Kandidaten und Sitzungsbeschreibungen jedoch nur, wenn wir die IP-Adresse des Absenders kennen und die IP-Adresse der Empfängerin nicht kennen? Da die WebRTC-Verbindung noch nicht hergestellt wurde, in welchen Medien werden diese Informationen bewertet?

Die Antwort auf all diese Fragen lautet: Signalmechanismus liegt in einem Konzept namens Bevor eine WebRTC-Verbindung hergestellt wird, benötigen wir ein Medium, um die oben genannten Informationen zwischen Ehegatten zu übertragen und sie darüber zu informieren, wie sie für eine WebRTC-Verbindung eine Verbindung zueinander finden und miteinander herstellen können. Hier kommt der Signalmechanismus ins Spiel. Wie der Name schon sagt, signalisiert ein Signalmechanismus die Verbindung zwischen zwei Ehepartnern, die eine Verbindung anstreben (ICE-Kandidaten, Sitzungsbeschreibung usw.). Änderungen.

WebRTC definiert keine Standards für die Implementierung eines solchen Signalisierungsmechanismus und überlässt es dem Entwickler, einen Mechanismus seiner Wahl zu erstellen. Der Signalmechanismus für den Informationsaustausch, entweder durch Kopieren und Einfügen der Informationen an die betreffenden Ehepartner oder durch Websockets, Socket.io, Server Side Events usw. Es kann über einen Kommunikationskanal durchgeführt werden, z. B.. Kurz gesagt, ein Signalmechanismus ist nur ein Modus. Der Austausch von Informationen über die Verbindung zwischen Ehegatten erfolgt, so dass die Ehegatten sich gegenseitig identifizieren und mehr kommunikation über WebRTC beginnen können.



Diesen Artikel teilen


Kommentare (0)

Kommentar