Zum Inhalt springen

WebSocket-Tester

WebSocket Tester

Öffnet eine WebSocket-Verbindung, sendet von Ihnen verfasste Frames und protokolliert alles Empfangene mit Zeiten.

Öffnet einen WebSocket von Ihrem Browser zu einem Server, den Sie nennen, sendet, was Sie tippen, und protokolliert jeden Frame in beide Richtungen mit Zeiten. Die Verbindung ist die des Browsers selbst – nichts läuft über unseren Server, ein Entwicklungs-Endpunkt auf Ihrem Rechner funktioniert also genauso wie ein öffentlicher.

🔒 Läuft vollständig in Ihrem Browserwebsockettestrealtimedebug

Die Verbindung baut Ihr Browser selbst auf. Weder die Adresse noch irgendetwas Gesendetes oder Empfangenes läuft über unseren Server.

Diese Seite wird über https ausgeliefert, also blockiert der Browser unverschlüsseltes ws:// als Mixed Content. Nehmen Sie wss://, oder öffnen Sie Ihren Entwicklungsserver über lokales http.

Durch Kommas getrennt. Sie werden im Header Sec-WebSocket-Protocol angeboten, und der Server wählt eines aus.

Ein Browser darf nur 1000 oder 3000–4999 senden (RFC 6455 §7.4).

Untätig

Senden

Protokoll

Empfangene Frames sind ▼, gesendete ▲. Die Zeiten zählen ab dem ersten Eintrag.

Noch nichts.

  • Die WebSocket-API des Browsers kann von sich aus keine Ping- oder Pong-Frames senden und keine eigenen Header anhängen. Wo Authentifizierung nötig ist, ist ein Token in der ersten Nachricht, im Query-String der URL oder als Subprotokoll die übliche Lösung.

So funktioniert es

  1. Geben Sie eine wss://-Adresse ein

    Diese Seite wird über https ausgeliefert, der Browser blockiert unverschlüsseltes ws:// also als Mixed Content. Ein Subprotokoll kann mit angeboten werden; der Server wählt eines, und das Protokoll sagt, welches.

  2. Senden Sie einen Frame

    Gültiges JSON wird vor dem Senden auf eine Zeile verdichtet, eine eingefügte, hübsch formatierte Nachricht geht also so hinaus, wie ein Client sie senden würde. Alles, was kein JSON ist, geht wie getippt.

  3. Lesen Sie das Protokoll nach Richtung und Zeit

    Empfangene Frames sind ▼, gesendete ▲, Ereignisse ●, und jeder ist mit der seit dem ersten Eintrag verstrichenen Zeit gestempelt. So unterscheiden Sie einen Server, der nie geantwortet hat, von einem, der langsam geantwortet hat.

  4. Schließen Sie mit einem Code, wenn Sie einen brauchen

    Ein Browser darf nur 1000 oder 3000–4999 senden (RFC 6455 §7.4), Ihre eigenen Codes gehören also in den anwendungsdefinierten Bereich. Der zurückkommende Schließcode wird in Worten ausgeschrieben.

Häufige Fragen

Kann ich einen Authorization-Header hinzufügen?

Aus einem Browser nicht – die WebSocket-API erlaubt überhaupt keine eigenen Header. Die Konventionen sind ein Token in der ersten Nachricht, in der URL-Query oder als Subprotokoll eingeschmuggelt; welche davon, entscheidet der Server.

Es wurde mit 1006 und ohne Grund geschlossen

1006 heißt, die Verbindung ist ohne Schließ-Frame abgebrochen – der Server ist abgestürzt, ein Proxy hat einen Timeout ausgelöst oder der Handshake wurde abgelehnt. Browser halten den Grund aus Sicherheitsgründen absichtlich zurück, die Antwort steht also im Serverprotokoll, nicht hier.

Kann ich einen Ping-Frame senden?

Nein. Browser beantworten Pings automatisch und geben der Seite keinen Weg, einen zu senden. Anwendungen, die einen Heartbeat brauchen, senden eine gewöhnliche Nachricht und verlassen sich darauf, dass der Server antwortet.

Läuft mein Verkehr über Ihren Server?

Nein. Der Browser verbindet sich direkt, Adresse und jeder Frame bleiben also zwischen Ihnen und diesem Server. Das bedeutet auch, dass ein localhost-Endpunkt hier funktioniert, den ein serverseitiger Tester nie erreichen könnte.

Eingabe aus

Danach

Diese Tools nehmen an, was dieses hier erzeugt, das Ergebnis kann also direkt weiter.