What Is a TCP SYN Flood Attack?
A SYN flood is a denial-of-service attack that abuses the way TCP sets up connections. By starting many connections and never finishing them, an attacker fills a server’s table of half-open connections until it can accept no more — a protocol-layer DDoS that needs far less bandwidth than a volumetric flood. Understanding it means understanding the TCP handshake.
How does the handshake get abused?#
TCP opens a connection with a three-way handshake:
Client → SYN → Server (server allocates state, replies)
Client ← SYN-ACK ← Server
Client → ACK → Server (connection established)
In a SYN flood, the attacker sends the first SYN — often with a
spoofed source — but never sends the final ACK. The server dutifully
allocates memory for each half-open connection and waits. Flood it with enough SYNs and the
connection table fills, so real clients are turned away. The attacker spends almost nothing; the
server spends memory on every fake.
How is it defended?#
| Defense | How it helps |
|---|---|
| SYN cookies | Server stores no state until the handshake completes |
| Increased backlog + shorter timeouts | Absorb and recycle half-open slots |
| Rate limiting / filtering | Drop abusive SYN sources |
| Upstream DDoS mitigation | Absorb large floods |
SYN cookies are the elegant fix: the server encodes the connection info into its reply’s sequence number instead of storing it, so a flood of SYNs that never complete costs it no memory at all.
The SYN flood is the classic protocol-layer DoS. More at the Network Security hub.
Frequently asked questions#
What is a SYN flood attack?
A SYN flood is a denial-of-service attack that abuses the TCP three-way handshake. The attacker sends many SYN (connection request) packets but never completes the handshake, leaving the server holding half-open connections in memory. Enough of these exhaust the connection table, so legitimate connections are refused.
What are SYN cookies?
SYN cookies are a defense that lets a server avoid storing state for half-open connections. Instead of allocating memory on receiving a SYN, the server encodes the needed information into the sequence number it returns, reconstructing the connection only if the handshake completes. This defeats SYN floods without dropping legitimate traffic.