SYN Flood vs SYN Cookies | mysimulator.uk

Defense Mode

Classic backlog (vulnerable)

Traffic

Attack SYN rate 150 /s

Legitimate connection rate 6 /s

Backlog capacity 64 slots

Half-open timeout 2.0 s

Live Readouts

Backlog occupancy

0 / 64

Legit success rate

100%

Legit conns dropped

How it works

A normal TCP connection is a 3-way handshake: SYN → SYN-ACK → ACK. The moment a server sees a SYN, classic TCP stacks allocate a slot in the backlog queue and hold it in SYN_RECV state until the ACK arrives or a timeout expires.

SYN flood:
  attacker sends SYNs from spoofed/unreachable sources
  → server allocates a backlog slot per SYN, waits ~T seconds
  → slots fill faster than they expire when:
      attack_rate × T  >  backlog_capacity
  → queue full ⇒ legitimate SYNs are silently dropped (DoS)

SYN cookies (Bernstein, RFC 4987) remove the need to store any state at SYN time. The server encodes everything it needs into the initial sequence number it sends back:

cookie = low24( H(secret, srcIP, srcPort, dstIP, dstPort, t_coarse) )
seq(SYN-ACK) = cookie          // no backlog slot allocated yet
on ACK: ack_number - 1 == recomputed cookie?
  yes → connection accepted directly, resources allocated now
  no  → silently dropped

Because the cookie is a cryptographic function of the request, a spoofed attacker who never sees the SYN-ACK can never produce a valid ACK — so flood traffic is absorbed with zero memory cost, while a real client's normal handshake completes exactly as before.

Attack SYN rate / Legitimate rate — traffic mix hitting the server each second.
Backlog capacity — how many half-open slots the classic queue can hold.
Half-open timeout — how long an unanswered SYN occupies a slot before expiring.
SYN Cookies — toggles the defense; watch the backlog stay empty and drops stop.

Legitimate SYN Attack SYN (spoofed) Half-open backlog slot Completed connection

⚠ Couldn't load the 3D engineThree.js failed to load from the CDN. Check your connection and reload.