TL;DR: The client sends SYN with an initial sequence number, the server replies SYN-ACK with its own and acknowledges the client's, and the client sends ACK; both sides now agree on sequence numbers and the connection is established. A SYN flood sends SYNs (often from spoofed source addresses) and never completes the handshake, so the server fills its queue of half-open connections and starts refusing legitimate clients. SYN cookies remove that state: when the queue is under pressure the server encodes the connection's details in its own initial sequence number, keeps nothing, and reconstructs the connection only when a valid ACK returns that number. Large volumetric floods still need upstream filtering, because they saturate the link before the host is involved.
How to approach it
Walk the handshake with what each side stores, then the attack as an asymmetry (cheap for the attacker, costly for the server), then SYN cookies as a way of making the server stateless until the client proves it can receive packets. Close by separating protocol exhaustion from bandwidth exhaustion.
A strong answer
Client
legitimate
Server
listening
Attacker
spoofed sources
- Normal handshake
Client to Server
1SYN, seq = x
1. SYN, seq = x
The client picks a random initial sequence number.
The handshake.
- Client to server: SYN, sequence number
x(random), plus options (window scaling, MSS, selective acknowledgement). - Server to client: SYN-ACK, sequence
y(random), acknowledgementx+1. The server allocates a small record for the half-open connection in its SYN queue and retransmits SYN-ACK if no reply arrives. - Client to server: ACK, acknowledgement
y+1. The server moves the connection to the accept queue for the application.
Random initial sequence numbers matter for security: an off-path attacker who cannot see the SYN-ACK cannot guess y, so cannot complete or inject into a connection while spoofing someone else's address.
The SYN flood. The attacker sends SYNs as fast as they can, usually with random spoofed source addresses. Each costs the server a SYN queue entry and retransmissions to addresses that never answer, while costing the attacker one packet and no state. When the queue is full, new SYNs, including legitimate ones, are dropped. Spoofing also hides the source and makes simple per-IP blocking useless.
SYN cookies. When the SYN queue is under pressure, the server stops storing half-open connections. Instead it crafts y to encode a timestamp, the negotiated MSS, and a keyed hash (a MAC) of the connection's addresses and ports. It sends SYN-ACK and forgets. When an ACK arrives, it checks that ack - 1 is a valid cookie for these addresses and recent enough, then creates the connection. A spoofed source never sees the SYN-ACK, so it cannot return a valid ACK. Trade-off: some TCP options are not preserved (older implementations lost window scaling), so cookies are usually enabled only under load (Linux tcp_syncookies=1 does this).
Other mitigations. Larger SYN backlogs and shorter SYN-ACK retry counts; load balancers and reverse proxies that terminate TCP; and upstream DDoS scrubbing for floods large enough to fill the network link, which no host setting fixes.
Where this sits among denial-of-service attacks.
| Class | Exhausts | Defence location |
|---|---|---|
| Volumetric (UDP floods, reflection and amplification) | Bandwidth | Upstream: provider scrubbing, anycast |
| Protocol (SYN flood, fragment attacks) | Connection state in hosts and middleboxes | SYN cookies, stateless edge, scrubbing |
| Application (HTTP floods, expensive queries, LLM token abuse) | Server CPU, memory, money | Rate limiting, caching, per-identity quotas |
The last row is where AI APIs suffer most: one request can cost thousands of tokens, so quotas by tokens and spend matter more than by connections.
What interviewers probe next
- "Why does spoofing matter for a SYN flood but not much for an HTTP flood?" An HTTP request needs a completed handshake, which a spoofed source cannot do, so HTTP floods come from real machines (botnets) and per-source limits help more.
- "What does a SYN cookie encode?" A coarse timestamp, an MSS index and a MAC over the connection tuple with a server secret.
- "How do reflection attacks differ?" The attacker spoofs the victim's address in requests to third-party services (DNS, NTP, memcached) whose responses are larger, so the victim is flooded by many servers.
What if?
What if · interview follow-ups
Hold your answer as the constraints change
Your public login service slows to a crawl, and graphs show a flood of TCP SYN packets from thousands of source addresses.
Start here
How does the TCP handshake work?
What state does the server hold after SYN-ACK?
The client sends SYN with an initial sequence number, the server replies SYN-ACK with its own and acknowledges the client's, and the client sends ACK. Both sides then agree on sequence numbers.
Carry it forwardThree-way handshake agrees sequence numbers.
Weak answerForgetting the server stores state after SYN.
Constraint changes
How does a SYN flood work?
What runs out on the server?
It sends SYNs, often from spoofed source addresses, and never completes the handshake. The server fills its queue of half-open connections and starts refusing legitimate ones.
Carry it forwardSYN floods exhaust half-open connection state.
Weak answerTreating it as a bandwidth problem only.
Constraint changes
How do SYN cookies help?
Can the server avoid storing state for SYNs?
The server encodes connection state in its initial sequence number and keeps nothing until a valid ACK returns. Spoofed SYNs then cost the server almost nothing.
Carry it forwardSYN cookies remove per-SYN state.
Weak answerOnly increasing the backlog size.
Constraint changes
What if the flood exceeds your bandwidth?
Where must large floods be absorbed?
Host defences cannot help once the link is saturated. Upstream DDoS protection with scrubbing or an anycast CDN absorbs it before it reaches you.
Carry it forwardVolumetric floods need upstream absorption.
Weak answerRelying on the origin firewall.
Constraint changes
How would you prepare for next time?
Who do you call when it happens?
Put public services behind a DDoS-protected edge, enable SYN cookies, set connection limits on load balancers, monitor half-open connection counts and have a runbook with provider contacts.
Carry it forwardEdge protection, host tuning and runbooks.
Weak answerWaiting for the next attack to plan.
Now defend it
How would you respond and harden?
Enable SYN cookies and connection limits, engage upstream DDoS protection or route through an anycast CDN to absorb volume, monitor half-open connections, and keep a runbook with provider contacts and escalation steps.
How it's scored
Weak: Recites SYN, SYN-ACK, ACK and "too many SYNs crash the server".
Hire: Explains half-open state and queue exhaustion, the role of spoofing, and SYN cookies as stateless verification.
Strong Hire: Explains random sequence numbers against off-path injection, what a cookie encodes and why spoofed sources cannot answer, the option trade-off and load-triggered use, and places the attack among volumetric, protocol and application floods with the right defence location for each.
Common mistakes
- Thinking SYN cookies stop bandwidth floods.
- Forgetting the role of spoofed source addresses.
- Treating sequence numbers as unimportant for security.
- Blocking per source IP during a spoofed SYN flood.