ddos-sim.com All simulations Build a test plan

Layer 4 · Transport · tcp_connection_flood

TCP connection flood test

The tcp_connection_flood simulation completes full, unspoofed TCP handshakes and drops each one immediately, at a set rate — flooding the accept path of a domain you own with a churn of short-lived connections to see how fast it can set up and tear down connections before it falls behind.

Layer L4 Protocol TCP Command tcp_connection_flood Access Reviewed engagement

What a TCP connection flood does

A TCP connection flood opens a large number of complete TCP connections as fast as it can. Unlike a SYN flood, every handshake finishes — so the connections are real and fully established — and unlike a held-connection flood, each one is dropped straight away. The pressure is on rate: the accept queue, the accept loop, the per-connection setup and teardown cost, and the pile of sockets left in TIME_WAIT. A server that copes with steady traffic can still fall behind when the churn of new connections outruns how fast it can accept and clean them up.

How ddos-sim.com simulates it safely

ddos-sim.com opens bounded, fully completed TCP handshakes from the worker's real address to a single verified domain pinned to a public address, then closes each one immediately and opens the next, at a rate held inside the domain's limits. Nothing is spoofed and no payload is sent — it is pure connection churn — so every packet stays attributable.

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

  • Accept-queue depth and accept-loop throughput
  • Per-connection setup and teardown cost (CPU and memory)
  • TIME_WAIT accumulation and socket reuse tuning
  • Connection-rate limits on firewalls and load balancers
  • How quickly capacity recovers once the churn stops

How to run a TCP connection flood test

  1. Verify your domain. Prove ownership over HTTPS — it is self-service and takes minutes.
  2. Add the tcp_connection_flood command to a timeline in the portal and set the target port, connection rate, and duration.
  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 connection outcomes and worker timeline to find where your accept path starts to bend.

Configure a TCP connection flood test in the portal →

Availability & limits

The TCP connection flood is reviewed and approved before it runs (a manual review) and is priced per engagement — request a quote.

Frequently asked questions

How is this different from a SYN flood?

A SYN flood sends SYN packets and never completes the handshake, pressuring the SYN backlog. A TCP connection flood completes the full three-way handshake and drops the connection immediately, so it floods the accept path and connection setup/teardown throughput with fully established connections rather than half-open ones.

How is this different from an established connection flood?

An established connection flood completes handshakes and holds the connections open to fill the connection-tracking table. A TCP connection flood does not hold them — it opens and drops each connection immediately, stressing the rate of connection setup and teardown (and TIME_WAIT churn) rather than the table's held capacity.

Rehearse a TCP connection flood against infrastructure you own — bounded, monitored, and stopped the instant you have your answer.

Build a test plan
← All DDoS simulations