WebSockets
Die wichtigsten Befehle zum Merken
websocat -s ADRESSE:PORT— einen kleinen lokalen WebSocket-Server starten.websocat ws://…— einen interaktiven Client verbinden.
Befehle und Optionen
| Option oder Taste | Bedeutung |
|---|---|
-s 127.0.0.1:8765 |
Nur auf IPv4-Loopback-Port 8765 als Server lauschen. |
ws://127.0.0.1:8765 |
Ohne TLS zum lokalen WebSocket-Endpunkt verbinden. |
Enter |
Die eingegebene Zeile im interaktiven Textmodus senden. |
Ctrl+C |
Client beziehungsweise Server im jeweiligen Terminal beenden. |
Der erste Block gehört in Terminal A, der zweite in B. Das ist ein lokaler Textaustausch, kein Produktionsserver.
Die entscheidenden Konzepte
1. Eine Verbindung bleibt für beide Nachrichtenrichtungen offen
WebSocket ermöglicht bidirektionale Kommunikation über eine dauerhafte Verbindung. Nach dem Aufbau können beide Seiten Nachrichten senden, ohne für jede Aktualisierung eine neue HTTP-Anfrage abzuwarten.
Das passt zu Benachrichtigungen, Zusammenarbeit und Steuerverkehr. Es ändert das Interaktionsmuster, nicht den Bedarf an Authentifizierung oder Kapazitätsplanung. Jede offene Verbindung belegt Ressourcen.
2. Der Eröffnungshandshake unterscheidet sich vom Nachrichtenaustausch
Der klassische Handshake beginnt als HTTP/1.1-Upgrade. Nach erfolgreichem Wechsel tragen WebSocket-Frames die Nachrichten. Ein erfolgreicher gewöhnlicher GET beweist keine WebSocket-Unterstützung desselben Servers.
ws ist unverschlüsselt, wss verwendet TLS. Ein Proxy muss Upgrade beziehungsweise den passenden Protokollmechanismus und langlebigen Verkehr unterstützen.
3. Nachrichten haben Grenzen, können aber mehrere Frames nutzen
WebSocket unterstützt Text- und Binärnachrichten. Eine Nachricht kann mehrere Frames umfassen. Anwendungen sollten Frame-Grenzen nicht mit fachlichen Datensätzen verwechseln. Client-Masking ist ein Protokollmechanismus, keine Verschlüsselung.
Ping, Pong und Close sind Kontrollframes. Sie verwalten die Verbindung. Pong beweist nicht, dass ein bestimmter Anwendungsbefehl verarbeitet wurde. Dafür bleiben eigene Bestätigungen nötig.
4. Wiederverbinden stellt Anwendungszustand nicht automatisch her
Netzwerkwechsel, Leerlauf-Timeouts, Proxyrichtlinien und Prozessausfälle können Verbindungen beenden. Eine neue Verbindung spielt keine Ereignisse automatisch nach und klärt nicht den Ausgang des letzten Befehls.
Anwendungen benötigen gegebenenfalls Sequenzkennungen, Fortsetzungsregeln, Duplikatbehandlung und Rückstaukontrolle. Langsame Empfänger dürfen keine unbegrenzten Puffer erzeugen. Der Transport bietet einen Kanal, keinen dauerhaften Ereignisspeicher.
Ein kleines Beispiel
Optional: Starte den ersten Befehl in Terminal A und danach den Client in B. Lass beide offen.
websocat -s 127.0.0.1:8765websocat ws://127.0.0.1:8765Tippe in B hello und drücke Enter. Suche die Zeile in A. Tippe dort reply, drücke Enter und prüfe B. Das sind deine Nachrichten, keine vorgegebenen Messergebnisse. Keine Seite spiegelt den Text hier automatisch zurück.
Ist Port 8765 belegt, stoppe keinen fremden Prozess. Verwende in beiden Befehlen denselben freien lokalen Port. Eine abgelehnte Verbindung bedeutet fehlende Endpunkterreichbarkeit, keinen nachgewiesenen Framingfehler.
Beende zum Schluss beide Terminalsitzungen mit Ctrl+C. Die Sockets schließen; Dateien bleiben nicht zurück.
Merke dir: WebSocket hält einen bidirektionalen Nachrichtenkanal offen. Wiederherstellung und fachlicher Erfolg brauchen dein Anwendungsprotokoll.