WebSockets vs. Server-Sent Events vs. Long Polling vs. WebRTC vs. WebTransport
- In modernen Echtzeit-Webanwendungen ist die Fähigkeit, Ereignisse vom Server an den Client zu übertragen, unverzichtbar.
- Aus diesem Bedarf heraus wurden verschiedene Methoden entwickelt, die jeweils eigene Vor- und Nachteile haben.
- Anfangs war nur Long Polling als Option verfügbar, später kamen mit WebSockets robustere Lösungen für bidirektionale Kommunikation hinzu.
- Nach WebSockets wurden mit Server-Sent Events (SSE) einfachere Mittel für unidirektionale Kommunikation vom Server zum Client bereitgestellt.
- Das WebTransport-Protokoll bietet einen effizienteren, flexibleren und besser skalierbaren Ansatz und scheint diesen Bereich weiter zu verändern.
- Für bestimmte Anwendungsfälle kann auch WebRTC für Server-Client-Ereignisse in Betracht gezogen werden.
Was ist Long Polling?
- Long Polling ist die erste „Hack“-Technik, die serverseitiges Messaging zum Client im Browser über HTTP ermöglicht hat.
- Im Gegensatz zu traditionellem Polling, bei dem der Client den Server regelmäßig nach Daten fragt, wird beim Long Polling eine Verbindung zum Server offengehalten, bis neue Daten verfügbar sind.
- Wenn dem Server neue Informationen vorliegen, sendet er eine Antwort an den Client und schließt die Verbindung.
- Unmittelbar nach Erhalt der Serverantwort startet der Client eine neue Anfrage, und dieser Vorgang wiederholt sich.
- Diese Methode ermöglicht zeitnähere Datenaktualisierungen und reduziert unnötigen Netzwerkverkehr sowie Serverlast.
- Dennoch kann sie weiterhin Kommunikationsverzögerungen verursachen und ist weniger effizient als andere Echtzeittechniken wie WebSockets.
Was sind WebSockets?
- WebSockets bieten einen Full-Duplex-Kommunikationskanal über eine einzelne persistente Verbindung zwischen Client und Server.
- Diese Technologie ermöglicht den Datenaustausch zwischen Browser und Server ohne den Overhead des HTTP-Request-Response-Zyklus und eignet sich daher gut für die Übertragung von Echtzeitdaten.
- WebSockets stellen gegenüber traditionellem HTTP einen großen Fortschritt dar, denn nach dem Verbindungsaufbau können beide Seiten unabhängig Daten senden. Damit sind sie ideal für Szenarien mit niedriger Latenz und häufigen Updates.
Was sind Server-Sent Events?
- Server-Sent Events (SSE) bieten eine standardisierte Methode, Server-Updates über HTTP an den Client zu pushen.
- Anders als WebSockets ist SSE nur für unidirektionale Kommunikation vom Server zum Client ausgelegt und daher ideal für Situationen, in denen Clients Updates in Echtzeit empfangen sollen, ohne Daten an den Server senden zu müssen.
Was ist die WebTransport-API?
- WebTransport ist eine moderne API, die für effiziente Kommunikation mit niedriger Latenz zwischen Web-Clients und Servern entwickelt wurde.
- Sie nutzt das HTTP/3-QUIC-Protokoll, um verschiedene Formen der Datenübertragung zu ermöglichen.
- WebTransport ist ein leistungsfähiges Werkzeug für Anwendungen, die Hochleistungsnetzwerke benötigen, etwa Echtzeitspiele, Live-Streaming und Kollaborationsplattformen.
- WebTransport befindet sich derzeit noch im Status eines Working Draft und ist noch nicht breit etabliert.
Was ist WebRTC?
- WebRTC (Web Real-Time Communication) ist ein Open-Source-Projekt und API-Standard, der Echtzeitkommunikation (RTC) in Webbrowsern und mobilen Anwendungen ohne komplexe Serverinfrastruktur oder zusätzliche Plugins ermöglicht.
- WebRTC unterstützt Peer-to-Peer-Verbindungen für den Austausch von Audio, Video und Daten zwischen Browsern.
- WebRTC wurde dafür entwickelt, durch NAT und Firewalls hindurch zu funktionieren, und verwendet Protokolle wie ICE, STUN und TURN, um Verbindungen zwischen Peers herzustellen.
Grenzen der Technologien
- Nur WebSockets und WebTransport ermöglichen das Senden von Daten in beide Richtungen.
- Durch das Limit von 6 Requests pro Domain ist die Nutzbarkeit aller persistenten Server-Client-Messaging-Methoden eingeschränkt.
- In mobilen Apps verschiebt das Betriebssystem die App nach einer gewissen Zeit ohne Aktivität automatisch in den Hintergrund und schließt offene Verbindungen.
- In Unternehmensumgebungen blockieren viele Proxys und Firewalls Nicht-HTTP-Verbindungen, was die Integration von WebSocket-Servern in die Infrastruktur erschwert.
Leistungsvergleich
- Um die Leistung von WebSockets, SSE, Long Polling und WebTransport direkt zu vergleichen, müssen zentrale Aspekte wie Latenz, Durchsatz, Serverlast und Skalierbarkeit unter verschiedenen Bedingungen bewertet werden.
Latenz
- WebSockets: Bieten durch Full-Duplex-Kommunikation über eine einzelne persistente Verbindung die geringste Latenz.
- Server-Sent Events: Bieten niedrige Latenz für Kommunikation vom Server zum Client, erlauben aber ohne zusätzliche HTTP-Requests keine Nachrichten an den Server.
- Long Polling: Führt zu höherer Latenz, da für jede Datenübertragung eine neue HTTP-Verbindung aufgebaut werden muss.
- WebTransport: Es wird erwartet, dass es ähnlich niedrige Latenzen wie WebSockets bietet und durch das HTTP/3-Protokoll von effizienterem Multiplexing und Congestion Control profitiert.
Durchsatz
- WebSockets: Können dank der persistenten Verbindung hohen Durchsatz erreichen, der jedoch sinken kann, wenn der Client Daten nicht in der Geschwindigkeit verarbeiten kann, in der der Server sie sendet.
- Server-Sent Events: Können mit weniger Overhead als WebSockets Nachrichten an viele Clients broadcasten und dadurch bei unidirektionaler Server-Client-Kommunikation einen höheren Durchsatz erreichen.
- Long Polling: Bietet in der Regel geringeren Durchsatz aufgrund des Overheads durch häufiges Öffnen und Schließen von Verbindungen.
- WebTransport: Es wird erwartet, dass es hohen Durchsatz sowohl für bidirektionale als auch unidirektionale Streams innerhalb einer einzelnen Verbindung unterstützt und in Szenarien mit mehreren Streams WebSockets übertreffen kann.
Skalierbarkeit und Serverlast
- WebSockets: Das Aufrechterhalten einer großen Anzahl von WebSocket-Verbindungen kann die Serverlast deutlich erhöhen und die Skalierbarkeit von Anwendungen mit vielen Nutzern beeinträchtigen.
- Server-Sent Events: Sind wegen des geringeren Verbindungs-Overheads im Vergleich zu WebSockets besser skalierbar, insbesondere in Szenarien, in denen hauptsächlich Updates vom Server zum Client benötigt werden.
- Long Polling: Ist aufgrund der hohen Serverlast durch häufigen Verbindungsaufbau am wenigsten skalierbar.
- WebTransport: Wurde so konzipiert, dass es die Effizienz von Verbindungs- und Stream-Verarbeitung in HTTP/3 nutzt, und bietet daher hohe Skalierbarkeit bei geringerer Serverlast als WebSockets und SSE.
Empfehlungen und Eignung für Anwendungsfälle
- In der Landschaft der Server-Client-Kommunikationstechnologien hat jede Methode eigene Stärken und passende Einsatzszenarien.
- Server-Sent Events (SSE) sind am einfachsten zu implementieren und können technische Probleme vermeiden, indem sie Einschränkungen durch Unternehmens-Firewalls umgehen.
- WebSockets sind besonders stark in Szenarien, die dauerhafte bidirektionale Kommunikation erfordern.
- WebTransport ist schwierig in der Einführung, wird von Server-Frameworks einschließlich Node.js noch nicht breit unterstützt und ist nicht mit Safari kompatibel.
- Long Polling ist ineffizient und wird wegen des hohen Overheads durch das wiederholte Einrichten neuer HTTP-Verbindungen für die meisten Anwendungsfälle nicht empfohlen.
Bekannte Probleme
- Alle Echtzeit-Streaming-Technologien haben bekannte Probleme.
- Clients können Ereignisse verpassen, die auf dem Server auftreten, während sie verbunden werden, sich neu verbinden oder offline sind.
- Unternehmens-Firewalls können beim Einsatz von Streaming-Technologien Probleme verursachen.
Meinung von GN⁺
- Dieser Artikel vergleicht verschiedene Kommunikationstechnologien, die Entwickler beim Aufbau von Echtzeit-Webanwendungen nutzen können, und liefert damit nützliche Informationen für die Technologiewahl.
- WebSockets und SSE sind bereits weit verbreitet; insbesondere WebSockets sind bei Anwendungen mit bidirektionaler Kommunikation wie Echtzeit-Chat oder Spielen sehr beliebt.
- WebTransport befindet sich noch im Entwurfsstadium und wird noch nicht breit unterstützt, weshalb der Einsatz in realen Projekten derzeit schwierig sein kann. Als zukünftige Technologie auf Basis von HTTP/3 besitzt es jedoch viel Potenzial und ist daher beachtenswert.
- Long Polling ist zwar eine ältere Technik, kann in bestimmten Situationen aber weiterhin nützlich sein, insbesondere wenn die Kompatibilität mit Legacy-Systemen wichtig ist.
- Bei der Wahl einer Echtzeit-Kommunikationstechnologie sollten die Anforderungen der Anwendung, unterstützte Browser und Serverinfrastruktur sowie der Reifegrad der Technologie berücksichtigt werden.
1 Kommentare
Hacker-News-Kommentare
Jemand äußert seine Vorliebe für Server Sent Events (SSE) und erwähnt das Fehlen von Flow Control (Backpressure) und Multiplexing bei WebSockets, die Unmöglichkeit der Übertragung binärer Daten mit SSE sowie mögliche Einführungsprobleme bei WebTransport.
Es wird auf die Schwierigkeit hingewiesen, Echtzeitfunktionen in Unternehmensumgebungen zu implementieren, sowie auf die Grenzen der Problemlösung durch Bürokratie; als einfache Lösung wird das Hinzufügen eines Aktualisieren-Buttons vorgeschlagen.
Unter der Annahme von HTTP/2 oder höher wird die Meinung geäußert, dass die Kombination aus EventSource und fetch() ähnlich gut sein dürfte wie andere Protokolle, die eine einzelne TCP-Verbindung verwenden; außerdem wird die Nutzung von UDP in HTTP/3 erwähnt.
Jemand sagt, er wisse nicht, warum WebSockets und SSE beim initialen Request das Senden von Headern nicht unterstützen, und weist darauf hin, dass die Implementierung der Authentifizierung für Echtzeitdienste damit den jeweiligen Entwicklern überlassen bleibt.
Erwähnt werden Probleme bei der Verwaltung von WebSockets und SSE im großen Maßstab, besondere Anforderungen an die Beobachtbarkeit im Backend, Schwierigkeiten beim Debugging auf Mobilgeräten, die Kosten von Netzwerkverbindungen sowie die Schwierigkeit, Zustand aufrechtzuerhalten.
Jemand teilt seine Erfahrung, bei einem in den 90er-Jahren entworfenen Online-Auktionssystem Echtzeit-Updates per Server Push/HTTP-Streaming verarbeitet zu haben.
Jemand vermisst die Einfachheit von Long Polling und erwähnt zugleich eine positive Einschätzung von WebRTC.
Eine bei Stream arbeitende Person empfiehlt für die meisten Fälle WebSockets mit keep-alive-Pings alle 30 Sekunden und erwähnt Überlegungen zu der niedrigen Latenz von WebTransport sowie zu Echtzeitspielen und der Übertragung von Sprachdaten.
Es wird kritisch angemerkt, dass der Artikel die Vorteile von UDP-basierter Kommunikation bei WebRTC nicht erwähnt.