WebSocket Testing

Why it matters

There is no status code per message, so a lost, duplicated or out-of-order update raises no error: the customer just sees "picked up" after "delivered", or a chat message twice. And because connections stay open for hours, some failures never appear in a quick check: a proxy that cuts idle connections, a session that expires mid-connection, server memory that grows with every client.

The tester's question changes from "what does this request return?" to "what must arrive, in what order, within what time, and what happens after a drop?"

The opening handshake

The client sends an HTTP/1.1 GET with Upgrade: websocket, Sec-WebSocket-Version: 13 and a random Sec-WebSocket-Key. A server that accepts answers 101 Switching Protocols with a Sec-WebSocket-Accept value derived from that key; from then on the same TCP connection carries WebSocket frames. Production should use wss:// (over TLS), not ws://.

In this HTTP/1.1 handshake any other status means no WebSocket was opened (over HTTP/2, RFC 8441 uses a CONNECT request answered with 200 instead), so access rules are tested here. Cookies travel with the handshake, and RFC 6455 says a server should answer 403 when the Origin header names a site it does not accept. Browser scripts cannot add custom headers, so tokens often travel in the URL, where they can end up in logs. A script never sees the status of a rejected handshake, only a failed connection with close code 1006; read the real status in the developer tools' Network panel.

• No session, an expired session or no access: no 101, but the 401 or 403 the contract names.
• An origin the server does not accept: 403. A browser always sends the origin of the page it runs on, so connecting from another site, such as the WebSocket Tester, already tests a foreign origin; a missing or forged Origin needs a client outside the browser. Test only systems you own or have written permission to test.
• A page served over HTTPS that opens ws://: the browser blocks it as mixed content.

GET /live HTTP/1.1
Host: shop.example.test
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13
Origin: https://shop.example.test

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

Try it: WebSocket Tester

Messages, control frames and close codes

Data travels in frames. A message is text (UTF-8) or binary and may span several frames. A ping control frame must be answered with a pong; browsers do this automatically but hide both from scripts, so applications often add their own heartbeat message. There are no built-in acknowledgements: if the client must know that a message was processed, the application defines a reply, usually echoing an id.

Test messages as you would a REST body: required fields, types, unknown message types, malformed JSON, and the size limit and one byte above it. Either side ends the connection with a close frame, which normally carries a code and an optional reason; the other side answers with its own close frame. The RFC 6455 codes you meet most:

• 1000 normal closure; 1001 going away, such as a server shutting down or a browser leaving the page.
• 1003 a data type the endpoint cannot accept; 1007 data that does not fit the message type, such as invalid UTF-8 in text; 1008 policy violation; 1009 message too big; 1011 an unexpected server condition, the counterpart of a 500.
• 1005 and 1006 are never sent in a close frame: an endpoint reports 1005 itself when the close frame it received had no code, and 1006 when the connection ended without a close frame, after a network drop, a killed process or a proxy timeout.
• Codes from 4000 to 4999 are for private use: an API may define 4401 for an expired session, and it means only what that API's documentation says.

Try it: JSON Schema Validator Try it: JSON Formatter

Testing ordering and reconnection

On one connection, frames arrive in the order they were sent; WebSocket runs over TCP and nothing reorders them. Ordering defects come from the application: several server workers publishing, a replay after a reconnect, asynchronous handling in the client. A sequence number in every message gives the test something to check.

Reconnection is the application's job. RFC 6455 recommends a random delay before the first attempt and longer delays after each failure (back-off), so that thousands of clients do not hit a recovering server at once. After reconnecting, the client must authenticate again, resubscribe and catch up on what it missed.

• Ordering: send a burst of numbered messages, and events from two clients at once; every receiver sees the same order, without gaps or duplicates.
• Drop: cut the network mid-session (switch off Wi-Fi, or stop the proxy), let events happen, then restore it; every missed update appears exactly once.
• Idle: stay silent longer than the proxy timeout; the heartbeat keeps the connection open, or the client recovers.
• Session expired or access revoked while connected: the server stops sending private data, and the client asks the user to sign in instead of reconnecting forever.

WebSockets under load

Requests per second matter less here than concurrent open connections, the rate of new handshakes, messages delivered per second and the delay from an event to its arrival at every subscriber. Every open connection holds memory and a socket on the server and on each proxy, even when silent. Tools such as k6 and Gatling can script WebSocket clients; load only environments you are allowed to load.

• Ramp up to the expected peak of connections and hold it, giving each simulated client its own test user and token as real users would have; record failed handshakes and memory per connection.
• Fan-out: one event to thousands of subscribers; report delivery latency at the median and the 95th percentile (the time that 95% of deliveries stay within), measured on one machine's clock or with synchronised clocks.
• Reconnection storm: drop all connections at once, as a deployment does; back-off should spread the reconnects and the service should recover.
• Slow consumers and soak (a long run at normal load): a client that reads slowly must not make the server queue messages without limit, and memory must not grow over hours.

Try it: Load Test Data Generator

Worked example: a live order-tracking feed

The delivery app's contract: seq rises by one per update and a status never moves backwards; a heartbeat arrives every 20 seconds when nothing changes; after a reconnect the client sends its lastSeq and the server replays only updates with a higher seq; close codes are 1000 (user closed tracking), 1008 (invalid message) and 4401 (session expired, do not reconnect). In the sample, -> is client to server and <- is server to client.

Test conditions derived from it, each observable in the frame log:

• Subscribing to another customer's order B-2077 delivers none of its updates. The contract does not say whether the server answers with an error message or a close code: a gap in the test basis to settle with the team first.
• A subscribe without orderId, or text that is not JSON, closes with 1008; a 1011 means the server failed on bad input.
• With no change for a minute, a heartbeat arrives about every 20 seconds and the connection stays open.
• Cut the network after seq 1, advance the order twice, restore it: the client resubscribes with lastSeq 1 and receives 2 and 3 once, in order.
• When the session expires, the client receives 4401, stops reconnecting and asks the user to sign in.

-> {"type":"subscribe","orderId":"A-1042","lastSeq":0}
<- {"type":"subscribed","orderId":"A-1042"}
<- {"type":"status","orderId":"A-1042","seq":1,"status":"accepted"}
<- {"type":"heartbeat"}
<- {"type":"status","orderId":"A-1042","seq":2,"status":"picked_up"}
<- {"type":"status","orderId":"A-1042","seq":3,"status":"delivered"}

Try it: WebSocket Tester

Frequently asked questions

References

• RFC 6455: The WebSocket ProtocolIETF · 2011The WebSocket handshake over HTTP, framing, masking, ping/pong and close codes.
• The WebSocket API — MDNMDN Web Docs (Mozilla)The browser WebSocket API: opening a connection, sending messages and handling close events.
• OWASP Web Security Testing Guide (WSTG)OWASP FoundationThe reference methodology for testing web applications and APIs for security weaknesses, test by test.