WebSockets in Java: Von Chats bis zu Börsencharts in Echtzeit

WebSockets in Java: Wenn HTTP nicht mehr ausreicht

Stellen Sie sich eine Online-Börse vor. Sie betrachten den Bitcoin-Kurschart. Jede Sekunde ändern sich die Zahlen. Oder ein Multiplayer-Spiel, bei dem Sie Ihre Spielfigur bewegen und hundert andere Spieler dies sofort sehen. Oder einfach einen Firmen-Chat, bei dem Nachrichten eintreffen, ohne dass Sie F5 drücken müssen.

Wie funktioniert das unter der Haube? Früher behalfen sich Entwickler mit Tricks: Polling (der Client fragt jede Sekunde den Server "Na, gibt es Neuigkeiten?"), Long Polling (der Server hält die Verbindung, bis es eine Neuigkeit gibt), Server-Sent Events (einseitiger Datenstrom). All das sind Krücken. Das HTTP-Protokoll wurde ursprünglich als Anfrage-Antwort konzipiert. Es kann keine Daten von sich aus "schieben".

Hier kommen WebSockets ins Spiel. Dieses Protokoll baut die Verbindung einmal auf – und hält sie offen. Der Server kann jederzeit Daten an den Client senden und umgekehrt. Bidirektionale Kommunikation in Echtzeit, ohne den Overhead von HTTP-Headern.

In diesem Artikel beleuchten wir WebSockets in Java von A bis Z. Wir schreiben einen vollwertigen Chat, gehen auf Fallstricke ein und vergleichen gängige Bibliotheken. Wenn Sie Java-Entwickler sind und Echtzeit-Anwendungen in Java erstellen möchten, sind Sie hier genau richtig.

Wie funktioniert WebSocket? Eine kurze Einführung

WebSocket ist keine Magie, sondern einfach ein Protokoll auf Basis von TCP. Es beginnt als normale HTTP-Anfrage (Handshake) und "upgradet" dann zu einem permanenten bidirektionalen Kanal.

Schritt 1: Handshake

Der Client sendet eine normale HTTP-GET-Anfrage mit dem Header Upgrade: websocket. Der Server antwortet mit dem Statuscode 101 Switching Protocols. Das war's. Ab diesem Moment werden die Daten nicht mehr als HTTP-Pakete, sondern als WebSocket-Frames übertragen.

Schritt 2: Daten-Frames

Die Daten werden in kleinen Paketen (Frames) übertragen. Ein Frame kann textuell (normaler String) oder binär (Bild, Audio) sein. Java-Bibliotheken verbergen diese Komplexität – Sie arbeiten einfach mit Strings oder Bytes.

Schritt 3: Verbindung schließen

Jede Seite kann das Schließen der Verbindung initiieren, indem sie einen speziellen Close-Frame sendet.

Klingt einfach? Ist es auch. Aber der Teufel steckt im Detail: Timeouts, Wiederverbindungen, Skalierung. Dazu später mehr.

Bibliotheken für WebSockets in Java

Im Java-Ökosystem gibt es drei Hauptansätze:

\n
• Jakarta WebSocket (JSR 356) – der Standard von Java EE / Jakarta EE. Funktioniert auf jedem kompatiblen Server (Tomcat, Jetty, GlassFish). Viele Annotationen, wenig Code.
\n
• Spring WebSocket – ein Aufsatz auf den Standard im Spring-Ökosystem. Bietet Integration mit Security, STOMP (ein Protokoll über WebSocket für Topic-Abonnements) und praktische Vorlagen.
\n
• Netty / Vert.x / Undertow – Low-Level asynchrone Frameworks. Maximale Leistung, aber mehr Code.
\n

Für 90% der Aufgaben reichen Jakarta oder Spring. Wir werden beide Varianten mit echten Beispielen betrachten.

Beispiel 1: Ein einfacher Chat mit Jakarta WebSocket (ohne Spring)

Angenommen, wir haben einen alten, guten Tomcat 10+ (Jakarta EE). Wir benötigen einen Server-Endpoint und einen Client (HTML+JS).

Server: Endpunkt-Klasse

import jakarta.websocket.*;\nimport jakarta.websocket.server.ServerEndpoint;\nimport java.io.IOException;\nimport java.util.Set;\nimport java.util.concurrent.CopyOnWriteArraySet;\n\n@ServerEndpoint("/chat")\npublic class ChatEndpoint {\n\n    // Speichert alle aktiven Sessions (threadsichere Menge)\n    private static final Set<Session> sessions = new CopyOnWriteArraySet<>();\n\n    @OnOpen\n    public void onOpen(Session session) {\n        sessions.add(session);\n        broadcast("Benutzer verbunden. Gesamt im Chat: " + sessions.size());\n    }\n\n    @OnMessage\n    public void onMessage(String message, Session session) {\n        // Logik hinzufügbar: nur an