Langes Polling vs. WebSockets

Webanwendungen wurden ursprünglich als Client-Server-Architektur konzipiert. Clients erstellen eine HTTP/HTTPS-Anfrage an den entsprechenden Server, um eine Information anzufordern oder zu ändern. Eine einfache Webanwendung folgt beispielsweise einem ähnlichen Ablauf.

1. Der Client fordert Daten vom Server an

2. Der Load Balancer leitet die Anfragen an den entsprechenden Server weiter

3. Der Server fragt die entsprechende Datenbank nach einigen Daten ab

4. Die Datenbank gibt die abgefragten Daten an den Server zurück.

5. Der Server verarbeitet die Daten und sendet sie an den Client zurück.

Eine einfache HTTP-Anfrage ist der gängigste Weg, um Serverinformationen zu erhalten. Was aber, wenn Sie Daten zurückerhalten möchten, sobald sie der Datenbank hinzugefügt oder an den Server gesendet wurden? Bei einer einfachen Webanwendung, die als Client-Server-Architektur konzipiert ist, müssten Sie diesen Vorgang immer wieder wiederholen, um zu prüfen, ob neue Informationen in die Datenbank aufgenommen wurden. Dieser Prozess ist bekannt als Abfrage oder manchmal auch als kurzes Polling bezeichnet. Der Nachteil dieses Ansatzes ist, dass die meiste Zeit über keine Daten zurückgegeben werden, da der Server keine neuen Informationen erhalten hat. Lassen Sie uns dieses Problem lösen und die Vor- und Nachteile von Long Polling und Websockets diskutieren.

Überblick: Langes Polling vs. WebSockets

Langes Polling

Long Polling ist ein Ansatz bei dem der Client eine API-Anfrage an den Server sendet, aber anstatt eine sofortige Antwort vom Server zu erhalten, muss die HTTP-Verbindung aufrechterhalten werden. Die Aufrechterhaltung der HTTP-Verbindung ermöglicht es dem Server, zu einem späteren Zeitpunkt zu antworten, wenn Daten verfügbar sind oder die Timeout-Schwelle erreicht wurde. Nach Erhalt der Antwort sendet der Client sofort die nächste Anfrage.

Anstatt, wie beim Polling, zahlreiche Anfragen zu senden, bis der Server neue Informationen erhält, muss der Client nur eine Anfrage an den Server senden, um die neuesten Informationen zu erhalten. Nach Erhalt der Daten kann der Client eine neue Anfrage starten und diesen Vorgang so oft wie nötig wiederholen.

Ein Ablauf für Long Polling sieht wie folgt aus:

1. Der Client stellt eine HTTP-Anfrage an den Server und fordert einige Daten an.

2. Der Server antwortet nicht sofort mit den angeforderten Informationen, sondern wartet, bis neue Informationen verfügbar sind.

3. Wenn neue Daten verfügbar sind, antwortet der Server mit neuen Informationen.

4. Der Client empfängt diese Daten und sendet sofort eine weitere Anfrage an den Server, um den Prozess neu zu starten.

WebSockets

WebSockets sind eine moderne Technologie die auf dem TCP/IP-Stack eines Geräts aufbaut. Die einzige Beziehung zum HTTP-Protokoll besteht darin, dass HTTP-Server das Handshake interpretieren, um eine Verbindung herzustellen. Es handelt sich um eine bidirektionale, voll-duplex Protokoll, das zustandsabhängig ist, d. h. die Verbindung zwischen Client und Server bleibt so lange bestehen, bis eine der beiden Parteien beschließt, sie zu beenden.

Im Gegensatz zum Long-Polling, das nur eine Halbduplex-Lösung ist, muss der Prozess nach Erhalt der letzten Informationen vom Server nicht wiederholt werden. Die WebSocket-Technologie ermöglicht es uns, die Verbindung nach der Rückgabe der neuen Informationen aufrechtzuerhalten und bidirektionale Aktualisierungen durchzuführen. Der Client kann Informationen an den Server zurücksenden und in derselben Anfrage auf weitere Informationen warten.

Ein WebSocket-Verbindungsablauf sieht in etwa so aus:

1. Die Client-Seite initiiert einen WebSocket, indem sie eine Anfrage sendet, die einen Upgrade-Header enthält, um das Kommunikationsprotokoll auf ein WebSocket-Protokoll umzustellen

2. Wenn der Server eine Verbindung herstellen kann und mit den Bedingungen des Clients einverstanden ist, sendet er eine Antwort an den Client, in der er die WebSocket-Handshake-Anforderung bestätigt.

3. Sobald der Client eine erfolgreiche WebSocket-Verbindung erhält, können der Client und der Server nun damit beginnen, Daten in beide Richtungen zu senden, was eine Echtzeitkommunikation ermöglicht.

4. Der Server oder der Client beschließt, die Verbindung zu beenden.

Wann sollte man Long Polling gegenüber WebSockets wählen?

Es gibt eine Debatte darüber, wann das Long Polling oder das WebSocket-Protokoll verwendet werden sollte. Beide haben ihre Vorteile und Grenzen und werden oft für unterschiedliche Zwecke verwendet. In diesem Abschnitt werden wir die wichtigsten Vorteile von Long Polling und WebSockets diskutieren.

Vorteile von Long Polling gegenüber WebSockets

Kompatibilität: Long Polling ist eine ältere Technologie, die eher als Technik verwendet wird, was sie zu einer kompatibleren Option als WebSockets macht. Sie basiert auf XMLHttpRequestauf und ist mit einer breiteren Palette von Webbrowsern und Netzwerkkonfigurationen kompatibel.

Netzwerk: Bei der heutigen Technologie wechseln die Menschen ständig die Netzwerke von 3G über LTE bis hin zu WiFi. WebSockets müssen so konfiguriert werden, dass sie sich an eine Änderung der Netzwerkverbindung anpassen. Diese Konfiguration ist erforderlich, weil die Verbindung mit dem Server neu aufgebaut werden muss und nicht wiederhergestellt werden kann, nachdem der Client sich entschieden hat, die Verbindung zu schließen. Bei Long Polling ist dies kein Problem, da es so eingerichtet ist, dass der Client nach einer bestimmten Zeit (in der Regel 20 Sekunden) versucht, eine weitere Anfrage zu senden, um die Verbindung mit dem Server automatisch wiederherzustellen, und nicht wie bei WebSockets in einem Fehlerzustand behandelt werden muss.

Anwendungsfälle für Long Polling statt WebSockets

Long Polling und WebSockets werden im Allgemeinen in Fällen verwendet, in denen Aktualisierungen in Echtzeit erforderlich sind. Einige Beispiele hierfür sind In-App-Chats, Preisgestaltung in Echtzeit, Geotracking und IoT.

Long Polling bietet Vorteile gegenüber WebSockets in Anwendungsfällen mit niedrigfrequenten Echtzeit-Updates. Diese Vorteile liegen darin, dass Long Polling eine Halbechtzeitlösung ist, bei der die Verbindung neu aufgebaut werden muss. Außerdem ist Long Polling, wie bereits erwähnt, so konzipiert, dass die Verbindung ohne zusätzliche Komplikationen wiederhergestellt werden kann, wenn sich die Benutzer in einer Umgebung mit geringer Bandbreite oder einem instabilen Netzbetreiber befinden. Allerdings handelt es sich bei Long Polling um eine ältere Technologie/Technik zur Durchführung von Echtzeit-Aktualisierungen. Daher ist sie weniger fortschrittlich und weniger flexibel als WebSockets, bietet aber mehr Unterstützung für Legacy-Systeme.

Wann sollte man sich für WebSockets und wann für Long Polling entscheiden?

Vorteile von WebSockets gegenüber Long Polling

Geringere Ressourcenauslastung: WebSockets unterhalten eine dauerhafte Verbindung zwischen dem Client und dem Server, wodurch der Overhead des Aufbaus einer neuen Verbindung für jede Echtzeitaktualisierung reduziert wird. Die konstante Verbindung reduziert die Ressourcennutzung auf der Client- und Serverseite in Bezug auf Netzwerkbandbreite, Speicher und CPU, um eine Echtzeitkommunikation zu erreichen.

Verbesserte Skalierbarkeit: Aufgrund der Natur von WebSockets und der bidirektionalen Kommunikation zwischen Client und Server kann der Server Aktualisierungen in Echtzeit an den Client weiterleiten, wodurch die Anzahl der gesendeten Anfragen reduziert wird. Langes Polling muss jedes Mal eine Verbindung neu aufbauen, wenn der Client neue Informationen benötigt. Wenn die Zahl der Benutzer steigt, kann dies für einen einzelnen Server eine große Belastung darstellen.

Erweiterte Funktionalität: WebSockets bieten Vollduplex-Kommunikationskanäle, die eine Datenübertragung in Echtzeit und geringe Latenzzeiten ermöglichen. Langes Polling wird manchmal nur als eine Halbechtzeitlösung angesehen und ist nicht ideal für Szenarien mit hohem Datenverkehr oder Anwendungsfälle, die Echtzeitaktualisierungen erfordern. Erweiterte Funktionen sorgen für eine reibungslosere Erfahrung der Endbenutzer, da sie nahtlosere Updates für ihre Anwendung erhalten.

Anwendungsfälle, die WebSockets dem Long Polling vorziehen

WebSockets eignen sich besser für Anwendungen, die häufige Aktualisierungen erfordern. Beispiele hierfür sind Chat-Anwendungen oder Echtzeit-Dateneinspeisungen. Die dauerhafte Verbindung ermöglicht eine effiziente Übertragung, die für den Endnutzer eine nahtlose Erfahrung darstellt. Multiplayer-Spiele und Kollaborationstools verwenden im Allgemeinen ebenfalls WebSockets. Die bidirektionale Zwei-Wege-Kommunikation ermöglicht es dem Server, dem Client Signale zu senden, was für den Empfang von Echtzeit-Updates von anderen Clients von Vorteil sein kann. So kann der Server dem Client beispielsweise signalisieren, dass er die Position eines anderen Spielers in Abhängigkeit von dessen Aktionen aktualisieren soll.

Im Hinblick auf die Skalierung, oder wenn die Anzahl der Benutzer steigt, ist es ideal, zum WebSocket-Protokoll zu wechseln. Die Belastung eines einzelnen Servers wird zu groß, wenn die Client-Basis eine lange Polling-Technologie verwendet. Wenn alle 20 Sekunden eine Anfrage gesendet wird, ist die Auslastung schlecht und der Server wird mit der Zeit langsamer, was die Latenzzeit pro Anfrage.

Wie PubNub in die Diskussion zwischen Long Polling und WebSockets passt

WebSockets und Long Polling bieten wertvolle Lösungen für die Erstellung von Echtzeitanwendungen. Bei der Entwicklung dieser Anwendungsfälle kommen jedoch viele andere Überlegungen ins Spiel. Mit der heutigen Technologie ist nichts so einfach wie das Senden einer Nachricht oder von Daten von einem Client zu einem anderen. Fast immer ist zusätzlich zu dem Echtzeitsystem, das ein Entwickler zu erstellen versucht, eine weitere Funktionalität erforderlich. In einem In-App-Chat können Sie zum Beispiel Präsenz-Updates (Signalisierung), wenn Benutzer online sind, Profanity-Filterung oder sogar Lesen/Zustellen von Nachrichten betrachten.

Neben der Hinzufügung spezifischer Funktionen gibt es immer noch Probleme mit der zugrundeliegenden Infrastruktur, wie z. B. die Komplexität bei der Handhabung der Skalierbarkeit. Bei der Verwendung bestimmter Technologien wie Socket.io verwenden, um einen WebSocket zu erstellen, müssen sich die Entwickler immer noch darum kümmern, dynamisch Server auf der ganzen Welt hinter einem Load Balancer aufzustellen, um die Auslastung der einzelnen Server zu verwalten. Diese Probleme werden immer komplexer, je mehr man skaliert.

Die Echtzeit-Daten-APIs von PubNub ermöglichen die Entwicklung leistungsfähiger, ereignisgesteuerter Anwendungen zur Erleichterung der Echtzeitkommunikation über alle Geräte hinweg, unabhängig vom jeweiligen Anwendungsfall. PubNub bietet eine Vielzahl von SDKs, wie z.B. ein JavaScript SDK für Webanwendungen und ein C-Core SDK für IoT-Anwendungen, um eine nahtlose Integration mit dem gewählten Gerät zu gewährleisten. Mit PubNub müssen Sie sich keine Gedanken über die Auswahl einer geeigneten Alternative oder die zugrunde liegende Komplexität der Implementierung einer Echtzeitlösung machen.

Jetzt, da Sie wissen, wann Long Polling und wann WebSockets eingesetzt werden sollten melden Sie sich für eine kostenlose Testversion an oder planen Sie eine Demo um herauszufinden, was Sie mit PubNub bauen können.

Wie kann PubNub Ihnen helfen?

Dieser Artikel wurde ursprünglich auf PubNub.com veröffentlicht.

Unsere Plattform unterstützt Entwickler bei der Erstellung, Bereitstellung und Verwaltung von Echtzeit-Interaktivität für Webanwendungen, mobile Anwendungen und IoT-Geräte.

Die Grundlage unserer Plattform ist das größte und am besten skalierbare Echtzeit-Edge-Messaging-Netzwerk der Branche. Mit über 15 Points-of-Presence weltweit, die 800 Millionen monatlich aktive Nutzer unterstützen, und einer Zuverlässigkeit von 99,999 % müssen Sie sich keine Sorgen über Ausfälle, Gleichzeitigkeitsgrenzen oder Latenzprobleme aufgrund von Verkehrsspitzen machen.

PubNub erleben

Sehen Sie sich die Live Tour an, um in weniger als 5 Minuten die grundlegenden Konzepte hinter jeder PubNub-gestützten App zu verstehen

Einrichten

Melden Sie sich für einen PubNub-Account an und erhalten Sie sofort kostenlosen Zugang zu den PubNub-Schlüsseln

Beginnen Sie

Mit den PubNub-Dokumenten können Sie sofort loslegen, unabhängig von Ihrem Anwendungsfall oder SDK