What an established connection flood does
Where a SYN flood pressures the accept path with half-open connections (which SYN cookies mitigate), an established-connection flood completes the handshake and simply keeps the connection open and idle. Enough long-lived connections exhaust the server’s and firewall’s connection-tracking (conntrack) tables and per-connection memory, so new legitimate connections are refused — without any spoofing.
How ddos-simulation.com simulates it safely
ddos-simulation.com completes normal, unspoofed TCP handshakes to a single verified domain pinned to a public address, enables TCP keep-alive, and holds each connection idle within the rate and concurrency limits for that domain. No application data is ever sent.
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.
Honest scopeThe real source address is used and the handshakes are genuine, so this pressures the connection table rather than spoofing traffic. Use the concurrency limit to bound how many connections are held open at once.
What the test exercises
- Connection-tracking (conntrack) and established-connection table limits
- Per-connection memory on the server and any stateful middlebox
- Idle-connection reaping policy and timeouts
- Load-balancer and firewall session-table limits
- Recovery once the held connections are dropped
When to run an established connection flood test
Run an established connection flood test when idle, fully-open connections — not connection churn — are the pressure you need to model.
- You want to see how many concurrent idle connections the stack holds before file descriptors or memory run out.
- A stateful firewall, NAT, or load balancer keeps per-connection state and you need to confirm it doesn't exhaust.
- You're validating idle-timeout and per-IP connection caps.
How to run an established connection flood test
- Verify your domain. Prove ownership over HTTPS — it is self-service and takes minutes.
- Add the
established_flood command to a timeline in the portal and set the rate, duration, and any concurrency limit. - 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 latency, status codes, and worker timeline to find where your service starts to bend.
Configure an established connection flood test in the portal →
Reading the results
Resilient: Idle-connection limits and timeouts reclaim capacity, file-descriptor and memory use stay bounded, and new connections still succeed.
Under strain: Connection-tracking or descriptor limits are reached, memory climbs with each held connection, and the service stops accepting new clients.
Availability & limits
The established connection flood is a network-layer method: it is priced per engagement, and your domain must be verified and reviewed before it can run.
Frequently asked questions
How is this different from a SYN flood?
A SYN flood leaves connections half-open to pressure the backlog, which SYN cookies mitigate. This completes the handshake and holds connections established, pressuring the connection and conntrack tables instead.
Are the connections spoofed?
No. Every connection uses the real source address and completes a normal handshake through the operating system network stack.
Rehearse an established connection flood test against infrastructure you own — bounded, monitored, and stopped the instant you have your answer.
Build a test plan