Funktionsweise von JS: WebRTC- und P2P-Kommunikation

Heute veröffentlichen wir eine Übersetzung von Teil 18 einer Reihe von Materialien, die sich mit allem befassen, was mit JavaScript zu tun hat. Hier werden wir über die WebRTC-Technologie sprechen, die darauf abzielt, den direkten Datenaustausch zwischen Browseranwendungen in Echtzeit zu organisieren.

Rückblick

Was ist WebRTC? Zunächst ist anzumerken, dass die Abkürzung RTC für Real Time Communication (Kommunikation in Echtzeit) steht. Dies allein gibt viele Informationen über diese Technologie.

WebRTC nimmt eine sehr wichtige Nische unter den Mechanismen der Webplattform ein. Bisher boten P2P-Technologien (Peer-to-Peer-, Punkt-zu-Punkt-Verbindungen, Peer-to-Peer- und Peer-to-Peer-Netzwerke), die von Anwendungen wie Desktop-Chats verwendet wurden, Möglichkeiten, die Webprojekte nicht hatten. WebRTC macht einen Unterschied für die Webtechnologien.

Wenn wir diese Technologie allgemein betrachten, ermöglicht WebRTC Webanwendungen, P2P-Verbindungen zu erstellen, auf die weiter unten eingegangen wird. Darüber hinaus werden wir hier die folgenden Themen behandeln, um das vollständige Bild der internen Struktur von WebRTC zu zeigen:

• P2P-Kommunikation.
• Firewalls und NAT Traversal-Technologie.
• Signalisierung, Sitzungen und Protokolle.
• WebRTC-API

P2P-Kommunikation

Angenommen, zwei Benutzer haben jeweils in ihrem eigenen Browser eine Anwendung gestartet, mit der Sie einen Video-Chat mit WebRTC organisieren können. Sie möchten eine P2P-Verbindung herstellen. Nachdem die Entscheidung getroffen wurde, benötigen wir einen Mechanismus, mit dem die Browser der Benutzer einander finden und die Kommunikation unter Berücksichtigung der in den Systemen verfügbaren Informationsschutzmechanismen herstellen können. Nach dem Herstellen einer Verbindung können Benutzer Multimedia-Informationen in Echtzeit austauschen.

Eine der Hauptschwierigkeiten bei P2P-Verbindungen von Browsern besteht darin, dass sich Browser zuerst gegenseitig erkennen und dann eine Netzwerkverbindung basierend auf Sockets herstellen müssen, um eine bidirektionale Datenübertragung sicherzustellen. Wir empfehlen, die mit der Installation solcher Verbindungen verbundenen Schwierigkeiten zu erörtern.

Wenn eine Webanwendung Daten oder Ressourcen benötigt, lädt sie diese vom Server herunter und fertig. Die Serveradresse ist der Anwendung bekannt. Wenn es sich beispielsweise um die Erstellung eines P2P-Chats handelt, dessen Betrieb auf der direkten Verbindung von Browsern basiert, sind die Adressen dieser Browser nicht im Voraus bekannt. Um eine P2P-Verbindung herzustellen, müssen Sie daher einige Probleme lösen.

Firewalls und NAT Traversal Protocol

Gewöhnlichen Computern sind in der Regel keine statischen externen IP-Adressen zugewiesen. Der Grund dafür ist, dass sich solche Computer normalerweise hinter Firewalls und NAT-Geräten befinden.

NAT ist ein Mechanismus, der interne lokale IP-Adressen, die sich hinter einer Firewall befinden, in externe globale IP-Adressen übersetzt. Die NAT-Technologie wird zum einen aus Sicherheitsgründen und zum anderen aufgrund der von IPv4 auferlegten Einschränkungen für die Anzahl der verfügbaren globalen IP-Adressen verwendet. Aus diesem Grund sollten Webanwendungen, die WebRTC verwenden, nicht darauf angewiesen sein, dass das aktuelle Gerät über eine globale statische IP-Adresse verfügt.

Mal sehen, wie NAT funktioniert. Wenn Sie sich in einem Unternehmensnetzwerk befinden und mit WLAN verbunden sind, wird Ihrem Computer eine IP-Adresse zugewiesen, die nur hinter Ihrem NAT-Gerät vorhanden ist. Angenommen, dies ist die IP-Adresse 172.0.23.4. Für die Außenwelt sieht Ihre IP-Adresse jedoch möglicherweise wie 164.53.27.98 aus. Die Außenwelt sieht Ihre Anfragen daher als von der Adresse 164.53.27.98 stammend an. Dank NAT werden jedoch Antworten auf Anfragen Ihres Computers an externe Dienste an Ihre interne Adresse 172.0.23.4 gesendet. Dies geschieht mithilfe von Übersetzungstabellen. Bitte beachten Sie, dass neben der IP-Adresse auch eine Portnummer für das Netzwerk erforderlich ist.

Da NAT in den Prozess der Interaktion Ihres Systems mit der Außenwelt involviert ist, muss Ihr Browser die IP-Adresse des Computers kennen, auf dem der Browser, den Sie kommunizieren möchten, ausgeführt wird, um eine WebRTC-Verbindung herzustellen.

Hier betreten die Server STUN (Session Traversal Utilities für NAT) und TURN (Traversal Using Relays um NAT) die Szene. Um den Betrieb der WebRTC-Technologie sicherzustellen, wird zunächst eine Anfrage an den STUN-Server gesendet, um Ihre externe IP-Adresse herauszufinden. Tatsächlich handelt es sich um eine Anfrage an einen Remote-Server, um herauszufinden, von welcher IP-Adresse der Server diese Anfrage erhält. Nach Erhalt einer ähnlichen Anfrage sendet der Remote-Server eine Antwort mit der für ihn sichtbaren IP-Adresse.

Basierend auf der Annahme, dass dieses Schema betriebsbereit ist und Sie Informationen über Ihre externe IP-Adresse und Ihren Port erhalten haben, können Sie anderen Teilnehmern des Systems (wir nennen sie Peers) mitteilen, wie sie Sie direkt kontaktieren können. Diese Peers können dasselbe auch über STUN- oder TURN-Server tun und Ihnen mitteilen, welche Adressen ihnen zugewiesen sind.

Signalisierung, Sitzungen und Protokolle

Der oben beschriebene Prozess zum Herausfinden von Netzwerkinformationen ist Teil eines großen Signalisierungssystems, das im Fall von WebRTC auf dem JSEP-Standard (JavaScript Session Establishment Protocol) basiert. Die Signalisierung umfasst die Erkennung von Netzwerkressourcen, die Erstellung und Verwaltung von Sitzungen, die Kommunikationssicherheit, die Koordination von Medienparametern und die Fehlerbehandlung.

Damit die Verbindung funktioniert, müssen Peers die Datenformate vereinbaren, die sie austauschen, und Informationen über die Netzwerkadressen des Computers sammeln, auf dem die Anwendung ausgeführt wird. Der Signalisierungsmechanismus zum Teilen dieser kritischen Informationen ist nicht Teil der WebRTC-API.

Die Signalisierung ist nicht durch den WebRTC-Standard definiert und wird in seiner API nicht implementiert, um Flexibilität bei den verwendeten Technologien und Protokollen zu gewährleisten. Die Signalisierung und die Server, die sie unterstützen, liegen in der Verantwortung des Entwicklers der WebRTC-Anwendung.

Basierend auf der Annahme, dass Ihre im Browser ausgeführte WebRTC-Anwendung die externe IP-Adresse des Browsers mithilfe von STUN ermitteln kann, wie oben beschrieben, besteht der nächste Schritt darin, die Sitzungsparameter zu diskutieren und eine Verbindung mit einem anderen Browser herzustellen.

Die anfängliche Erörterung der Sitzungsparameter und der Aufbau einer Verbindung erfolgt unter Verwendung eines Signalisierungs- / Kommunikationsprotokolls, das auf Multimedia-Kommunikation spezialisiert ist. Dieses Protokoll ist außerdem für die Einhaltung der Regeln verantwortlich, nach denen die Sitzung verwaltet und beendet wird.

Eines dieser Protokolle heißt SIP (Session Initiation Protocol). Bitte beachten Sie, dass SIP aufgrund der Flexibilität des WebRTC-Signalisierungssubsystems nicht das einzige Signalisierungsprotokoll ist, das verwendet werden kann. Das ausgewählte Signalisierungsprotokoll muss außerdem mit einem Protokoll der Anwendungsschicht namens SDP (Session Description Protocol) zusammenarbeiten, das bei Verwendung von WebRTC verwendet wird. Alle Metadaten zu Multimediadaten werden mit dem SDP-Protokoll übertragen.

Jeder Peer (dh eine Anwendung, die WebRTC verwendet), der versucht, einen anderen Peer zu kontaktieren, generiert eine Reihe von Kandidatenrouten für das ICE-Protokoll (Interactive Connectivity Establishment). Kandidaten stellen eine Kombination aus IP-Adresse, Port und Transportprotokoll dar, die verwendet werden kann. Bitte beachten Sie, dass ein Computer über viele Netzwerkschnittstellen (verkabelt, drahtlos usw.) verfügen kann, sodass ihm mehrere IP-Adressen zugewiesen werden können, eine für jede Schnittstelle.

Hier ist ein Diagramm mit MDN, das den obigen Prozess des Datenaustauschs veranschaulicht.

Der Prozess des Datenaustauschs, der zum Herstellen einer P2P-Verbindung erforderlich ist

Stellen Sie eine Verbindung her

Jeder Peer ermittelt zuerst seine externe IP-Adresse wie oben beschrieben. Anschließend werden dynamisch „Kanäle“ für Signalisierungsdaten erstellt, die dazu dienen, Peers zu erkennen und den Datenaustausch zwischen ihnen zu unterstützen, um Sitzungsparameter und deren Installation zu diskutieren.

Diese „Kanäle“ sind unbekannt und für die Außenwelt nicht zugänglich. Für den Zugriff auf diese Kanäle ist eine eindeutige Kennung erforderlich.

Bitte beachten Sie, dass aufgrund der Flexibilität von WebRTC und der Tatsache, dass der Signalisierungsprozess nicht durch den Standard definiert ist, das Konzept der „Kanäle“ und die Reihenfolge ihrer Verwendung je nach den verwendeten Technologien geringfügig variieren können. Tatsächlich erfordern einige Protokolle keinen "Kanal" -Mechanismus zum Organisieren des Datenaustauschs. Für die Zwecke dieses Materials gehen wir davon aus, dass die "Kanäle" bei der Implementierung des Systems verwendet werden.

Wenn zwei oder mehr Peers mit demselben „Kanal“ verbunden sind, haben Peers die Möglichkeit, Daten auszutauschen und Sitzungsinformationen zu diskutieren. Dieser Vorgang ähnelt einer Publisher-Subscriber- Vorlage. Im Allgemeinen sendet der Peer, der die Verbindung initiiert, ein "Angebot" unter Verwendung eines Signalisierungsprotokolls wie SIP oder SDP. Der Initiator erwartet vom Empfänger des Vorschlags eine „Antwort“, die mit dem betrachteten „Kanal“ verbunden ist.

Nachdem die Antwort eingegangen ist, findet der Prozess der Bestimmung und Diskussion der besten ICE-Kandidaten statt, die bei jedem Fest gesammelt wurden. Nachdem die optimalen ICE-Kandidaten ausgewählt wurden, werden die Datenparameter vereinbart, die zwischen Peers und dem Netzwerkroutingmechanismus (IP-Adresse und Port) ausgetauscht werden.

Anschließend wird eine aktive Netzwerk-Socket-Sitzung zwischen Peers eingerichtet. Darüber hinaus erstellt jeder Peer lokale Datenströme und Endpunkte von Datenkanälen, und die bidirektionale Übertragung von Multimediadaten beginnt mit der angewandten Technologie.

Wenn der Verhandlungsprozess zur Auswahl des besten ICE-Kandidaten nicht erfolgreich ist, was manchmal auf den Fehler von Firewalls und NAT-Systemen zurückzuführen ist, wird eine Sicherungsoption verwendet, die darin besteht, einen TURN-Server als Relay zu verwenden. Bei diesem Prozess handelt es sich um einen Server, der als Vermittler fungiert und die zwischen Peers ausgetauschten Daten weiterleitet. Bitte beachten Sie, dass dieses Schema keine echte P2P-Verbindung ist, bei der Peers Daten direkt untereinander übertragen.

Wenn Sie einen Fallback mit TURN für den Datenaustausch verwenden, muss nicht mehr jeder Peer wissen, wie er mit anderen kommuniziert und wie er Daten an ihn überträgt. Stattdessen müssen Peers wissen, welcher externe TURN-Server Multimediadaten in Echtzeit senden muss und von welchem ​​Server sie während der Kommunikationssitzung empfangen müssen.

Es ist wichtig zu verstehen, dass dies nun eine Backup-Methode zur Organisation der Kommunikation war. TURN-Server sollten sehr zuverlässig sein, eine große Bandbreite und ernsthafte Rechenleistung haben und die Arbeit mit potenziell großen Datenmengen unterstützen. Die Verwendung eines TURN-Servers führt daher offensichtlich zu zusätzlichen Kosten und zu einer Erhöhung der Komplexität des Systems.

WebRTC-API

In WebRTC gibt es drei Hauptkategorien von APIs:

• Die Media Capture and Streams-API ist für die Medienerfassung und das Streaming verantwortlich. Mit dieser API können Sie eine Verbindung zu Eingabegeräten wie Mikrofonen und Webcams herstellen und Medienströme von diesen empfangen.
• RTCPeerConnection API Mit der API dieser Kategorie ist es möglich, von einem Endpunkt von WebRTC aus den erfassten Strom von Audio- oder Videodaten über das Internet in Echtzeit an einen anderen Endpunkt von WebRTC zu senden. Mit dieser API können Sie Verbindungen zwischen dem lokalen Computer und dem Remote-Peer herstellen. Es bietet Methoden zum Herstellen einer Verbindung zu einem Remote-Peer, zum Verwalten der Verbindung und zum Überwachen ihres Status. Seine Mechanismen werden verwendet, um unnötige Verbindungen zu schließen.
• RTCDataChannel API Die von dieser API dargestellten Mechanismen ermöglichen die Übertragung beliebiger Daten. Jeder Datenkanal ist einer RTCPeerConnection-Schnittstelle zugeordnet.

Lassen Sie uns über diese APIs sprechen.

API Media Capture und Streams

Die Media Capture- und Streams-API, die häufig als Media Stream-API oder Stream-API bezeichnet wird, ist eine API, die das Arbeiten mit Streams von Audio- und Videodaten unterstützt. Mit dieser API können Sie Einschränkungen in Bezug auf Datentypen festlegen. Hier gibt es Rückrufe für den erfolgreichen und erfolglosen Abschluss von Vorgängen, die bei Verwendung asynchroner Mechanismen für die Arbeit mit Daten verwendet werden, sowie Ereignisse, die während des Vorgangs ausgelöst werden.

Die Methode getUserMedia() der getUserMedia() API bittet den Benutzer um Erlaubnis, mit Eingabegeräten arbeiten zu dürfen, die MediaStream- Streams mit Audio- oder Videospuren erzeugen, die die angeforderten Medientypen enthalten. Ein solcher Stream kann beispielsweise eine Videospur (seine Quelle ist entweder eine Hardware- oder eine virtuelle Videoquelle wie eine Kamera, ein Videorecorder, ein Bildschirmfreigabedienst usw.), eine Audiospur (physische oder virtuelle Audioquellen können sie auf ähnliche Weise bilden) umfassen. wie ein Mikrofon, ein Analog-Digital-Wandler usw.) und möglicherweise andere Arten von Spuren.

Diese Methode gibt das Versprechen zurück , das in das MediaStream- Objekt aufgelöst wird. Wenn der Benutzer die Berechtigungsanforderung ablehnt oder das entsprechende Medium nicht verfügbar ist, wird das Versprechen mit einem PermissionDeniedError oder NotFoundError .

Sie können über das navigator auf den MediaDevice Singleton zugreifen:

 navigator.mediaDevices.getUserMedia(constraints) .then(function(stream) { /*   */ }) .catch(function(err) { /*   */ }); 

Beachten Sie, dass Sie beim Aufrufen der Methode getUserMedia() ein constraints , das der API mitteilt, welcher Stream-Typ zurückgegeben werden soll. Hier können Sie viele Dinge konfigurieren, einschließlich der Kamera, die Sie verwenden möchten (vorne oder hinten), der Bildrate, der Auflösung usw.

Ab Version 25 ermöglichen Chromium-basierte Browser die Übertragung von Audiodaten von getUserMedia() Audio- oder Videoelemente (beachten Sie jedoch, dass getUserMedia() standardmäßig deaktiviert sind).

Die Methode getUserMedia() kann auch als Eingabeknoten für die Web-Audio-API verwendet werden :

 function gotStream(stream) {   window.AudioContext = window.AudioContext || window.webkitAudioContext;   var audioContext = new AudioContext();   //  AudioNode     var mediaStreamSource = audioContext.createMediaStreamSource(stream);   //       ,    ,   //       !   mediaStreamSource.connect(audioContext.destination); } navigator.getUserMedia({audio:true}, gotStream); 

Einschränkungen im Zusammenhang mit dem Schutz personenbezogener Daten

Die unbefugte Erfassung von Daten von einem Mikrofon oder einer Kamera ist eine schwerwiegende Beeinträchtigung des persönlichen Lebens des Benutzers. Die Verwendung von getUserMedia() die Implementierung sehr spezifischer Anforderungen, um den Benutzer über das Geschehen zu informieren und Berechtigungen zu verwalten. Die Methode getUserMedia() muss immer die Benutzerberechtigung einholen, bevor Sie ein Eingabegerät öffnen, das Medien sammelt, z. B. eine Webcam oder ein Mikrofon. Browser bieten möglicherweise die Option einer einmaligen Einstellung der Berechtigung für eine Domain an. Sie müssen jedoch mindestens beim ersten Zugriff auf Mediengeräte eine Berechtigung anfordern, und der Benutzer muss diese Berechtigung ausdrücklich erteilen.

Darüber hinaus sind hier die Regeln wichtig, die sich auf die Benachrichtigung des Benutzers über das Geschehen beziehen. Browser müssen eine Anzeige anzeigen, die die Verwendung eines Mikrofons oder einer Kamera anzeigt. Die Anzeige einer solchen Anzeige hängt nicht vom Vorhandensein von Hardwareanzeigen im System ab, die den Betrieb solcher Geräte anzeigen. Darüber hinaus sollten Browser einen Indikator anzeigen, dass die Berechtigung zur Verwendung des Eingabegeräts erteilt wurde, auch wenn das Gerät zu einem bestimmten Zeitpunkt nicht zum Aufzeichnen relevanter Daten verwendet wird.

RTCPeerConnection-Schnittstelle

Die RTCPeerConnection-Schnittstelle ist eine WebRTC-Verbindung zwischen dem lokalen Computer und dem Remote-Peer. Es bietet Methoden zum Herstellen einer Verbindung zu einem Remote-System, zum Unterstützen der Verbindung und Überwachen ihres Status sowie zum Schließen der Verbindung, nachdem sie nicht mehr benötigt wird.

Hier ist ein WebRTC-Architekturdiagramm, das die Rolle von RTCPeerConnection demonstriert.


RTCPeerConnection-Rolle

Aus JavaScript-Sicht kann aus der Analyse dieses Diagramms hauptsächlich gewonnen werden, dass RTCPeerConnection den Webentwickler von komplexen Mechanismen abstrahiert, die sich auf tieferen Ebenen des Systems befinden. Die von WebRTC verwendeten Codecs und Protokolle leisten hervorragende Arbeit, um den Datenaustausch in Echtzeit zu ermöglichen, selbst wenn nicht vertrauenswürdige Netzwerke verwendet werden. Hier sind einige der Aufgaben, die durch diese Mechanismen gelöst werden:

• Paketverlust maskieren.
• Echokompensation.
• Bandbreitenanpassung.
• Dynamische Pufferung zur Beseitigung von Jitter.
• Automatische Lautstärkeregelung.
• Rauschunterdrückung und -unterdrückung.
• Bild "reinigen".

RTCDataChannel API

Wie bei Audio- und Videodaten unterstützt WebRTC die Echtzeitübertragung anderer Datentypen. Mit der RTCDataChannel-API können Sie einen P2P-Austausch beliebiger Daten organisieren.

Es gibt viele Szenarien für die Verwendung dieser API. Hier sind einige davon:

• Spiele
• Echtzeit-Text-Chats.
• Dateiübertragung.
• Organisation von dezentralen Netzwerken.

Diese API zielt auf die effizienteste Nutzung der Funktionen der RTCPeerConnection-API ab und ermöglicht Ihnen die Organisation eines leistungsstarken und flexiblen Datenaustauschsystems in einer P2P-Umgebung. Zu seinen Merkmalen gehören:

• Effektive Arbeit mit Sitzungen mit RTCPeerConnection.
• Unterstützung für mehrere gleichzeitig verwendete Kommunikationskanäle mit Priorisierung.
• Unterstützung für zuverlässige und unzuverlässige Methoden der Nachrichtenübermittlung.
• Integriertes Sicherheitsmanagement (DTLS) und Überlastung.

Die Syntax hier ähnelt der bei der Arbeit mit der WebSocket-Technologie verwendeten. Die send() -Methode und das message werden hier angewendet:

 var peerConnection = new webkitRTCPeerConnection(servers,   {optional: [{RtpDataChannels: true}]} ); peerConnection.ondatachannel = function(event) {   receiveChannel = event.channel;   receiveChannel.onmessage = function(event){       document.querySelector("#receiver").innerHTML = event.data;   }; }; sendChannel = peerConnection.createDataChannel("sendDataChannel", {reliable: false}); document.querySelector("button#send").onclick = function (){   var data = document.querySelector("textarea#send").value;   sendChannel.send(data); } 

WebRTC in der realen Welt

In der realen Welt erfordert die WebRTC-Kommunikation Server. Systeme sind nicht zu kompliziert, dank ihnen wird die folgende Abfolge von Aktionen implementiert:

• Benutzer entdecken sich gegenseitig und tauschen Informationen über einander aus, z. B. Namen.
• WebRTC-Clientanwendungen (Peers) tauschen Netzwerkinformationen aus.
• Kollegen tauschen Informationen über Mediendaten wie Videoformat und Auflösung aus.
• WebRTC-Clientanwendungen stellen eine Verbindung unter Umgehung von NAT-Gateways und Firewalls her.

Mit anderen Worten, WebRTC benötigt vier Arten von Serverfunktionen:

• Mittel zum Erkennen von Benutzern und zum Organisieren ihrer Interaktion.
• Signalisierung.
• NAT und Firewalls umgehen.
• Relay-Server, die verwendet werden, wenn keine P2P-Verbindung hergestellt werden kann.

Das STUN- Protokoll und seine TURN- Erweiterung werden von ICE verwendet , um RTCPeerConnection die Arbeit mit NAT-Bypass-Mechanismen zu ermöglichen und andere Schwierigkeiten bei der Datenübertragung über ein Netzwerk zu bewältigen.

Wie bereits erwähnt, ist ICE ein Protokoll zum Verbinden von Peers, z. B. zwei Video-Chat-Clients. Zu Beginn der Kommunikationssitzung versucht ICE, Peers mit möglichst geringer Verzögerung direkt über UDP zu verbinden. Während dieses Prozesses haben STUN-Server eine einzige Aufgabe: Den Peer hinter NAT seine öffentliche Adresse und seinen Port erfahren zu lassen. Schauen Sie sich diese Liste der verfügbaren STUN-Server an (Google hat auch solche Server).


STUN-Server

ICE-Kandidatenerkennung

Wenn die UDP-Verbindung nicht hergestellt werden kann, versucht ICE, eine TCP-Verbindung herzustellen: zuerst - über HTTP, dann - über HTTPS. Wenn keine direkte Verbindung hergestellt werden kann - insbesondere aufgrund der Unfähigkeit, Unternehmens-NATs und -Firewalls zu umgehen - verwendet ICE einen Vermittler (Relay) in Form eines TURN-Servers. Mit anderen Worten, ICE versucht zunächst, STUN mit UDP für die direkte Verbindung von Peers zu verwenden. Wenn dies nicht funktioniert, wird eine Fallback-Option mit einem Mieter in Form eines TURN-Servers verwendet. Der Begriff "Kandidatensuche" bezieht sich auf den Prozess der Suche nach Netzwerkschnittstellen und Ports.


Suche nach geeigneten Netzwerkschnittstellen und Ports

Sicherheit

Echtzeit-Kommunikationsanwendungen oder verwandte Plugins können zu Sicherheitsproblemen führen. Insbesondere sprechen wir über Folgendes:

• Unverschlüsselte Mediendaten oder andere Daten können auf dem Pfad zwischen Browsern oder zwischen einem Browser und einem Server abgefangen werden.
• Eine Anwendung kann ohne Wissen des Benutzers Video- und Audiodaten aufzeichnen und an einen Angreifer übertragen.
• Zusammen mit einem harmlos aussehenden Plug-In oder einer harmlos aussehenden Anwendung kann ein Virus oder eine andere schädliche Software auf den Computer des Benutzers gelangen.

WebRTC verfügt über verschiedene Mechanismen, um mit diesen Bedrohungen umzugehen:

• WebRTC-Implementierungen verwenden sichere Protokolle wie DTLS und SRTP .
• Für alle Komponenten von WebRTC-Systemen ist die Verwendung von Verschlüsselung obligatorisch. Dies gilt auch für Signalmechanismen.
• WebRTC ist kein Plugin. WebRTC-Komponenten werden in der Browser-Sandbox und nicht in einem separaten Prozess ausgeführt. Komponenten werden aktualisiert, wenn der Browser aktualisiert wird.
• Der Zugang zu Kamera und Mikrofon muss ausdrücklich erfolgen. Und wenn eine Kamera oder ein Mikrofon verwendet wird, wird diese Tatsache in der Benutzeroberfläche des Browsers deutlich angezeigt.

Zusammenfassung

WebRTC ist eine sehr interessante und leistungsstarke Technologie für Projekte, bei denen Daten in Echtzeit zwischen Browsern übertragen werden. Der Autor des Materials sagt, dass sein Unternehmen, SessionStack , traditionelle Mechanismen für den Datenaustausch mit Benutzern verwendet, bei denen Server verwendet werden. Wenn sie jedoch WebRTC verwenden, um die entsprechenden Probleme zu lösen, würde dies die Organisation des Datenaustauschs direkt zwischen Browsern ermöglichen, was zu einer Verringerung der Verzögerung bei der Datenübertragung und zu einer Verringerung der Belastung der Unternehmensinfrastruktur führen würde.

Liebe Leser! Verwenden Sie die WebRTC-Technologie in Ihren Projekten?