What a WebSocket exhaustion attack does
WebSockets are long-lived: once the HTTP Upgrade succeeds, the connection stays open and the application keeps state for it — a slot in a connection registry, buffers, often a dedicated goroutine or thread and a heartbeat timer. An exhaustion attack opens many real WebSocket connections and simply keeps them alive, occupying that per-connection state until the server can accept no more. Unlike a raw connection flood it passes the upgrade and reaches your application code, so it exercises the WebSocket layer itself rather than just the kernel.
How ddos-sim.com simulates it safely
ddos-sim.com completes a real TLS handshake and WebSocket upgrade to a single verified domain pinned to a public address, then holds the socket open with periodic ping frames within the rate and concurrency limits for that domain. You choose the endpoint path and any request headers your handshake needs (such as Origin or Sec-WebSocket-Protocol); the Host and TLS server name stay pinned to the verified domain, and the upgrade is always a plain GET with no request body. Connections that the server does not upgrade to 101 Switching Protocols are reported and dropped, so the test only ever holds genuine WebSockets.
Every run is bound to one verified domain you have proven you own. Ownership is checked over HTTPS before anything is scheduled, and running traffic against systems you do not own or are not clearly authorized to test may be unlawful. See the Acceptable Use Policy.
What the test exercises
- Maximum concurrent WebSocket connections your application and proxies sustain
- Per-connection memory and goroutine/thread cost of an idle socket
- Connection-registry and heartbeat/ping-timeout handling under load
- Reverse-proxy and load-balancer WebSocket limits and idle timeouts
- How quickly capacity recovers once the connections are dropped
How to run a WebSocket exhaustion test
- Verify your domain. Prove ownership over HTTPS — it is self-service and takes minutes.
- Add the
websocket_floodcommand to a timeline, set the endpoint path (e.g./ws) and any headers your handshake needs, and choose the new-connections rate, duration, and maximum concurrent connections. - Set health thresholds. Choose the error-rate, latency, or status-code limits at which the test should abort itself.
- Run and watch. Bounded workers are provisioned minutes before start and torn down the moment the last task ends, while metrics stream live.
- Read the results. Review the recorded handshake outcomes and worker timeline to find where your WebSocket layer starts to bend.
Availability & limits
WebSocket exhaustion is priced per engagement — request a quote. Verify your domain before it runs.
Frequently asked questions
How is this different from an established connection flood?
The established connection flood holds idle TCP sockets to exhaust connection-tracking tables. WebSocket exhaustion goes further up the stack: it completes a real WebSocket upgrade and is accepted by your application's WebSocket handler, so it occupies per-connection application state — accept loops, connection registries, heartbeat goroutines — not just kernel connection tables.
Can I point it at a specific WebSocket endpoint?
Yes. You set the handshake path (for example /ws or /cable) and any request headers your endpoint needs, such as Origin or Sec-WebSocket-Protocol. The Host and TLS server name stay pinned to your verified domain, and the handshake is always a GET upgrade.
Rehearse a WebSocket exhaustion test against infrastructure you own — bounded, monitored, and stopped the instant you have your answer.
Build a test plan