ddos-sim.com All simulations Build a test plan

Layer 7 · Application · websocket_flood

WebSocket exhaustion test

The websocket_flood simulation completes real WebSocket handshakes over TLS to an endpoint you choose on a domain you own, then holds each socket open with periodic pings — so you can see how many live WebSocket connections your application sustains before its handler pool, memory, or heartbeat loop gives out.

Layer L7 Protocol WebSocket/TLS Command websocket_flood Access Quote on request

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.

Authorized targets only

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

When to run a WebSocket exhaustion test

Run a WebSocket exhaustion test when long-lived connections and per-connection state are where your real-time tier could run out of room.

  • You run WebSocket or real-time endpoints and want to know how many concurrent held connections the handler supports.
  • You want to validate per-connection memory, thread or goroutine, and file-descriptor limits under sustained open sockets.
  • A proxy or load balancer sits in front of the WebSocket tier and you need to confirm its connection limits behave.

How to run a WebSocket exhaustion test

  1. Verify your domain. Prove ownership over HTTPS — it is self-service and takes minutes.
  2. Add the websocket_flood command 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.
  3. Set health thresholds. Choose the error-rate, latency, or status-code limits at which the test should abort itself.
  4. Run and watch. Bounded workers are provisioned minutes before start and torn down the moment the last task ends, while metrics stream live.
  5. Read the results. Review the recorded handshake outcomes and worker timeline to find where your WebSocket layer starts to bend.

Configure a WebSocket exhaustion test in the portal →

Reading the results

Resilient: Connection and idle limits cap the number of held sockets, per-connection memory stays bounded, and new real-time clients still connect.

Under strain: The handler runs out of descriptors, memory, or worker slots, existing sessions degrade, and new WebSocket connections are refused.

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
← All DDoS simulations