WebRTC vs Websockets: Wenn WebRTC Video, Audio und Daten verarbeiten kann, warum benötige ich Websockets? [geschlossen]


219

Daher möchte ich eine Chat-App erstellen, die Video, Audio und Text ermöglicht. Ich habe einige Zeit in Websockets und WebRTC recherchiert, um zu entscheiden, welche ich verwenden soll. Da es mit WebRTC viele Video- und Audio-Apps gibt, klingt dies nach einer vernünftigen Wahl, aber gibt es noch andere Dinge, die ich berücksichtigen sollte? Fühlen Sie sich frei, Ihre Gedanken zu teilen.

Dinge wie:

  • Da WebRTC neu ist, ist es nur in einigen Browsern verfügbar, während WebSockets in mehr Browsern zu sein scheint.

  • Skalierbarkeit - Websockets verwendet einen Server für Sitzungen und WebRTC scheint p2p zu sein.

  • Multiplexing / mehrere Chatrooms - Wird in Google+ Hangouts verwendet und ich sehe immer noch Demo-Apps zur Implementierung an.

  • Server - Websockets benötigen RedisSessionStore oder RabbitMQ, um über mehrere Computer hinweg skaliert zu werden.

Antworten:


272

WebRTC wurde für eine leistungsstarke und qualitativ hochwertige Kommunikation von Video, Audio und beliebigen Daten entwickelt. Mit anderen Worten, für Apps genau so, wie Sie es beschreiben.

WebRTC-Apps benötigen einen Dienst, über den sie Netzwerk- und Medienmetadaten austauschen können. Dieser Vorgang wird als Signalisierung bezeichnet. Sobald die Signalisierung erfolgt ist, werden Video / Audio / Daten direkt zwischen Clients gestreamt, wodurch die Leistungskosten für das Streaming über einen Zwischenserver vermieden werden.

WebSocket hingegen ist für die bidirektionale Kommunikation zwischen Client und Server ausgelegt. Es ist möglich, Audio und Video über WebSocket zu streamen (siehe hier zum Beispiel), aber die Technologie und APIs sind nicht wie WebRTC für effizientes, robustes Streaming ausgelegt.

Wie bereits in anderen Antworten erwähnt, kann WebSocket zur Signalisierung verwendet werden.

Ich führe eine Liste der WebRTC-Ressourcen. Ich empfehle Ihnen dringend, zunächst die Google I / O- Präsentation 2013 zu WebRTC zu lesen.


2
Vielen Dank für die ausführliche Antwort ... ein Update fast zwei Jahre später?
Crashalot

2
Ich empfehle, einen Blick auf die oben verlinkten Ressourcen zu werfen - siehe g.co/webrtc .
Sam Dutton

3
Auch nicht , dass (ich glaube) WebRTC kann über Paket bestellen und Sachen zu weniger streng sein konfiguriert werden, so kann es viel schneller ist , dass Sie nicht etwas Paketverlust ausmachen usw. (dh die mit neuesten Daten sind wichtiger , als wenn alle die Daten): stackoverflow.com/a/13051771/993683

1
Ich denke, die Schlüsselwörter hier sind zu der Zeit . Die Polling-Fallback-Funktion von Socket.io ist jetzt redundant, sodass Sie eine hauchdünne Bibliothek mit einfach zu implementierenden Funktionen zu entsetzlichen Leistungskosten haben. Lass mich nicht anfangen: D.
Luke

1
@SamDutton, Sicherlich kann der Server als Peer fungieren und ein Ende des RTCDataChannel selbst verwenden? Als solches sehe ich für die moderne Webprogrammierung überhaupt keinen Vorteil von Websocket? seit RTCDataChannel ist UDP / Echtzeit?
Pacerier

71

WebSockets:

  • Ratifizierter IETF-Standard (6455) mit Unterstützung für alle modernen Browser und sogar für ältere Browser mit Web-Socket-js-Polyfill.

  • Verwendet HTTP-kompatiblen Handshake und Standardports, wodurch die Verwendung mit vorhandener Firewall-, Proxy- und Webserverinfrastruktur erheblich vereinfacht wird.

  • Viel einfachere Browser-API. Grundsätzlich ein Konstruktor mit ein paar Rückrufen.

  • Nur Client / Browser zu Server.

  • Unterstützt nur zuverlässigen Transport in der richtigen Reihenfolge, da er auf TCP basiert. Dies bedeutet, dass Paketverluste alle nachfolgenden Pakete verzögern können.

WebRTC:

  • Ich fange gerade an, von Chrome und Firefox unterstützt zu werden. MS hat eine inkompatible Variante vorgeschlagen. Die DataChannel-Komponente ist noch nicht zwischen Firefox und Chrome kompatibel.

  • WebRTC ist unter idealen Umständen von Browser zu Browser, erfordert jedoch selbst dann fast immer einen Signalisierungsserver, um die Verbindungen herzustellen. Die derzeit am häufigsten verwendeten Signalisierungsserverlösungen verwenden WebSockets.

  • Die Transportschicht kann so konfiguriert werden, dass die Anwendung auswählen kann, ob die Verbindung ordnungsgemäß und / oder zuverlässig ist.

  • Komplexe und vielschichtige Browser-API. Es gibt JS-Bibliotheken, die eine einfachere API bereitstellen, aber diese sind jung und ändern sich schnell (genau wie WebRTC selbst).


4
Die Unterstützung von WebRTC-Browsern ist mittlerweile viel besser. caniuse.com/#search=WebRTC
tuxayo

57

Websockets verwenden das TCP-Protokoll.

WebRTC ist hauptsächlich UDP.

Der Hauptgrund für die Verwendung von WebRTC anstelle von Websocket ist daher die Latenz. Beim Websocket-Streaming haben Sie entweder eine hohe Latenz oder eine abgehackte Wiedergabe mit geringer Latenz. Mit WebRTC erzielen Sie möglicherweise eine geringe Latenz und eine reibungslose Wiedergabe, was für die VoIP-Kommunikation von entscheidender Bedeutung ist.

Versuchen Sie einfach, diese Technologie mit einem Netzwerkverlust zu testen, dh 2%. Sie werden hohe Verzögerungen im Websocket-Stream sehen.


2
Für Interessierte wird dieses Zeug hier weiter erklärt: stackoverflow.com/a/13051771/993683

39

webRTC oder Websockets? Warum nicht beides verwenden?

Beim Erstellen eines Video- / Audio- / Text-Chats ist webRTC definitiv eine gute Wahl, da es Peer-to-Peer-Technologie verwendet. Sobald die Verbindung hergestellt ist, müssen Sie die Kommunikation nicht über einen Server weiterleiten (es sei denn, Sie verwenden TURN).

Beim Einrichten der webRTC-Kommunikation müssen Sie einen Signalisierungsmechanismus verwenden. Websockets könnten hier eine gute Wahl sein, aber webRTC ist der richtige Weg, um Video-, Audio- und Textinformationen zu erhalten. Chatrooms werden in der Signalisierung durchgeführt.

Wie Sie bereits erwähnt haben, unterstützt nicht jeder Browser webRTC, sodass Websockets manchmal ein guter Fallback für diese Browser sein können.


10

Der Vergleich von Websocket und Webrtc ist unfair.

Websocket basiert auf TCP. Die Paketgrenze kann im Gegensatz zu tcp anhand der Header-Informationen eines Websocket-Pakets erkannt werden.

In der Regel verwendet webrtc den Websocket. Die Signalisierung für webrtc ist nicht definiert, es liegt beim Dienstanbieter, welche Art von Signalisierung er verwenden möchte. Dies kann SIP, HTTP, JSON oder eine beliebige Text- / Binärnachricht sein.

Die Signalisierungsnachrichten können über den Websocket gesendet / empfangen werden.


10

Sicherheit ist ein Aspekt, den Sie verpasst haben.

Bei Websockets müssen die Daten über einen zentralen Webserver übertragen werden, der normalerweise den gesamten Datenverkehr sieht und darauf zugreifen kann.

Mit WebRTC werden die Daten durchgehend verschlüsselt und nicht über einen Server übertragen (außer manchmal werden TURN-Server benötigt, sie haben jedoch keinen Zugriff auf den Hauptteil der Nachrichten, die sie weiterleiten).

Abhängig von Ihrer Anwendung kann dies von Bedeutung sein oder auch nicht.

Wenn Sie große Datenmengen senden, kann auch die Einsparung von Cloud-Bandbreitenkosten aufgrund der P2P-Architektur von webRTC in Betracht gezogen werden.


1
Es ist ein Missverständnis, dass WebRTC ausschließlich ein Peer-to-Peer-Protokoll ist. In der Industrie wird es zunehmend als serverbasierte VOIP-Alternative eingesetzt.
photicSphere

Wenn wir WebSocket als Medienfluss von WebRTC implementieren, wird SIP verwendet, und SIP ist ein Nur-Text-Protokoll, das für VoIP verwendet wurde.
M. Rostami

6

Webrtc ist Teil der Peer-to-Peer-Verbindung. Wir alle wissen, dass vor dem Erstellen einer Peer-to-Peer-Verbindung ein Handshake-Prozess erforderlich ist, um eine Peer-to-Peer-Verbindung herzustellen. Und Websockets spielen die Rolle des Handshake-Prozesses.


3

Websocket und WebRTC können zusammen verwendet werden, Websocket als Signalkanal von WebRTC und webrtc ist ein Video- / Audio- / Textkanal. Auch WebRTC kann in UDP auch in TURN-Relay sein. TURN-Relay unterstützt TCP HTTP und HTTPS. Viele Projekte verwenden Websocket und WebRTC zusammen.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.