WebSocket: Vom Polling zur direkten Verbindung: Warum Echtzeit-Anwendungen dieses Protokoll brauchen

Vor einiger Zeit habe ich gerade eine einfache Seite erstellt, um Live-Serverprotokolle anzuzeigen. Die ursprüngliche Idee bestand lediglich darin, die Seite alle 5 Sekunden mithilfe von JavaScript zu aktualisieren. Wenn man sich die Ergebnisse ansieht, fühlt es sich an, als würde man im SMS-Zeitalter auf eine Nachricht warten: angespannt, langsam und verschwendet den Akku. Mir ist gerade aufgefallen, dass es eine viel elegantere Möglichkeit für die bidirektionale Kommunikation zwischen dem Browser und dem Server gibt: WebSocket.

WebSocket ist wie ein direkter Tunnel, der vom Browser zum Server öffnet. Sobald die Tür geöffnet ist, können sich beide Parteien jederzeit gegenseitig Nachrichten senden, ohne eine neue Tür öffnen zu müssen. Wenn normales HTTP so ist, als würde man das Haus eines Freundes besuchen und nach dem Chatten direkt nach Hause gehen, ist WebSocket so, als würde man über eine Gegensprechanlage chatten, die immer verbunden ist.

HTTP ist keine bidirektionale Route

Vor WebSocket war die Abfrage die häufigste Methode, um die neuesten Daten von einem Server abzurufen. Der Browser fordert alle paar Sekunden Daten vom Server an, auch wenn sich die Daten nicht unbedingt ändern. Es ist, als würde man einen Freund fragen: „Bist du schon da?“ jede Minute, obwohl er noch unterwegs war.

Es gibt eine effizientere Variante namens Long Poll. Der Server hält die Anfrage zurück, bis neue Daten vorliegen, und antwortet dann. Dennoch muss jede Antwort geschlossen und eine neue Anfrage erneut geöffnet werden. Der Overhead ist immer noch groß, insbesondere für Anwendungen, die eine geringe Latenz erfordern, wie Chat, Live-Benachrichtigungen oder Dashboard-Überwachung.

HTTP ist für Request-Response konzipiert: Client-Anfragen, Server-Antworten, fertig. Es verfügt nicht über einen integrierten Mechanismus, mit dem der Server aktiv Daten an den Client senden kann. WebSocket füllte diese Lücke.

WebSocket: TCP-Tunnel über HTTP geöffnet

WebSocket beginnt mit einfachem HTTP. Der Client sendet eine Anfrage mit einem speziellen Header:

GET /chat HTTP/1.1
Host: example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13

Server, die WebSocket unterstützen, antworten mit dem Status 101 Switching Protocols:

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

Nach diesem Handshake ändert sich die HTTP-Verbindung in eine WebSocket-Verbindung. Von hier aus können sich Browser und Server gegenseitig Frames-Daten im selben Kanal senden, ohne wiederholte HTTP-Header. Leichter, schneller und in Echtzeit.

Praktisch: Ein einfacher Node.js-Server

Ich mag Node.js für WebSocket-Experimente, weil es leichtgewichtig ist. Installieren Sie einfach das ws-Paket und erstellen Sie dann eine Serverdatei. Das folgende Beispiel erstellt einen Server, der Nachrichten von einem Client an alle verbundenen Clients sendet:

// server.js
const WebSocket = require('ws');
const wss = new WebSocket.Server({ port: 8080 });

wss.on('connection', (ws) => {
  console.log('Client baru terhubung');

  ws.on('message', (message) => {
    const text = message.toString();
    console.log('Diterima:', text);

    // Broadcast ke semua client
    wss.clients.forEach((client) => {
      if (client.readyState === WebSocket.OPEN) {
        client.send(text);
      }
    });
  });

  ws.on('close', () => {
    console.log('Client terputus');
  });
});

console.log('WebSocket server berjalan di ws://localhost:8080');

Mit node server.js ausführen, dann ist der Server bereit, Verbindungen zu akzeptieren. Der interessanteste Teil: Eine Zeile client.send() vom Server kann direkt zum Browser gehen, ohne auf eine neue Anfrage warten zu müssen.

Client im Browser

Auf der Browserseite verwenden wir das in JavaScript integrierte WebSocket-Objekt. Für einfache Fälle sind keine zusätzlichen Bibliotheken erforderlich:

// client.js
const socket = new WebSocket('ws://localhost:8080');

socket.addEventListener('open', () => {
  console.log('Terhubung ke server');
  socket.send('Halo dari browser!');
});

socket.addEventListener('message', (event) => {
  console.log('Pesan dari server:', event.data);
  document.getElementById('log').innerText += event.data + '\n';
});

socket.addEventListener('close', () => {
  console.log('Koneksi tertutup');
});

socket.addEventListener('error', (error) => {
  console.error('Terjadi error:', error);
});

Achten Sie auf das message-Ereignis: Dies unterscheidet WebSocket von fetch oder AJAX. Der Server kann dieses Ereignis jederzeit auslösen. Der Browser muss nicht aktualisiert oder abgefragt werden. Hören Sie einfach zu, als wäre das Radio immer eingeschaltet.

Wann sollten Sie WebSocket verwenden?

WebSocket ist nicht die Lösung für alle Probleme. Am wertvollsten ist es, wenn die Anwendung über ein Push-Muster vom Server zum Client verfügt. Hier sind einige Beispiele:

• Chat und Messaging: Eingehende Nachrichten müssen dem Empfänger sofort angezeigt werden, ohne dass sie neu geladen werden müssen.
• Live-Benachrichtigung: Echtzeitbenachrichtigungen wie Überwachungswarnungen oder Aktienkursaktualisierungen.
• Gemeinsame Bearbeitung: Google Docs-Stil, wobei Änderungen eines Benutzers für andere Benutzer sofort sichtbar sein müssen.
• Online-Gaming: Niedrige Latenz ist alles.
• IoT-Dashboard: Sensoren senden kontinuierlich Daten an das Dashboard.

Alle oben genannten Szenarien haben etwas gemeinsam: Die Daten fließen kontinuierlich, die Richtung kann in beide Richtungen erfolgen und die Verzögerung muss gering sein.

Wann ist WebSocket nicht notwendig?

Andererseits erhöht die Verwendung von WebSocket für Dinge, die tatsächlich für die Verwendung von regulärem HTTP geeignet sind, tatsächlich die Komplexität. Verwenden Sie WebSocket nicht, wenn:

• Daten ändern sich selten und Benutzer benötigen keine sofortigen Updates.
• Für die Anwendung ist nur eine einfache Anfrage/Antwort erforderlich, etwa eine Anmeldeseite oder ein Absendeformular.
• Ihr Server verfügt nicht über einen Mechanismus, um viele offene Verbindungen gleichzeitig zu verarbeiten.

WebSocket hält Verbindungen offen. Jede Verbindung beansprucht Speicher und einen Dateideskriptor. Wenn die Anwendung ausreicht, um alle 30 Sekunden eine Abfrage durchzuführen, besteht möglicherweise kein Grund zur Sorge.

Sicherheits- und Produktionshinweise

Wenn sich die Anwendung in der Produktion befindet, vergessen Sie nicht, wss:// anstelle von ws:// zu verwenden. wss:// ist die verschlüsselte Version, genau wie HTTPS. Bedenken Sie außerdem Folgendes:

• Authentifizierung: Client-Verifizierung während des Handshakes, zum Beispiel über ein Token im Abfragestring oder Cookie.
• Ratenbegrenzung: begrenzt, wie viele Nachrichten der Client pro Sekunde senden kann.
• Heartbeat: Senden Sie regelmäßig Ping/Pong, um sicherzustellen, dass die Verbindung noch aktiv ist.
• Erneut verbinden: Bereiten Sie im Browser die Wiederverbindungslogik mit exponentiellem Backoff vor, falls die Verbindung verloren geht.

Auf dem Heimserver verwende ich WebSocket häufig für kleine Dinge: Überwachungsprotokolle, Download-Status oder Benachrichtigungen zum Backup-Prozess. Das Ergebnis? Das Dashboard fühlt sich lebendig an, ohne dass es jedes Mal aktualisiert werden muss.

Schlussfolgerung

WebSocket ist ein Protokoll, das die Webkommunikation von einem „Frage-und-Antwort“-Muster in eine fortlaufende wechselseitige Konversation umwandelt. Für Echtzeitanwendungen ist es viel effizienter als Polling oder Long Polling. Aber wie jede Technologie hat sie ihren rechtmäßigen Platz: Nutzen Sie sie, wenn Sie Server-Push, geringe Latenz und dauerhafte Verbindungen benötigen.

Wenn Sie ein kleines Projekt haben, das Live-Updates benötigt, versuchen Sie, einen einfachen WebSocket-Server zu erstellen. Es fühlt sich anders an, wenn der Browser nicht mehr ein Besucher ist, der ständig an die Tür klopft, sondern ein Bewohner, der im Wohnzimmer sitzt und plaudert.

Haben Sie selbst Erfahrung mit WebSocket? Oder sind Sie immer noch verwirrt, wann Sie Polling und wann WebSocket verwenden sollten? Schreiben Sie in die Kommentarspalte, ich würde gerne Ihre Geschichte hören.