a SYN flood
/ SIN flood /
Recall that a TCP connection starts with a three-way handshake: the client sends SYN ('let's talk'), the server replies SYN-ACK ('okay, I hear you'), and the client finishes with ACK ('great, go'). Between the server's SYN-ACK and the client's final ACK, the server holds a half-open connection, having reserved memory for it while waiting. A SYN flood abuses exactly this waiting: it sends a torrent of SYNs but never completes the handshakes, leaving the server's table jammed with half-open connections that never resolve.
Here's the mechanism step by step. The attacker sends many SYN packets, often with spoofed (fake) source IP addresses. For each, the server dutifully replies SYN-ACK and allocates a slot in its connection table, waiting for the final ACK. But that ACK never comes — the source address was fake or the attacker simply ignores the reply. Each half-open connection ties up server resources until it eventually times out. Send SYNs faster than they time out, and the server's table of half-open connections fills completely; with no slots left, it must turn away new connection attempts — including those from real users.
Why it matters: the SYN flood is a classic, illustrative denial-of-service attack because it exploits the protocol's own design — the server must reserve state after a single SYN, before it knows the client is genuine. The standard defense is the SYN cookie: instead of allocating state on the first SYN, the server encodes the needed connection information into the sequence number it sends in the SYN-ACK, so it can stay stateless until a valid ACK actually returns and proves the client is real. The deeper lesson is general: any protocol that commits resources before authenticating the other side can be exhausted this way.
An attacker fires 100,000 SYNs per second with spoofed source IPs at a server. The server sends SYN-ACKs and reserves a slot for each, waiting for ACKs that never arrive. Its half-open connection table fills, and legitimate users' SYNs are refused. SYN cookies fix it by reserving no state until a real ACK comes back.
Half-open connections pile up until the table is full.
The SYN flood exploits the server committing memory on the first SYN, before knowing the client is real. SYN cookies defeat it by staying stateless until a valid ACK proves the client genuine.