How it works
A TCP session starts with a three-way handshake. The client sends a SYN packet, the server replies with SYN-ACK, and the client completes the exchange with an ACK.
In a SYN flood, the attacker sends SYN packets at scale but does not complete the handshake. The target keeps temporary state for these incomplete sessions until timeouts expire.
What breaks first
- Listen queues and half-open connection tables fill up
- Firewalls and load balancers waste CPU on incomplete sessions
- Legitimate users fail to establish new TCP connections
- Other services on the same path can be affected as collateral damage
Why SYN floods are still relevant
The attack does not need extreme bandwidth to be effective. The target is usually state exhaustion, not link saturation.
This is why a relatively small attack in Gbps can still cause major disruption when packet rate is high and the mitigation path relies too heavily on stateful handling.
Common mitigation methods
SYN cookies reduce the amount of state the server needs to keep before the handshake is completed. Rate limiting can slow down obvious attack patterns, but it is not enough on its own at larger scale.
More effective mitigation usually means filtering as early as possible. Stateless validation and high-performance packet filtering paths are far more resilient than pushing every packet into connection tracking or firewall state tables.