Methods / L4 / SYN
L4 · NetworkVolumetricTCPSpoofableState Exhaustion
SYN stress test
Floods a target with TCP SYN packets that open half-connections it never completes, validating how your stack and protection survive connection-table exhaustion.
How it works
Each SYN packet asks the server to allocate a half-open connection and wait for a handshake that never arrives, so a high enough SYN rate fills the backlog and starves legitimate clients of slots. The classic Layer 4 volumetric primitive, it stresses the connection state table rather than bandwidth alone. It validates whether SYN cookies, SYN proxying at the edge, and backlog tuning keep the service answering under a flood of half-open requests.
Parameters
pps600k ppsSYN packet rate driven at the target port
sourceswide source spreadDistributes SYNs across many source addresses by region
dst portany listening portTargets a single open TCP service
duration10-600 sLength of the test window
Run it from the CLI
retro-cli
$ retro run syn --target 203.0.113.45 --port 443 --duration 120
SYN FAQ
What does a SYN flood actually exhaust?+
It targets the connection state table, not just bandwidth. Each SYN reserves a half-open slot until a handshake that never comes times out, so a sustained rate fills the backlog and blocks new legitimate connections.
Do SYN cookies fully stop a SYN flood?+
SYN cookies remove the state-allocation problem by deferring backlog use until the handshake completes, but a large enough flood can still saturate the link or CPU. This method shows you where that ceiling sits on your own stack.
How is this different from SYN-OPT?+
Plain SYN uses minimal packets that naive filters can flag on shape alone. SYN-OPT adds realistic TCP options like MSS and SACK so the packets look like genuine clients, testing option-aware mitigation instead.