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-simulation.com simulates it safely
ddos-simulation.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 onlyEvery 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
When to run a TCP connection flood test
Run a TCP connection flood test when you need to know how the accept path copes with a churn of short-lived, fully-established connections.
- You want to validate accept-queue depth, file-descriptor limits, and per-connection memory under rapid open/close churn.
- A load balancer or proxy terminates TCP and you need to see how it behaves when connection setup and teardown dominate.
- You're checking that connection-tracking tables and ephemeral-port reuse keep up during a burst.
How to run a TCP connection flood test
- Verify your domain. Prove ownership over HTTPS — it is self-service and takes minutes.
- Add the
tcp_connection_flood command to a timeline in the portal and set the target port, connection rate, and duration. - 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 connection outcomes and worker timeline to find where your accept path starts to bend.
Configure a TCP connection flood test in the portal →
Reading the results
Resilient: Connections are accepted and closed cleanly, file-descriptor and socket counts recover between bursts, and application latency is unaffected.
Under strain: Accept queues overflow, the service runs out of file descriptors or ephemeral ports, or TIME_WAIT sockets pile up faster than they drain.
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