Long Polling vs WebSocket: Was wählen für Echtzeit?

Long Polling vs WebSocket in JavaScript: Der epische Kampf um Echtzeit

Es war einmal, in einer Zeit, als das Internet langsam und die Browser einfältig waren, war die einzige Möglichkeit, herauszufinden, ob neue Daten auf dem Server vorhanden waren, F5 zu drücken. Dann kam AJAX, und wir lernten, den Server manuell zu befragen. Aber was ist, wenn die Daten von selbst kommen sollen, ohne unser Zutun? Willkommen in der Welt der Echtzeit-Kommunikation.

In diesem Artikel werden wir die beiden wichtigsten Ansätze untersuchen, die die Entwicklergemeinschaft bis heute spalten: das gute alte Long Polling und das moderne, kühne WebSocket. Wir werden Code in JavaScript schreiben, uns ihre Interna ansehen und verstehen, welches Werkzeug Sie für Ihr nächstes Projekt wählen sollten. Wenn Sie den Unterschied zwischen Long Polling vs WebSocket ein für alle Mal verstehen wollen, sind Sie hier genau richtig.

Das Problem: Wie bringt man den Server dazu, zuerst zu sprechen?

HTTP ist ein unidirektionales Protokoll. Der Client (Browser) sendet eine Anfrage, der Server antwortet – und das war's, Ende der Mahlzeit. Aber in der realen Welt (Chats, Börsenkurse, Benachrichtigungen) müssen Daten in die entgegengesetzte Richtung fließen. Lange Zeit haben Entwickler getrickst. Und hier sind die beiden wichtigsten Methoden, um dieses Problem zu lösen.

Long Polling: Ein cleverer Trick mit der Zeit

Stellen Sie sich vor, Sie rufen den Kundendienst an und sagen: "Ich warte in der Leitung, bis ein Mitarbeiter frei wird." Sie legen nicht auf. Genau so funktioniert Long Polling (auch "lange Abfrage" genannt).

Wie es funktioniert:

\n
• Der Client sendet eine normale HTTP-Anfrage.
\n
• Der Server antwortet nicht sofort, wenn keine Daten vorhanden sind. Er "hängt" und wartet.
\n
• Sobald Daten verfügbar sind, sendet der Server eine Antwort.
\n
• Der Client verarbeitet die Antwort und öffnet sofort eine neue Verbindung.
\n

Code auf dem Client (JavaScript):

function longPoll() {\n  fetch('/updates')\n    .then(response => response.json())\n    .then(data => {\n      console.log('Neue Daten:', data);\n      // Sofort eine neue Abfrage starten\n      longPoll();\n    })\n    .catch(error => {\n      console.error('Fehler, Wiederverbindung in 2 Sekunden:', error);\n      setTimeout(longPoll, 2000);\n    });\n}\n\n// Starten\nlongPoll();

Vorteile:

\n
• Funktioniert auf jedem Server und jedem Browser (sogar im IE6).
\n
• Erfordert keine speziellen Protokolle – reines HTTP.
\n
• Funktioniert durch alle Unternehmens-Proxys und Firewalls.
\n

Nachteile:

\n
• Jede Nachricht ist eine neue HTTP-Anfrage (Header, Cookies, Overhead).
\n
• Der Server hält viele offene Verbindungen (C10k-Problem – 10.000 Clients).
\n
• Die Latenz ist höher als bei WebSocket.
\n

WebSocket: Ein permanenter Kommunikationskanal

WebSocket ist wie eine offene Leitung zwischen einem Raumschiff und der Bodenkontrolle. Sie stellen die Verbindung einmal her, und dann können beide Seiten jederzeit Daten senden, ohne unnötige Formalitäten.

Wie es funktioniert:

\n
• Der Client initiiert einen Handshake über HTTP.
\n
• Der Server wechselt das Protokoll auf ws:// oder wss://.
\n
• Es wird eine permanente bidirektionale Verbindung hergestellt.
\n
• Daten werden in Frames übertragen – leichtgewichtig und schnell.
\n

Code auf dem Client (JavaScript):

const socket = new WebSocket('wss://example.com/chat');\n\n// Wenn die Verbindung geöffnet ist\nsocket.onopen = function() {\n  console.log('Verbindung hergestellt');\n  socket.send(JSON.stringify({ type: 'greeting', text: 'Hallo, Server!' }));\n};\n\n// Wenn eine Nachricht eintrifft\nsocket.onmessage = function(event) {\n  const data = JSON.parse(event.data);\n  console.log('Nachricht vom Server:', data);\n};\n\n// Bei einem Fehler\nsocket.onerror = function(error) {\n  console.error('WebSocket-Fehler:', error);\n};\n\n// Bei Schließung\nsocket.onclose = function(event) {\n  console.log('Verbindung geschlossen. Code:', even