Die europäischen Internetnutzer sind zweigeteilt: Laut einer Umfrage des Instituts für Meinungsanalyse in Allenbach (Deutschland) sind Skype, Chat und Instant Messaging-Systeme für 16,5 Millionen Erwachsene und 9 Millionen Kinder zu einem festen Bestandteil des Alltags geworden nutzen diese Dienste von Fall zu Fall, und 28 Millionen berühren sie nicht.

Die Situation kann sich ändern, da jetzt Firefox integriert ist Echtzeit-Kommunikationstechnologie (WebRTC) sowie der Kunde selbst. Das Starten eines Audio- und Video-Chats ist jetzt nicht schwieriger als das Öffnen einer Website. Dienste wie Facebook und Skype hingegen setzen auf Lösungen mit einem separaten Client und der Erstellung eines Kontos.

WebRTC ist nicht nur einfach zu bedienen. Mit dieser Methode können Sie sogar einstellen direkte Verbindung zwischen zwei Browsern. Somit laufen Audio- und Videodaten nicht über einen Server, auf dem es zu Überlastungen kommen kann oder auf dem der Administrator nicht besonders sensibel auf die Privatsphäre oder den Datenschutz eingeht. Dank der direkten Verbindung erfordert WebRTC keine Registrierung bzw Konto in jedem Dienst.

Um ein Gespräch zu beginnen, müssen Sie nur dem Link folgen. Die Kommunikation bleibt privat weil der Datenstrom verschlüsselt ist. Echtzeitkommunikation über den Browser, Google begann sich bereits 2011 aktiv zu engagieren, als es den Quellcode seiner WebRTC-Implementierung veröffentlichte.

Kurz darauf erhielten Chrome und Firefox eigene WebRTC-Engines. Sie sind derzeit mobile Optionen sowohl mit dieser Technologie als auch mit der WebView 3.6-Engine ausgestattet, die mit Android 5.0 installiert ist, das von Anwendungen verwendet wird.

Für die Echtzeitkommunikation müssen im Webviewer die entsprechenden JavaScript-Schnittstellen implementiert werden. Verwenden von GetUserMedia Software aktiviert die Aufnahme von Audio- und Videoquellen, z. B. Webcam und Mikrofon. RTCPeerConnection ist für den Verbindungsaufbau sowie für die Kommunikation selbst zuständig.

Parallel zur Browserintegration Arbeitsgruppe Das World Wide Web Consortium (W3C) hat den WebRTC-Standardisierungsprozess vorangetrieben. 2015 soll es fertig sein.

WebRTC gibt sich mit wenig zufrieden

Die Nutzung des WebRTC-Dienstes erfordert nicht viele Ressourcen, da der Server nur die Buddies verbindet. Auch der Verbindungsaufbau ist nicht besonders schwierig. Zunächst signalisiert der Browser dem WebRTC-Server, dass er plant, einen Anruf zu initiieren. Es erhält einen HTTPS-Link vom Server – die Verbindung ist verschlüsselt. Diesen Link sendet der Nutzer an seinen Gesprächspartner. Der Browser bittet den Benutzer dann um Erlaubnis, auf die Webcam und das Mikrofon zuzugreifen.

Um eine direkte Streaming-Verbindung mit der anderen Partei herzustellen, erhält der Browser seine IP-Adresse und Konfigurationsdaten vom WebRTC-Dienst. Der Webbrowser des Buddys tut dasselbe.

Damit die Streaming-Verbindung reibungslos funktioniert und in gute Qualität, drei Engines arbeiten im Browser. Zwei von ihnen optimieren und komprimieren Audio- und Videodaten, der dritte ist für deren Transport zuständig. Es sendet Daten per SRTP-Protokoll(Secure Real-time Transport Protocol), das verschlüsseltes Streaming in Echtzeit ermöglicht.

Wenn eine direkte Verbindung fehlschlägt, sucht WebRTC nach einem anderen Pfad. Dies geschieht beispielsweise, wenn Netzwerkeinstellungen verhindern, dass der STUN-Server die IP-Adresse melden kann. Der WebRTC-Standard sieht vor, dass in diesem Fall die Konversation stattfindet, jedoch unter zwischengeschalteter Einbeziehung des TURN-Servers (Traversal Using Relays around NAT). Auf der Website netscan.co können Sie also überprüfen, ob WebRTC auf Ihrem Computer und mit Ihrem Zugriff auf das Web implementiert ist.

Wie die Verbindung hergestellt wird

Zuerst müssen Sie ein Gespräch registrieren (1). Der WebRTC-Dienst stellt einen Link bereit, der an den Gesprächspartner gesendet werden muss. Der Browser ermittelt über den STUN-Server seine eigene IP-Adresse (2), sendet sie an den Dienst und erhält die IP des Partners, um eine direkte Verbindung herzustellen (3). Wenn STUN fehlschlägt, wird die Konversation über den TURNserver umgeleitet (4).

Kommunikation durch WebRTC-Technologien im Browser wird mit JavaScript-Code gestartet. Danach sind drei Engines für die Kommunikation zuständig: Die Voice- und Video-Engines sammeln Multimediadaten von Webcam und Mikrofon, die Transport-Engine kombiniert die Informationen und versendet den Stream verschlüsselt über das Secure Real-Time Protocol (SRTP).

Welche Browser funktionieren mit WebRTC

Chrome und Firefox sind mit einer WebRTC-Engine ausgestattet, die Dienste wie talky.io nutzt. Der Mozilla-Browser kann direkt mit seinem eigenen Client arbeiten.

Google und Mozilla entwickeln die Idee der Echtzeitkommunikation weiter: Chrome kann eine WebRTC-Konferenz mit mehreren Teilnehmern veranstalten, und der neue Hello-Client in Firefox wird mit Hilfe einer Tochtergesellschaft des Telekommunikationsgiganten Telefonica entwickelt. Apple bleibt vorerst abseits, WebRTC sollte man in Safari noch nicht erwarten. Es gibt jedoch viele alternative iOS-Apps und Plugins für Safari.

Microsoft geht einen etwas anderen Weg. Als Besitzer des konkurrierenden Skype-Dienstes wird dieses Unternehmen nicht so leicht vor WebRTC kapitulieren. Stattdessen entwickelt Microsoft eine Technologie namens ORTC (Object Real-Time Communications) dazu Internet Explorer.

Unterschiede zu WebRTC, wie unterschiedliche Codecs und Protokolle zur Kontaktaufnahme mit dem Server, sind gering und werden im Laufe der Zeit wahrscheinlich zum WebRTC-Standard hinzukommen, der diese Unterschiede beinhalten wird. Somit bleibt nur Apple zurück - wie üblich.

Ein Foto: produzierende Unternehmen; goodluz/Photolia.com

Hallo Freunde, wie Sie bereits wissen, aktualisieren wir Sie regelmäßig mit neuen Technologien, heute werde ich WebRTC vorstellen, eine Technologie, die von entwickelt wurde Google, die es Benutzern ermöglicht, direkt im Browser Video und Audio zu sprechen, ohne dass die Verwendung von Plugins - Websites oder Anwendungen - erforderlich ist. Die Video- und Audio-Direktverbindung zwischen Benutzern findet direkt im Browser statt.
Von Mozilla unterstützte WebRTC-Technologie Firefox-Browser Google Chrome und für jeden Betriebssystem, Opera wird bald beitreten.
Was ist WebRTC und was?
WebRTC ist die Abkürzung für Web Real Time Communication, diese Technologie ermöglicht es Ihnen, Audio- und Video-Chats direkt im Browser zu öffnen, ohne dass dafür andere Plug-Ins, Anwendungen oder Dienste im Internet erforderlich sind. Die Verbindung erfolgt direkt von Browser zu Browser.
Wo bekannte Dienste (Skype, Yahoo Messenger, Apple FaceTime, Google Hago usw.) einen Server benötigen, der Benutzer verbindet, um Datenverkehr zu initiieren und zu verwalten. Bei der Nutzung dieser Dienste müssen wir uns registrieren und eine Liste mit Kunden und Kontakten erstellen.
Mit WebRTC brauchen wir keine Server, Anwendungen oder Server, die sich verbinden, um einzugreifen.
Vorteile von WebRTC:
1. Keine Apps mehr, die Ressourcen und Akkuverbrauch verbrauchen.
2. Chats sind privater (relativ).
3. Der Kontakt kann lokal hergestellt werden, nicht Flos US-Server für lokale Verbindungen.
4. Einfachheit, Benutzerfreundlichkeit.
5. Gelegenheit weitere Entwicklung, und in andere Richtungen.
6. Die Kommunikation ist stabil und unabhängig von externe Verbindungen die teilweise extrem instabil sind.
Im Tutorial habe ich eine Demo verwendet, die Leute bei Google entwickelt haben, diese Demo ist ziemlich einfach, erweiterte Funktionen und schnellere Verbindungen können eine der Anwendungen verwenden, die WebRTC unterstützen, sie sind einfacher zu bedienen. Bald werden wir auch ein Tutorial über WebRTC-Anwendungen erstellen.
Wie verwende ich die WebRTC-Demo?
Klicken Sie ganz einfach auf den unten stehenden Link, es wird automatisch ein Chat generiert. Um diesen Raum zu verknüpfen, müssen Sie einen Freund / eine Freundin senden, mit der Sie Kontakt aufnehmen möchten.
Freund/Freundin und Ihre, aber Sie sollten nur die meisten verwenden letzte Version Mozilla-Firefox oder Google Chrome.

Demo-WebRTC(Einführungschat Audio - Video)

Aufmerksamkeit:
Die Demo ist nicht sehr stabil, sie dient nur zu Demonstrationszwecken. Es kann für einen begrenzten Zeitraum verwendet werden, in dem kleine Verbindungsfehler auftreten können.
Wenn Sie Verbindungsprobleme haben, versuchen Sie, einen anderen Chat zu erstellen.

Heute ist WebRTC die „heiße“ Technologie zum Streamen von Audio und Video in Browsern. Konservative Technologien wie z HTTP-Streaming und Flash eignen sich eher für die Verbreitung von aufgezeichneten Inhalten (Video on Demand) und sind WebRTC in Sachen Echtzeit- und Online-Broadcasts deutlich unterlegen, d.h. wo eine minimale Videolatenz erforderlich ist, sodass die Zuschauer "live" sehen können, was passiert.

Die Möglichkeit einer qualitativ hochwertigen Echtzeitkommunikation ergibt sich aus der WebRTC-Architektur selbst, wo das UDP-Protokoll zum Transport von Videostreams verwendet wird, das die Standardbasis für die Übertragung von Videos mit minimalen Verzögerungen darstellt und in Echtzeitkommunikationssystemen weit verbreitet ist.

Die Kommunikationslatenz ist wichtig in Live-Streaming-Systemen, Webinaren und anderen Anwendungen, bei denen eine interaktive Kommunikation mit der Videoquelle, den Endbenutzern und der Lösung erforderlich ist.

Ein weiterer guter Grund, WebRTC auszuprobieren, ist definitiv ein Trend. Jedes Android heute Chrome-Browser unterstützt diese Technologie, die sicherstellt, dass Millionen von Geräten bereit sind, die Sendung anzusehen, ohne zusätzliche Software und Konfigurationen zu installieren.

Um die WebRTC-Technologie in Aktion zu testen und eine einfache Online-Übertragung darauf zu starten, haben wir die Serversoftware Flashphoner WebRTC Media & Broadcasting Server verwendet. Die Funktionen deklarieren die Fähigkeit, WebRTC-Streams im One-to-Many-Modus zu übertragen, sowie die Unterstützung von IP-Kameras und Videoüberwachungssystemen über das RTSP-Protokoll; In diesem Test konzentrieren wir uns auf Web-Web-Broadcasts und ihre Funktionen.

Installieren von WebRTC Media & Broadcasting Server

Denn für Windows-Systeme es gab keine Serverversion, und ich wollte keine virtuelle Maschine wie VMWare + Linux installieren, Online-Sendungen bei mir zu Hause testen Windows-Rechner hat nicht funktioniert. Um Zeit zu sparen, haben wir uns für eine Instanz des Cloud-Hostings wie folgt entschieden:

Es war ein Centos x86_64 Version 6.5 ohne vorinstallierte Software in einem Amsterdamer Rechenzentrum. Somit steht uns nur ein Server und ein ssh-Zugriff darauf zur Verfügung. Für Kenner Konsolenbefehle Linux verspricht die Installation eines WebRTC-Servers einfach und schmerzlos zu sein. Was wir also gemacht haben:

1. Archiv herunterladen:

$wget https://website/download-wcs5-server.tar.gz

2. Auspacken:

$tar -xzf download-wcs5-server.tar.gz

3. Installieren:

$cd FlashphonerWebCallServer

Geben Sie während der Installation die IP-Adresse des Servers ein: XXX.XXX.XXX.XXX

4. Lizenz aktivieren:

$cd /usr/local/FlashphonerWebCallServer/bin

$./aktivierung.sh

5. WCS-Server starten:

$service webcallserver starten

6. Prüfprotokoll:

$tail - f /usr/local/FlashphonerWebCallServer/logs/flashphoner_manager.log

7. Überprüfen Sie, ob zwei Prozesse vorhanden sind:

$ps zusätzl. | grep Flashphoner

Der Installationsvorgang ist abgeschlossen.

Testen von WebRTC-Livestreams

Das Testen von Sendungen erwies sich als eine einfache Angelegenheit. Neben dem Server gibt es einen Webclient, der aus einem Dutzend Javascript-, HTML- und CSS-Dateien besteht und von uns während der Installationsphase im Ordner /var/www/html bereitgestellt wurde. Es musste lediglich die IP-Adresse des Servers in die flashphoner.xml-Config eingetragen werden, damit der Webclient über HTML5-Websockets eine Verbindung zum Server aufbauen konnte. Lassen Sie uns den Testprozess beschreiben.

1. Öffnen Sie die Seite index.html des Testclients im Chrome-Browser:

2. Um mit der Übertragung zu beginnen, müssen Sie auf die Schaltfläche „Start“ in der Mitte des Bildschirms klicken.
Bevor Sie dies tun, müssen Sie sicherstellen, dass die Webcam angeschlossen und einsatzbereit ist. Es gibt keine besonderen Anforderungen an eine Webcam, wir haben beispielsweise eine standardmäßig eingebaute Laptop-Kamera mit einer Auflösung von 1280 × 800 verwendet.

Der Chrome-Browser wird auf jeden Fall nach dem Zugriff auf die Kamera und das Mikrofon fragen, damit der Benutzer versteht, dass sein Video an den Internetserver gesendet wird, und ihm dies ermöglicht.

3. Die Schnittstelle stellt eine erfolgreiche Übertragung des Videostreams von der Kamera an den WebRTC-Server dar. In der oberen rechten Ecke zeigt die Anzeige an, dass der Stream zum Server geht, in der unteren Ecke befindet sich eine Schaltfläche "Stop", um das Senden des Videos zu stoppen.

Schauen Sie sich den Link unten an. Es enthält eine eindeutige Kennung für diesen Stream, sodass jeder an der Ansicht teilnehmen kann. Öffnen Sie einfach diesen Link in einem Browser. Um es in die Zwischenablage zu kopieren, müssen Sie auf die Schaltfläche "Kopieren" klicken.

In realen Anwendungen wie Webinaren, Vorträgen, Online-Videoübertragungen oder interaktivem Fernsehen müssen Entwickler die Verteilung dieser Kennung an bestimmte Zuschauergruppen implementieren, damit diese sich mit den gewünschten Streams verbinden können, aber dies ist die Logik der Anwendung. WebRTC Media & Broadcasting Server es betrifft nicht, sondern befasst sich nur mit der Verbreitung von Videos.

5. Die Verbindung wird hergestellt und der Zuschauer sieht den Stream auf dem Bildschirm. Jetzt kann er den Link an jemand anderen senden, die Wiedergabe des Streams stoppen oder aktivieren Vollbildmodus Verwenden Sie die Steuerelemente in der unteren rechten Ecke.

Testergebnisse des WebRTC-Servers für Online-Sendungen

Während der Tests schien die Latenz perfekt zu sein. Der Ping zum Rechenzentrum betrug etwa 100 Millisekunden und die Verzögerung war mit dem Auge nicht sichtbar. Von hier aus können wir davon ausgehen, dass die tatsächliche Verzögerung die gleichen 100 plus oder minus einige zehn Millisekunden für die Pufferzeit ist. Im Vergleich zu Flash-Video schneidet Flash in diesen Tests nicht so gut ab wie WebRTC. Wenn Sie also Ihre Hand in einem ähnlichen Netzwerk bewegen, ist die Bewegung auf dem Bildschirm erst nach ein / zwei Sekunden zu sehen.

In Bezug auf die Qualität stellen wir fest, dass Sie manchmal Würfel auf Bewegungen unterscheiden können. Dies entspricht der Natur des VP8-Codecs und sein Hauptziel ist die Bereitstellung von Echtzeit-Videokommunikation mit akzeptabler Qualität und ohne Kommunikationsverzögerungen.

Der Server ist recht einfach zu installieren und zu konfigurieren, es sind keine ernsthaften Kenntnisse erforderlich, um ihn auszuführen, außer Linux-Kenntnissen auf dem Niveau eines fortgeschrittenen Benutzers, der Befehle von der Konsole über ssh ausführen und verwenden kann Texteditor. Als Ergebnis ist es uns gelungen, eine Eins-zu-Viele-Online-Übertragung zwischen Browsern einzurichten. Auch das Verbinden weiterer Viewer mit dem Stream bereitete keine Probleme.

Die Übertragungsqualität erwies sich für Webinare und Online-Übertragungen als durchaus akzeptabel. Das einzige, was einige Fragen aufwarf, war die Auflösung des Videos. Die Kamera unterstützt 1280x800, aber die Auflösung auf dem Testbild ist 640x480 sehr ähnlich. Offenbar muss diese Frage mit den Entwicklern geklärt werden.

Video zum Testen der Übertragung von einer Webcam
über WebRTC-Server

Das meiste Material auf WebRTC konzentriert sich auf die Anwendungsebene des Schreibens von Code und trägt nicht zum Verständnis der Technologie bei. Lassen Sie uns versuchen, tiefer zu gehen und herauszufinden, wie die Verbindung zustande kommt, was der Sitzungsdeskriptor und die Kandidaten sind BETÄUBEN und DREHEN Server.

WebRTC

Einführung

WebRTC ist eine browserbasierte Technologie, mit der Sie zwei Clients zur Videodatenübertragung verbinden können. Die Hauptmerkmale sind interne Browserunterstützung (keine Notwendigkeit für eingebettete Technologien von Drittanbietern wie z Adobe Flash ) und die Fähigkeit, Clients zu verbinden, ohne zusätzliche Server zu verwenden - Verbindung Peer-To-Peer(Des Weiteren, p2p).

Stellen Sie eine Verbindung her p2p- eine ziemlich schwierige Aufgabe, da Computer nicht immer öffentlich sind IP Adressen, also Adressen im Internet. Aufgrund der geringen Menge IPv4 Adressen (und aus Sicherheitsgründen) wurde ein Mechanismus entwickelt NAT, mit dem Sie private Netzwerke erstellen können, beispielsweise für den Heimgebrauch. Viele Heimrouter unterstützen jetzt NAT und dank dessen haben alle Heimgeräte Zugang zum Internet, obwohl Internetanbieter normalerweise einen bereitstellen IP die Anschrift. Öffentlichkeit IP Adressen sind im Internet einzigartig, private Adressen jedoch nicht. Also verbinden p2p- schwierig.

Um dies besser zu verstehen, betrachten Sie drei Situationen: Beide Knoten befinden sich im selben Netzwerk (Bild 1), beide Knoten befinden sich in unterschiedlichen Netzwerken (einer privat, der andere öffentlich) (Bild 2) und beide Knoten sind in verschiedenen privaten Netzwerken mit demselben IP Adressen (Figur 3).

Abbildung 1: Beide Knoten im selben Netzwerk

Abbildung 2: Knoten in verschiedenen Netzwerken (einer privat, einer öffentlich)

Abbildung 3: Knoten in verschiedenen privaten Netzwerken, aber mit numerisch gleichen Adressen

In den obigen Abbildungen gibt der erste Buchstabe in der Zwei-Zeichen-Notation den Knotentyp an (p = Peer, r = Router). In der ersten Abbildung ist die Situation günstig: Knoten in ihrem Netzwerk werden vollständig durch Netzwerk identifiziert IP Adressen und können sich somit direkt miteinander verbinden. In der zweiten Abbildung haben wir zwei verschiedene Netzwerke mit ähnlichen Knotennummern. Router (Router) erscheinen hier, die zwei haben Netzwerkschnittstelle- innerhalb Ihres Netzwerks und außerhalb Ihres Netzwerks. Deshalb haben sie zwei IP Adressen. Reguläre Knoten haben nur eine Schnittstelle, über die sie nur in ihrem eigenen Netzwerk kommunizieren können. Wenn sie Daten an jemanden außerhalb ihres Netzwerks übermitteln, dann nur mit Hilfe von NAT innerhalb des Routers (Router) und daher für andere sichtbar unter IP Router-Adresse ist ihre extern IP die Anschrift. Also der Knoten p1 Es gibt Innere IP = 192.168.0.200 und extern IP = 10.50.200.5 , wobei die letzte Adresse auch für alle anderen Hosts in seinem Netzwerk extern ist. Ähnlich verhält es sich mit node p2. Daher ist ihre Verbindung unmöglich, wenn nur ihre internen (eigenen) IP Adressen. Sie können externe Adressen verwenden, also Adressen von Routern, aber da alle Knoten in demselben privaten Netzwerk dieselbe externe Adresse haben, ist dies ziemlich schwierig. Dieses Problem wird durch den Mechanismus gelöst NAT

Was passiert, wenn wir uns trotzdem dafür entscheiden, die Knoten über ihre internen Adressen zu verbinden? Die Daten verlassen das Netzwerk nicht. Um den Effekt zu verstärken, können Sie sich die in der letzten Abbildung gezeigte Situation vorstellen – beide Knoten haben die gleichen internen Adressen. Wenn sie sie zur Kommunikation verwenden, kommuniziert jeder Knoten mit sich selbst.

WebRTC bewältigt solche Probleme erfolgreich mit dem Protokoll EIS, was allerdings den Einsatz zusätzlicher Server erfordert ( BETÄUBEN, DREHEN). All dies unten.

Zwei Phasen von WebRTC

Um zwei Knoten über ein Protokoll zu verbinden WebRTC(oder einfach RTC wenn zwei verbunden sind IPhone„a) Es ist notwendig, einige durchzuführen vorläufige Maßnahmen um eine Verbindung herzustellen. Dies ist die erste Phase – Aufbau einer Verbindung. Die zweite Phase ist die Übertragung von Videodaten.

Es sollte gleich gesagt werden, obwohl Technologie WebRTC in seiner Arbeit verwendet viele verschiedene Wege Kommunikation ( TCP und UDP) und hat eine flexible Umschaltung zwischen ihnen, diese Technologie verfügt über kein Protokoll zur Weitergabe von Verbindungsdaten. Kein Wunder, denn zwei Knoten verbinden p2p nicht so einfach. Daher ist es notwendig, einige zu haben zusätzlich Methode der Datenübertragung, nicht im Zusammenhang mit WebRTC. Es kann ein Socket-Transfer-Protokoll sein HTTP, es kann sogar ein Protokoll sein SMTP oder Russische Post. Dieser Übertragungsmechanismus primär Daten aufgerufen werden Signal. Es müssen nicht viele Informationen übertragen werden. Alle Daten werden als Text übertragen und in zwei Typen unterteilt − SDP und Eiskandidat. Der erste Typ wird verwendet, um eine logische Verbindung herzustellen, und der zweite für eine physische Verbindung. Dazu später mehr, aber im Moment ist es wichtig, sich daran zu erinnern WebRTC gibt uns einige Informationen, die an einen anderen Knoten übertragen werden müssen. Sobald wir alle notwendigen Informationen übermittelt haben, können sich die Knoten verbinden und unsere Hilfe wird nicht mehr benötigt. Also den Signalmechanismus, den wir implementieren müssen separat, verwendet werden nur wenn angeschlossen, und wird bei der Übertragung von Videodaten nicht verwendet.

Betrachten wir also die erste Phase, die Phase des Verbindungsaufbaus. Es besteht aus mehreren Artikeln. Betrachten Sie diese Phase zuerst für den Knoten, der die Verbindung initiiert, und dann für den wartenden.

• Initiator (Anrufer - Anrufer):
  1. Angebot zum Start der Videodatenübertragung (createOffer)
  2. Holen Sie sich Ihre SDP SDP)
  3. Holen Sie sich Ihre Ice-Kandidat Ice-Kandidat)
• Anklopfen ( Angerufener):
  1. Lokalen (eigenen) Medienstream abrufen und zur Übertragung einstellen (getUserMediaStream)
  2. Erhalten Sie ein Angebot, eine Videodatenübertragung zu starten und eine Antwort zu erstellen (createAnswer)
  3. Holen Sie sich Ihre SDP Objekt und leitet es durch den Signalmechanismus ( SDP)
  4. Holen Sie sich Ihre Ice-Kandidat Objekte und ihre Übertragung durch den Signalmechanismus ( Ice-Kandidat)
  5. Empfangen eines entfernten (fremden) Medienstroms und Anzeigen auf dem Bildschirm (onAddStream)

Der einzige Unterschied besteht im zweiten Absatz.

Trotz der scheinbaren Komplexität der Schritte gibt es eigentlich drei davon: Senden des eigenen Medienstreams (S. 1), Einstellen der Verbindungsparameter (S. 2-4), Empfangen eines fremden Medienstreams (S. 5). Am schwierigsten ist der zweite Schritt, denn er besteht aus zwei Teilen: dem Aufbau körperlich und logisch Verbindungen. Das erste weist darauf hin Weg, die Pakete durchlaufen müssen, um von einem Netzwerkknoten zum anderen zu gelangen. Der zweite weist darauf hin Video-/Audioparameter- welche Qualität zu verwenden ist, welche Codecs zu verwenden sind.

Mentale Bühne Angebot erstellen oder erstellenAntwort sollten mit den Übergabestufen verbunden werden SDP und Ice-Kandidat Objekte.

Grundlegende Entitäten

Medienstreams (MediaStream)

Die Haupteinheit ist der Medienstrom, dh der Strom von Video- und Audiodaten, Bild und Ton. Es gibt zwei Arten von Medienstreams – lokal und remote. Der lokale empfängt Daten von den Eingabegeräten (Kamera, Mikrofon) und der entfernte über das Netzwerk. Somit hat jeder Knoten sowohl einen lokalen als auch einen entfernten Thread. BEI WebRTC Es gibt eine Schnittstelle für Streams Medienstrom und es gibt auch eine Unterschnittstelle LocalMediaStream insbesondere für Lokaler Faden. BEI JavaScript Sie können nur auf den ersten stoßen, und wenn Sie ihn verwenden lib-Jingle, dann kann auch der zweite angetroffen werden.

BEI WebRTC Es gibt eine ziemlich verwirrende Hierarchie innerhalb des Threads. Jeder Stream kann aus mehreren Medienspuren bestehen ( Medienspur), die wiederum aus mehreren Medienkanälen bestehen kann ( Medienkanal). Und es können auch mehrere Mediastreams selbst sein.

Betrachten wir alles in Ordnung. Um dies zu tun, wollen wir uns ein Beispiel merken. Nehmen wir an, wir wollen nicht nur ein Video von uns übertragen, sondern auch ein Video von unserem Tisch, auf dem ein Blatt Papier liegt, auf das wir etwas schreiben werden. Wir brauchen zwei Videos (wir + Tisch) und ein Audio (wir). Es ist klar, dass wir und die Tabelle in verschiedene Threads aufgeteilt werden sollten, da diese Daten wahrscheinlich schwach voneinander abhängig sind. Deshalb werden wir zwei haben Medienstrom‘a – eine für uns und eine für den Tisch. Die erste enthält sowohl Video- als auch Audiodaten, die zweite nur Video (Abbildung 4).

Abbildung 4: Zwei unterschiedliche Medienströme. Eine für uns, eine für unseren Tisch

Es ist sofort klar, dass der Medienstrom mindestens die Fähigkeit beinhalten muss, Daten zu enthalten verschiedene Typen- Video und Audio. Dies wird in der Technologie berücksichtigt und daher wird jede Art von Daten durch eine Medienspur implementiert. Medienspur. Die Medienspur hat eine besondere Eigenschaft nett, der bestimmt, was vor uns ist - Video oder Audio (Abbildung 5)

Abbildung 5: Mediastreams bestehen aus Mediatracks

Wie wird alles im Programm laufen? Wir werden zwei Medienströme erstellen. Dann erstellen wir zwei Videospuren und eine Audiospur. Lassen Sie uns Zugang zu Kameras und einem Mikrofon erhalten. Sagen wir jedem Track, welches Gerät verwendet werden soll. Fügen wir dem ersten Medienstream eine Video- und Audiospur und dem zweiten Medienstream eine Videospur von einer anderen Kamera hinzu.

Aber wie unterscheiden wir Medienströme am anderen Ende der Verbindung? Dazu hat jeder Medienstrom eine Eigenschaft Etikett– Bezeichnung des Streams, sein Name (Abbildung 6). Medienspuren haben die gleiche Eigenschaft. Obwohl es auf den ersten Blick scheint, dass Video auf andere Weise von Ton unterschieden werden kann.

Abbildung 6: Mediastreams und Tracks werden durch Labels identifiziert

Wenn also Medienspuren durch ein Etikett identifiziert werden können, warum müssen wir dann für unser Beispiel zwei Medienströme verwenden statt nur einem? Schließlich können Sie einen Medienstrom übertragen und darin verschiedene Spuren verwenden. Wir haben erreicht wichtige Eigenschaft Medienströme - sie synchronisieren Medienspuren. Dabei werden nicht verschiedene Medienströme miteinander synchronisiert, sondern innerhalb eines Medienstroms alle Tracks gleichzeitig gespielt.

Wenn wir also wollen, dass unsere Worte, unsere Emotionen im Gesicht und unser Zettel gleichzeitig gespielt werden, dann lohnt es sich, einen Medienstrom zu verwenden. Wenn dies nicht so wichtig ist, ist es rentabler, verschiedene Streams zu verwenden - das Bild wird flüssiger.

Wenn eine Spur während der Übertragung deaktiviert werden muss, können Sie die Eigenschaft verwenden aktiviert Medienspuren.

Am Ende sollten Sie an Stereoton denken. Wie Sie wissen, ist Stereo-Sound zwei unterschiedlicher Klang. Und sie müssen auch separat gesendet werden. Dafür werden Kanäle verwendet. Medienkanal. Eine Audio-Medienspur kann viele Kanäle haben (z. B. 6, wenn Sie 5+1 Audio benötigen). Innerhalb der Medienspur natürlich auch Kanäle synchronisiert. Für Video wird meist nur ein Kanal genutzt, es können aber auch mehrere genutzt werden, beispielsweise für Werbeeinblendungen.

Zusammenfassen: Wir verwenden einen Medienstrom, um Video- und Audiodaten zu übertragen. Innerhalb jedes Medienstreams werden die Daten synchronisiert. Wir können mehrere Medienströme verwenden, wenn wir keine Synchronisierung benötigen. In jedem Medienstrom gibt es zwei Arten von Medienspuren – für Video und für Audio. Normalerweise gibt es nicht mehr als zwei Spuren, aber es können mehr sein, wenn Sie mehrere verschiedene Videos (des Gesprächspartners und seines Tisches) übertragen müssen. Jede Spur kann aus mehreren Kanälen bestehen, was normalerweise nur für Stereoton verwendet wird.

In der einfachsten Video-Chat-Situation haben wir einen lokalen Medienstream, der aus zwei Spuren besteht – einer Videospur und einer Audiospur, die jeweils aus einem Hauptkanal bestehen. Die Videospur ist für die Kamera zuständig, die Audiospur für das Mikrofon und der Medienstream ist der Container für beides.

Sitzungsdeskriptor (SDP)

Bei verschiedene Rechner es wird immer verschiedene Kameras, Mikrofone, Grafikkarten und andere Geräte geben. Es gibt viele Optionen, die sie haben. All dies muss für den Mediendatentransfer zwischen zwei Netzwerkknoten koordiniert werden. WebRTC tut dies automatisch und erstellt ein spezielles Objekt - das Session-Handle SDP. Übergeben Sie dieses Objekt an einen anderen Knoten und Sie können Mediendaten senden. Nur besteht noch keine Verbindung zu einem anderen Knoten.

Dazu wird ein beliebiger Signalisierungsmechanismus verwendet. SDP kann sogar über Steckdosen übertragen werden, sogar von einer Person (teilen Sie es einem anderen Knoten per Telefon mit), sogar von der russischen Post. Alles ist sehr einfach - Sie erhalten ein fertiges Produkt SDP und es muss gesendet werden. Und nach Erhalt auf der anderen Seite - Überweisung an die Abteilung WebRTC. Das Session-Handle wird als Text gespeichert und Sie können es in Ihren Anwendungen ändern, müssen dies aber normalerweise nicht. Wenn Sie beispielsweise Desktop↔Telefon verbinden, müssen Sie manchmal die Auswahl des gewünschten Audio-Codecs erzwingen.

Normalerweise müssen Sie beim Verbindungsaufbau beispielsweise eine Adresse angeben URL. Dies ist hier nicht erforderlich, da Sie selbst die Daten über den Signalisierungsmechanismus an das Ziel senden. Um anzuzeigen WebRTC was wir installieren wollen p2p Verbindung müssen Sie die Funktion createOffer aufrufen. Nachdem Sie diese Funktion aufgerufen und ihr ein Special gegeben haben zurückrufen‘a wird erstellt SDP Objekt und an dasselbe weitergegeben zurückrufen. Sie müssen dieses Objekt lediglich über das Netzwerk an einen anderen Knoten (Gesprächspartner) übertragen. Danach kommen am anderen Ende Daten durch den Signalisierungsmechanismus, nämlich this SDP ein Objekt. Dieser Sitzungsdeskriptor für diesen Knoten ist fremd und trägt daher nützliche Informationen. Der Empfang dieses Objekts ist ein Signal zum Starten der Verbindung. Daher müssen Sie dem zustimmen und die Funktion createAnswer aufrufen. Es ist ein vollständiges Analogon von createOffer . Zurück zu Ihrem zurückrufen wird einen lokalen Sitzungsdeskriptor übergeben und muss durch den Signalisierungsmechanismus zurückgeleitet werden.

Es ist erwähnenswert, dass Sie die createAnswer-Funktion nur aufrufen können, nachdem Sie die von jemand anderem erhalten haben SDP Objekt. Wieso den? Weil lokal SDP Das Objekt, das generiert wird, wenn createAnswer aufgerufen wird, muss sich auf die Fernbedienung verlassen SDP ein Objekt. Nur in diesem Fall ist es möglich, Ihre Videoeinstellungen mit den Einstellungen des Gesprächspartners abzustimmen. Rufen Sie außerdem createAnswer und createOffer nicht auf, bis der lokale Medienstream empfangen wird – sie haben nichts, in das sie schreiben können SDP ein Objekt .

Seit in WebRTC es ist möglich zu bearbeiten SDP Objekt, dann muss es nach Erhalt eines lokalen Handles gesetzt werden. Es mag ein wenig seltsam erscheinen, zu passieren WebRTC was sie uns selbst gegeben hat, aber das ist das Protokoll. Wenn Sie ein Remote-Handle erhalten, müssen Sie es auch festlegen. Daher müssen Sie zwei Deskriptoren auf einem Knoten installieren – Ihren eigenen und den eines anderen (d. h. lokal und entfernt).

Nach so Händedruck Knoten kennen die Wünsche des anderen. Wenn zum Beispiel der Knoten 1 unterstützt Codecs EIN und B, und der Knoten 2 unterstützt Codecs B und C, dann werden, da jeder Knoten seine eigenen und die Deskriptoren eines anderen kennt, beide Knoten einen Codec wählen B(Abbildung 7). Die Verbindungslogik ist nun eingerichtet und Medienströme können übertragen werden, aber es gibt ein weiteres Problem – die Knoten sind immer noch nur durch einen Signalisierungsmechanismus verbunden.

Abbildung 7: Codec-Aushandlung

Kandidaten (Eiskandidat)

Technologie WebRTC versucht, uns mit seiner neuen Methodik zu verwirren. Beim Verbindungsaufbau wird die Adresse des Teilnehmers, mit dem Sie sich verbinden möchten, nicht angegeben. Zuerst installiert logisch Verbindung, nicht körperlich, obwohl immer das Gegenteil gemacht wurde. Dies wird jedoch nicht seltsam erscheinen, wenn wir nicht vergessen, dass wir einen Signalisierungsmechanismus eines Drittanbieters verwenden.

Die Verbindung wurde also bereits hergestellt (logische Verbindung), aber es gibt noch keinen Weg für die Netzwerkknoten, um Daten zu übertragen. Es ist nicht ganz so einfach, aber fangen wir einfach an. Lassen Sie die Knoten im selben privaten Netzwerk sein. Wie wir bereits wissen, können sie sich über ihr Inneres leicht miteinander verbinden IP Adressen (oder vielleicht andere, falls nicht verwendet TCP/IP).

Durch einige zurückrufen'und WebRTC sagt uns Ice-Kandidat Objekte. Sie kommen auch in Textform und müssen genau wie Sitzungsdeskriptoren nur durch den Signalisierungsmechanismus gesendet werden. Wenn der Sitzungsdeskriptor Informationen über unsere Einstellungen auf Kamera- und Mikrofonebene enthielt, dann enthalten die Kandidaten Informationen über unseren Standort im Netzwerk. Übergeben Sie sie an einen anderen Knoten, und er kann sich physisch mit uns verbinden, und da er bereits einen Sitzungsdeskriptor hat, kann er sich logisch verbinden und die Daten werden „fließen“. Wenn er nicht vergisst, uns sein Kandidatenobjekt zu schicken, also Informationen darüber, wo er sich im Netzwerk befindet, können wir uns mit ihm in Verbindung setzen. Wir bemerken hier noch einen weiteren Unterschied zur klassischen Client-Server-Interaktion. Kommunikation mit HTTP-Server nach dem Request-Response-Schema erfolgt, sendet der Client Daten an den Server, der sie verarbeitet und per versendet Adresse, die im Anforderungspaket angegeben ist. BEI WebRTC wissen müssen zwei Adressen und verbinden Sie sie auf beiden Seiten.

Der Unterschied zu Sitzungshandles besteht darin, dass nur entfernte Kandidaten festgelegt werden müssen. Eine Bearbeitung ist hier untersagt und kann keinen Nutzen bringen. In einigen Implementierungen WebRTC Kandidaten müssen nur gesetzt werden, nachdem die Sitzungshandles gesetzt worden sind.

Und warum gab es nur einen Sitzungsdeskriptor, aber es kann viele Kandidaten geben? Denn der Standort im Netzwerk lässt sich nicht nur durch dessen Internes bestimmen IP Adresse, sondern auch die externe Adresse des Routers, und nicht unbedingt eine, sowie die Adressen DREHEN Server. Der Rest des Absatzes ist einer detaillierten Diskussion der Kandidaten und der Verbindung von Knoten aus verschiedenen privaten Netzwerken gewidmet.

Zwei Knoten befinden sich also im selben Netzwerk (Abbildung 8). Wie erkennt man sie? Mit Hilfe IP Adressen. Kein anderer Weg. Sie können zwar immer noch verschiedene Transportmittel verwenden ( TCP und UDP) und verschiedene Ports. Dies sind die Informationen, die im Kandidatenobjekt enthalten sind - IP, HAFEN, TRANSPORT und einige andere. Lassen Sie zum Beispiel verwenden UDP Transport und 531 Hafen.

Abbildung 8: Zwei Knoten befinden sich im selben Netzwerk

Dann, wenn wir in einem Knoten sind p1, dann WebRTC wird uns ein solches Kandidatenobjekt geben - . Dies ist kein genaues Format, sondern nur ein Diagramm. Wenn wir in einem Knoten stecken p2, dann ist der Kandidat . Durch den Signalmechanismus p1 erhält einen Kandidaten p2(d. h. Knotenstandort p2, nämlich seine IP und HAFEN). Wonach p1 mit verbinden kann p2 direkt. Richtiger, p1 sendet Daten an die Adresse 10.50.150.3:531 in der Hoffnung, dass sie ankommen p2. Es spielt keine Rolle, ob diese Adresse zu einem Knoten gehört p2 oder irgendein Vermittler. Wichtig ist nur, dass Daten über diese Adresse gesendet werden und diese erreichen können p2.

Solange sich die Knoten im selben Netzwerk befinden – alles ist einfach und leicht – hat jeder Knoten nur ein Kandidatenobjekt (womit immer sein eigenes gemeint ist, dh sein Standort im Netzwerk). Aber es wird viel mehr Kandidaten geben, wenn die Nodes drin sind anders Netzwerke.

Kommen wir zu einem komplizierteren Fall. Ein Knoten befindet sich hinter dem Router (genauer hinter NAT), und der zweite Knoten befindet sich im selben Netzwerk mit diesem Router (z. B. im Internet) (Abbildung 9).

Abbildung 9: Ein Host hinter NAT, ein anderer nicht

Dieser Fall hat eine spezielle Lösung für das Problem, die wir jetzt betrachten. Ein Heimrouter enthält normalerweise eine Tabelle NAT. Hierbei handelt es sich um einen speziellen Mechanismus, der entwickelt wurde, um Knoten innerhalb des privaten Netzwerks des Routers beispielsweise den Zugriff auf Websites zu ermöglichen.

Nehmen wir an, der Webserver ist direkt mit dem Internet verbunden, hat also eine Öffentlichkeit IP* die Anschrift. Lass es einen Knoten sein p2. Knoten p1(Webclient) sendet eine Anfrage an die Adresse 10.50.200.10 . Zuerst gehen die Daten zum Router r1, oder besser gesagt auf seinem Innere Schnittstelle 192.168.0.1 . Danach merkt sich der Router die Quelladresse (address p1) und trägt sie in eine spezielle Tabelle ein NAT, ändert dann die Quelladresse in ihre eigene ( p1 → r1). Weiter gem extern Schnittstelle sendet der Router Daten direkt an den Webserver p2. Der Webserver verarbeitet die Daten, generiert eine Antwort und sendet sie zurück. Sendet an den Router r1, da er in der Absenderadresse steht (der Router hat die Adresse in seine eigene geändert). Der Router empfängt Daten, schaut auf die Tabelle NAT und sendet die Daten an den Knoten p1. Der Router fungiert hier als Vermittler.

Was aber, wenn mehrere Knoten aus dem internen Netz gleichzeitig auf das externe Netz zugreifen? Wie wird der Router verstehen, an wen er die Antwort zurücksenden soll? Dieses Problem wird mit gelöst Häfen. Wenn der Router die Hostadresse durch seine eigene ersetzt, ersetzt er auch den Port. Wenn zwei Knoten auf das Internet zugreifen, ersetzt der Router ihre Quellports durch verschiedene. Wenn dann das Paket vom Webserver zum Router zurückkommt, erkennt der Router den Port, dem dieses Paket zugewiesen ist. Ein Beispiel ist unten.

Zurück zur Technologie WebRTC, oder besser gesagt, zu seinem Teil, der verwendet EIS Protokoll (also Eis Kandidaten). Knoten p2 hat einen Kandidaten (seine Position im Netzwerk - 10.50.200.10 ) und den Knoten p1, die sich hinter einem Router mit NAT befindet, hat zwei Kandidaten - lokal ( 192.168.0.200 ) und Routerkandidat ( 10.50.200.5 ). Das erste ist nicht sinnvoll, wird aber trotzdem generiert, da WebRTC weiß noch nichts über den Remote-Host - er kann sich im selben Netzwerk befinden oder auch nicht. Der zweite Kandidat wird sich als nützlich erweisen, und wie wir bereits wissen, wird der Hafen eine wichtige Rolle spielen (um durchzukommen NAT).

Tabelleneintrag NAT nur generiert, wenn Daten das interne Netzwerk verlassen. Daher der Knoten p1 muss zuerst die Daten übertragen und erst danach die Daten des Knotens p2 kann zum Knoten gelangen p1.

In der Praxis beide Knoten wird hinterher sein NAT. Um einen Eintrag in einer Tabelle zu erstellen NAT Bei jedem Router müssen die Knoten etwas an den entfernten Knoten senden, aber diesmal kann weder der erste den zweiten erreichen, noch umgekehrt. Dies liegt daran, dass die Knoten ihr Äußeres nicht kennen IP Adressen, und das Senden von Daten an interne Adressen ist sinnlos.

Sind die externen Adressen jedoch bekannt, lässt sich die Verbindung problemlos aufbauen. Wenn der erste Knoten Daten an den Router des zweiten Knotens sendet, ignoriert der Router sie aufgrund seiner Tabelle NAT während leer. Allerdings im Router des ersten Knotens in der Tabelle NAT Es bestand Bedarf an einer Aufzeichnung. Wenn nun der zweite Knoten Daten an den Router des ersten Knotens sendet, dann wird der Router diese erfolgreich an den ersten Knoten übertragen. Jetzt der Tisch NAT Der zweite Router hat die Daten, die Sie brauchen.

Das Problem ist, dass, um Ihr Äußeres zu kennen IP Adresse benötigen Sie einen Knoten, der sich in befindet gemeinsames Netzwerk. Um dieses Problem zu lösen, werden zusätzliche Server verwendet, die direkt mit dem Internet verbunden sind. Mit ihrer Hilfe entstehen auch die wertvollen Rekorde in der Tabelle. NAT.

STUN- und TURN-Server

Bei der Initialisierung WebRTC verfügbar BETÄUBEN und DREHEN Server, auf die wir uns im Folgenden beziehen werden EIS Server. Wenn die Server nicht angegeben sind, dann nur Knoten im selben Netzwerk (daran angeschlossen ohne NAT). Es sei gleich darauf hingewiesen, dass z 3g-Netzwerke müssen verwendet werden DREHEN Server.

BETÄUBEN Server ist nur ein Server im Internet, der zurückkehrt Absender, die die Adresse des Absenderhosts ist. Der Knoten hinter dem Router greift zu BETÄUBEN Server zu durchlaufen NAT. Das Paket, das kam BETÄUBEN server, enthält die Quelladresse - die Adresse des Routers, dh die externe Adresse unseres Knotens. Diese Adresse BETÄUBEN Server und sendet zurück. Somit erhält der Knoten sein Äußeres IP Adresse und Port, über die es vom Netzwerk aus erreichbar ist. Des Weiteren, WebRTC die Verwendung dieser Adresse erstellt einen zusätzlichen Kandidaten (externe Router-Adresse und Port). Jetzt in der Tabelle NAT Der Router hat einen Eintrag, der Pakete, die an den Router auf dem erforderlichen Port gesendet werden, an unseren Knoten weiterleitet.

Sehen wir uns diesen Vorgang anhand eines Beispiels an.

Beispiel (STUN-Serverbetrieb)

BETÄUBEN Der Server wird mit bezeichnet s1. Router, wie zuvor, durch r1, und der Knoten durch p1. Sie müssen auch der Tabelle folgen NAT- Bezeichnen wir es als r1_nat. Außerdem enthält diese Tabelle normalerweise viele Einträge von verschiedenen Subnetzknoten - sie werden nicht angegeben.

Am Anfang haben wir also einen leeren Tisch r1_nat.

Tabelle 2: Paketheader

Knoten p1 sendet dieses Paket an den Router r1(egal wie, unterschiedliche Technologien können in unterschiedlichen Subnetzen verwendet werden). Der Router muss die Quelladresse ersetzen Quell-IP, da die im Paket angegebene Adresse offensichtlich nicht für das externe Subnetz geeignet ist, außerdem sind Adressen aus diesem Bereich reserviert, und keine einzige Adresse im Internet hat eine solche Adresse. Der Router nimmt eine Substitution im Paket vor und erstellt Neuer Eintrag in deinem Tisch r1_nat. Dazu muss er sich eine Portnummer ausdenken. Denken Sie daran, da mehrere Knoten innerhalb eines Subnetzes auf ein externes Netzwerk zugreifen können, dann in der Tabelle NAT sollte zurückgehalten werden Weitere Informationen damit der Router feststellen kann, für welchen dieser mehreren Hosts das Rückpaket vom Server bestimmt ist. Lassen Sie den Router mit einem Port kommen 888 .

Geänderter Paketkopf:

Tabelle 4: NAT-Tabelle mit einem neuen Eintrag aktualisiert

Hier IP Die Adresse und der Port für das Subnetz sind genau die gleichen wie im ursprünglichen Paket. Tatsächlich müssen wir beim Postback eine Möglichkeit haben, sie vollständig wiederherzustellen. IP Die Adresse für das externe Netzwerk ist die Adresse des Routers, und der Port hat sich zu dem vom Router erfundenen geändert.

Der reale Port, an den der Knoten p1 akzeptiert eine Verbindung - dies natürlich 35777 , aber der Server sendet Daten an fiktiv Hafen 888 , die vom Router in die reale geändert werden 35777 .

Also hat der Router die Quelladresse und den Port im Paketheader geändert und der Tabelle einen Eintrag hinzugefügt NAT. Jetzt wird das Paket über das Netzwerk an den Server, also den Knoten, gesendet s1. am Eingang, s1 hat dieses Paket:

Quell-IP	Quelle PORT	Ziel-IP	ZIELHAFEN
10.50.200.5	888	12.62.100.200	6000

Tabelle 5: STUN-Server hat ein Paket empfangen

Gesamt BETÄUBEN der Server weiß, dass er ein Paket von der Adresse erhalten hat 10.50.200.5:888 . Nun sendet der Server diese Adresse zurück. Es lohnt sich, hier innezuhalten und das, was wir gerade betrachtet haben, noch einmal durchzugehen. Die obigen Tabellen sind Bestandteil Header Paket, überhaupt nicht davon Inhalt. Über den Inhalt haben wir nicht gesprochen, da es nicht so wichtig ist - es ist irgendwie im Protokoll beschrieben BETÄUBEN. Nun betrachten wir neben dem Titel auch den Inhalt. Es wird einfach sein und die Adresse des Routers enthalten - 10.50.200.5:888 obwohl wir es abgenommen haben Header Paket. Dies wird nicht oft gemacht, normalerweise kümmern sich Protokolle nicht um die Informationen über die Adressen der Knoten, es ist nur wichtig, dass die Pakete an ihr Ziel geliefert werden. Hier betrachten wir ein Protokoll, das einen Pfad zwischen zwei Knoten herstellt.

Jetzt haben wir also eine zweite Charge, die in die entgegengesetzte Richtung geht:

Tabelle 7: STUN-Server sendet ein Paket mit diesem Inhalt

Als nächstes wandert das Paket durch das Netzwerk, bis es die externe Schnittstelle des Routers erreicht r1. Der Router versteht, dass das Paket nicht für ihn bestimmt ist. Wie versteht er es? Dies kann nur durch den Hafen gefunden werden. Hafen 888 er verwendet nicht für seine persönlichen Zwecke, sondern verwendet für den Mechanismus NAT. Daher schaut der Router in diese Tabelle. Schaut auf die Säule Externer PORT und sucht nach einer passenden Zeichenfolge ZIELHAFEN aus dem eingehenden Paket, das heißt 888 .

interne IP	Interner PORT	externe IP	Externer PORT
192.168.0.200	35777	10.50.200.5	888

Tabelle 8: NAT-Tabelle

Wir haben Glück, dass es eine solche Linie gibt. Wenn es kein Glück hatte, wurde das Paket einfach verworfen. Jetzt müssen Sie verstehen, welcher der Subnetzknoten dieses Paket senden soll. Lassen Sie uns nicht überstürzen, fassen wir die Bedeutung von Ports in diesem Mechanismus noch einmal zusammen. Gleichzeitig könnten zwei Knoten im Subnetz Anfragen an das externe Netzwerk senden. Dann, wenn der Router für den ersten Knoten einen Port gefunden hat 888 , dann würde er für die zweite mit einem Port aufwarten 889 . Angenommen, dies ist passiert, dh der Tisch r1_nat sieht so aus:

Tabelle 10: Router-Spoofing-Empfängeradresse

Quell-IP	Quelle PORT	Ziel-IP	ZIELHAFEN
12.62.100.200	6000	192.168.0.200	35777

Tabelle 11: Der Router hat die Empfängeradresse geändert

Das Paket kommt erfolgreich am Knoten an p1 und indem er sich den Inhalt des Pakets ansieht, erfährt der Knoten von seinem Äußeren IP Adresse, also die Adresse des Routers im externen Netz. Es kennt auch den Port, den der Router durchläuft NAT.

Was kommt als nächstes? Was nützt das alles? Nutzen ist ein Eintrag in der Tabelle r1_nat. Wenn jetzt jemand an den Router senden wird r1 Port-Paket 888 , dann leitet der Router dieses Paket an den Host weiter p1. So wurde ein kleiner schmaler Durchgang zum versteckten Knoten geschaffen p1.

Anhand des obigen Beispiels können Sie sich eine Vorstellung davon machen, wie es funktioniert. NAT und Essenz BETÄUBEN Server. Im Allgemeinen der Mechanismus EIS und STUN/WENDE Server zielen nur darauf ab, Einschränkungen zu überwinden NAT.

Es kann mehr als einen Router zwischen dem Knoten und dem Server geben, aber mehrere. In diesem Fall erhält der Knoten die Adresse des Routers, der als erster in dasselbe Netzwerk wie der Server eindringt. Mit anderen Worten, wir erhalten die Adresse des verbundenen Routers BETÄUBEN Server. Zum p2p Kommunikation ist genau das, was wir brauchen, wenn wir nicht vergessen, dass in jedem Router die Zeile, die wir brauchen, der Tabelle hinzugefügt wird NAT. So wird der Rückweg wieder genauso reibungslos.

DREHEN Server verbessert BETÄUBEN Server. Daraus folgt sofort, dass evtl DREHEN Der Server kann funktionieren und wie BETÄUBEN Server. Allerdings gibt es auch Vorteile. Wenn ein p2p Kommunikation ist nicht möglich (wie in 3g Netzwerke), wechselt der Server in den Repeater-Modus ( Relais), das heißt, es fungiert als Vermittler. Natürlich über jeden p2p dann ist es keine Frage, sondern außerhalb des Rahmens des Mechanismus EIS die Knoten denken, dass sie direkt kommunizieren.

In welchen Fällen ist es notwendig DREHEN Server? Warum ist nicht genug BETÄUBEN Server? Tatsache ist, dass es mehrere Arten gibt NAT. Sie ersetzen die gleichen IP Adresse und Port, aber einige von ihnen haben eingebaute zusätzlicher Schutz von "Fälschung". Zum Beispiel im symmetrisch Tisch NAT 2 weitere Parameter werden gespeichert - IP und Port des entfernten Hosts. Ein Paket aus dem externen Netzwerk wird durchgelassen NAT nur dann in das interne Netzwerk, wenn die Quelladresse und der Port mit denen in der Tabelle übereinstimmen. Daher der Fokus BETÄUBEN Server fällt aus - Tabelle NAT speichert Adresse und Port BETÄUBEN Server und wann der Router ein Paket empfängt WebRTC Gesprächspartner, verwirft er ihn, da er „gefälscht“ sei. Er kam nicht von BETÄUBEN Server.

Auf diese Weise DREHEN Ein Server wird benötigt, wenn beide Gesprächspartner im Rückstand sind symmetrisch NAT(jeder für sich).

Kurze Zusammenfassung

Hier sind einige Aussagen über Entitäten WebRTC was immer im Auge behalten werden muss. Sie sind oben im Detail beschrieben. Wenn Ihnen eine der Aussagen nicht ganz klar erscheint, lesen Sie die entsprechenden Absätze erneut.

• Medienstrom
  • Video- und Audiodaten werden in Mediastreams verpackt
  • Medienströme synchronisieren die Medienspuren, aus denen sie bestehen
  • Verschiedene Medienstreams sind nicht synchron
  • Medienströme können lokal und entfernt sein, eine Kamera und ein Mikrofon sind normalerweise mit dem lokalen verbunden, entfernte erhalten Daten aus dem Netzwerk in verschlüsselter Form
  • Es gibt zwei Arten von Medienspuren – für Video und für Audio.
  • Medienspuren können ein- und ausgeschaltet werden
  • Medienspuren bestehen aus Medienkanälen
  • Medienspuren synchronisieren die Medienkanäle, die sich bilden
  • Medienstreams und Medienspuren haben Labels, anhand derer sie unterschieden werden können
• Sitzungshandle
  • Der Sitzungsdeskriptor wird verwendet, um zwei Netzwerkknoten logisch zu verbinden
  • Der Sitzungsdeskriptor speichert Informationen über verfügbaren Wege Video- und Audiodatenkodierung
  • WebRTC verwendet einen externen Signalisierungsmechanismus - die Aufgabe, Sitzungsdeskriptoren weiterzuleiten ( sdp) fällt auf die Anwendung
  • Der Mechanismus der logischen Verbindung besteht aus zwei Phasen - einem Vorschlag ( Angebot) und Antwort ( Antworten)
  • Die Generierung von Sitzungsdeskriptoren ist ohne die Verwendung eines lokalen Medienstroms im Falle eines Angebots nicht möglich ( Angebot) und ist ohne die Verwendung eines Remote-Session-Deskriptors im Fall einer Antwort ( Antworten)
  • Der resultierende Deskriptor muss der Implementierung übergeben werden WebRTC, und es spielt keine Rolle, ob dieses Handle remote oder lokal von derselben Implementierung abgerufen wird WebRTC
  • Es ist möglich, den Sitzungsdeskriptor leicht zu bearbeiten
• Kandidaten
  • Kandidat ( Ice-Kandidat) ist die Adresse des Knotens im Netzwerk
  • Die Knotenadresse kann Ihre eigene oder die Adresse eines Routers sein DREHEN Server
  • Es gibt immer viele Kandidaten
  • Der Kandidat besteht aus IP Adresse, Hafen und Transportart ( TCP oder UDP)
  • Kandidaten werden verwendet, um eine physische Verbindung zwischen zwei Knoten in einem Netzwerk herzustellen
  • Kandidaten müssen auch durch den Signalisierungsmechanismus gesendet werden
  • Die Kandidaten müssen auch Implementierungen bestehen WebRTC, aber nur entfernt
  • In einigen Implementierungen WebRTC Kandidaten können nur bestanden werden, nachdem der Sitzungsdeskriptor festgelegt wurde
• STUN/ZUG/EIS/NAT
  • NAT– ein Mechanismus zum Bereitstellen des Zugriffs auf ein externes Netzwerk
  • Heimrouter unterstützen eine spezielle Tabelle NAT
  • Der Router ersetzt die Adressen in den Paketen - die Quelladresse durch seine eigene, wenn das Paket ins externe Netz geht, und die Empfängeradresse durch die Hostadresse im internen Netz, wenn das Paket aus dem externen Netz kommt
  • Zur Bereitstellung von Mehrkanalzugriff auf ein externes Netzwerk NAT verwendet Häfen
  • EIS- Bypass-Mechanismus NAT
  • BETÄUBEN und DREHEN server - Hilfsserver zum Umgehen NAT
  • BETÄUBEN Der Server ermöglicht es Ihnen, die erforderlichen Einträge in der Tabelle zu erstellen NAT, und gibt auch die externe Adresse des Knotens zurück
  • DREHEN Server verallgemeinert BETÄUBEN Mechanismus und sorgt dafür, dass es immer funktioniert
  • Im schlimmsten Fall DREHEN Der Server wird als Vermittler verwendet ( Relais), also p2p wird zu einer Client-Server-Client-Verbindung.