WebRTC vs WebSocket (und Webhooks und HTTP) | We.Inc
WebRTC vs WebSocket: Peer-to-Peer-Medien und Datenkanäle im Vergleich zu einem Client-Server-Socket, warum WebRTC trotzdem Signaling braucht, dazu Webhook vs WebSocket und HTTP vs WebSocket.
Ein WebSocket hält eine einzige Zwei-Wege-Verbindung zwischen einem Browser und deinem Server offen, und jede Nachricht läuft über diesen Server. WebRTC verbindet Browser direkt miteinander für Audio, Video und beliebige Daten, verschlüsselt mit DTLS und SRTP. Oft werden beide zusammen eingesetzt: Ein WebSocket überträgt die Signaling-Nachrichten, die den WebRTC-Anruf aufbauen.
WebRTC und WebSocket im Vergleich
Frage
WebRTC
WebSocket
Wer spricht mit wem
Browser zu Browser (Peer to Peer)
Browser zu Server
Gebaut für
Audio, Video, Bildschirmfreigabe, Peer-Daten
Nachrichten zwischen App und Server
Aufbau
Offer, Answer und ICE-Kandidaten über dein eigenes Signaling
Ein einziger HTTP-Upgrade-Handshake
Zustelloptionen
Datenkanäle können geordnet oder ungeordnet, zuverlässig oder nicht zuverlässig sein
Geordnet und zuverlässig
Verschlüsselung
Immer aktiv (DTLS, SRTP)
Nur mit wss://
Braucht einen Server
Für Signaling und TURN-Relays, wenn sich Peers nicht direkt verbinden können
Ja, er ist die Gegenstelle
Wähle im Helfer unten aus, was du baust, und er nennt dir die passende Technologie samt Begründung. Außerdem behandelt er die beiden Fragen, die oft mit dieser vermischt werden: Webhooks, die von Server zu Server laufen, und einfache HTTP-Anfragen.
Wähle die Funktion, die deiner am nächsten kommt.
Lies, welche Technologie passt und warum.
Scrolle zu den Code-Abschnitten für eine Signaling-Skizze und ein Beispiel für einen Datenkanal.
Nutze die beiden Tabellen gegen Ende für die Vergleiche mit Webhooks und HTTP.
Greif nicht zu WebRTC, um Updates von deinem Server zu pushen. Der Server ist dort kein Peer, und ein WebSocket oder ein Event-Stream ist viel einfacher.
Plane ein TURN-Relay ein, bevor du Anrufe startest. Manche Netzwerke blockieren direkte Peer-Verbindungen, und dann fließen alle Medien über das Relay, das du bezahlst.
Halte den Signaling-Server dumm: Er leitet nur Offers, Answers und Kandidaten weiter. MDN beschreibt die Nutzdaten als Blackbox, die der Server nicht verstehen muss.
Für ein Spiel oder einen Live-Cursor-Feed zwischen Peers öffnest du den Datenkanal mit ordered auf false und maxRetransmits auf 0, damit ein verspätetes Paket nie neuere blockiert.
Häufige Fragen
Ersetzt WebRTC WebSockets?
Nein. WebRTC hat keinen eingebauten Weg, wie zwei Browser einander finden, also brauchst du trotzdem einen Kanal, um die Aufbau-Nachrichten auszutauschen. Ein WebSocket ist die übliche Wahl, auch wenn MDN anmerkt, dass jeder Transportweg funktioniert.
Kann WebRTC auch reine Daten senden, nicht nur Video?
Ja. RTCPeerConnection.createDataChannel() öffnet einen Kanal für Text- oder Binärdaten zwischen Peers, und die API ist bewusst an die WebSocket-API angelehnt, mit send() und einem message-Event.
Was ist der Unterschied zwischen einem Webhook und einem WebSocket?
Ein Webhook ist eine HTTP-Anfrage, die ein Server an eine URL auf einem anderen Server sendet, wenn ein Ereignis eintritt, danach endet die Verbindung. Ein WebSocket ist eine Verbindung, die offen bleibt, damit Browser und Server weiter miteinander sprechen können.
Ist ein WebSocket schneller als HTTP?
Bei vielen kleinen Nachrichten meistens ja, weil der Handshake nur einmal stattfindet und jede spätere Nachricht ohne Request-Header auskommt. Zum Laden einer Seite oder Datei ist normales HTTP das richtige Werkzeug und profitiert vom Caching.
Ist WebRTC auch mit vielen Teilnehmern in einem Anruf Peer to Peer?
Jede Verbindung besteht zwischen zwei Peers, daher wächst ein vollständiges Mesh schnell, wenn Leute dazukommen. Viele größere Anrufprodukte leiten Medien stattdessen über einen Server, der Streams weiterreicht, und das liegt außerhalb der WebRTC-Browser-API selbst.
Warum WebRTC trotzdem einen Server braucht
Bevor sich zwei Browser verbinden können, muss jeder die Sitzungsbeschreibung des anderen kennen, also ein SDP-Offer und eine Answer, sowie eine Liste möglicher Netzwerkadressen, die ICE-Kandidaten. WebRTC überlässt dir die Zustellung dieser Nachrichten.
Sobald sie ausgetauscht sind, probiert ICE die Kandidaten aus, wobei STUN jeder Seite hilft, ihre öffentliche Adresse herauszufinden. Funktioniert keine direkte Route, fällt der Verkehr auf einen TURN-Server zurück, der ihn weiterleitet. Danach fließen die Medien zwischen den Peers, nicht über deinen Signaling-Server.
Webhook vs WebSocket
Beide lösen unterschiedliche Probleme. Mit einem Webhook kann ein Dienst wie ein Zahlungsanbieter oder ein Code-Hoster deinem Backend mitteilen, dass etwas passiert ist, indem er eine HTTP-Anfrage an eine von dir registrierte URL sendet. Nichts bleibt offen, und kein Browser ist beteiligt.
Ein WebSocket hält eine Live-Leitung zum Browser eines Nutzers. Ein gängiges Muster nutzt beides: Ein Webhook teilt deinem Server mit, dass eine Bestellung bezahlt wurde, und dein Server pusht diese Nachricht dann über einen WebSocket an die geöffnete Seite des Kunden.
HTTP vs WebSocket
Normales HTTP ist Anfrage und Antwort: Der Client fragt, der Server antwortet, und GET-Antworten können von Browsern und CDNs gecacht werden. Das ist der richtige Standard für Seiten, Dateien und die meisten API-Aufrufe.
Ein WebSocket beginnt als HTTP-Anfrage, wechselt dann mit einer 101-Antwort das Protokoll und bleibt offen. Greif nur dann dazu, wenn der Server Daten senden muss, nach denen der Client nicht gefragt hat, oder wenn Nachrichten so häufig fliegen, dass der Overhead pro Anfrage ins Gewicht fällt.
WebRTC-Aufbau über einen WebSocket
Anrufer: ein Offer und einen Datenkanal erstellen
Der WebSocket leitet nur Aufbau-Nachrichten weiter. Die STUN-URL ist ein Platzhalter für den Server deiner Wahl.
Angerufener: antworten und den Kanal empfangen
Die andere Seite erhält den Kanal über das datachannel-Event, statt ihn selbst zu erstellen.
Ein ungeordneter Kanal ohne Wiederholungen für den Spielzustand
maxRetransmits und maxPacketLifeTime können nicht beide gesetzt werden, wähle eins davon.
Webhook vs WebSocket auf einen Blick
Webhook vs WebSocket
Frage
Webhook
WebSocket
Wer verbindet sich
Ein Server ruft einen anderen Server auf
Ein Client hält eine Leitung zu einem Server offen
Lebensdauer
Eine HTTP-Anfrage pro Ereignis
Offen, bis eine Seite sie schließt
Richtung
Vom Sender zum Empfänger
In beide Richtungen
Typischer Einsatz
Zahlungs-, Repository- oder Formular-Ereignisse
Live-Chat, Dashboards, Präsenzanzeige
HTTP vs WebSocket auf einen Blick
HTTP vs WebSocket
Frage
HTTP-Anfrage
WebSocket
Wer startet eine Nachricht
Immer der Client
Jede der beiden Seiten
Verbindung
Anfrage, dann Antwort
Mit 101 hochgestuft, bleibt dann offen
Caching
GET- und HEAD-Antworten sind cachebar
Keins
URL-Schemata
ws:// (port 80), wss:// (port 443)
Videoanruf zwischen zwei Personen
WebRTC, mit einem WebSocket für das Signaling
Audio und Video sollten mit geringer Verzögerung direkt zwischen den Anrufern laufen. Ein kleiner WebSocket-Server reicht beim Aufbau nur Offer, Answer und Kandidaten weiter.
Gruppen-Chatraum in einer Web-App
WebSocket
Nachrichten müssen gespeichert, moderiert und an alle im Raum gesendet werden, sie gehören also ohnehin auf deinen Server. Ein Socket pro Nutzer ist die einfache Lösung.
Eine große Datei an den Browser eines Freundes senden
WebRTC-Datenkanal
Ein zuverlässiger, geordneter Datenkanal überträgt die Bytes Peer to Peer, sodass dein Server die Datei nie speichert oder weiterleitet, außer TURN wird benötigt.
Schnelle Spielzüge für zwei Spieler
WebRTC-Datenkanal, ungeordnet
Ohne Reihenfolge und ohne Wiederholungen wird ein verlorenes Positions-Update übersprungen, statt neuere aufzuhalten. Brauchst du einen Schiedsrichter-Server, nutze stattdessen einen WebSocket zu ihm.
Zahlungsanbieter bestätigt eine Bestellung
Webhook
Der Server des Anbieters ruft eine URL auf deinem Server auf, wenn die Zahlung erfolgreich ist. Kein Browser ist beteiligt, und nichts muss offen bleiben.
Eine Produktseite und ihre Daten laden
Normales HTTP
Anfrage und Antwort reichen völlig, und GET-Antworten können gecacht werden. Eine dauerhafte Verbindung würde Kosten verursachen und nichts bringen.