A SYN-ACK flood works by sending the second packet of a TCP handshake that nobody started, rather than the first packet of a new one. It is one of the Layer 4 vectors a thorough DDoS test is built to exercise, and it belongs to the protocol attack class: the damage is done in packets per second against devices that keep connection state, not in bandwidth. What separates it from its siblings is where the cost lands and how the traffic can be made to arrive from innocent servers.
How a SYN-ACK flood works
A SYN-ACK is only valid as a reply. A host that receives one should already have sent a SYN to that address and port, and a stateful device in front of it should already hold a record of that outbound SYN. An unsolicited SYN-ACK matches nothing.
That is the difference from a SYN flood. A SYN flood creates state: every packet claims a half-open slot until the backlog is full. A SYN-ACK flood creates none. Each packet costs a lookup in the connection table, a miss, and a drop, and the attack wins by making the device do that lookup millions of times a second. On a firewall or load balancer the limit it hits is lookup rate and CPU, not table size, which is why a box with a huge conntrack table can still fall over.
The origin host adds a cost of its own. Under the TCP specification a host that receives a SYN-ACK for a connection it does not have answers with a RST. If the flood reaches the server, every inbound packet produces an outbound one, so the host's own uplink carries a second flood in the other direction, aimed at whatever source addresses were forged.
Why it matters under attack
The reflected form is what makes this vector hard to shut down. An attacker sends spoofed SYNs, carrying the victim's address, to any public TCP service: web servers, mail servers, anything with an open port. Each one answers the victim with a SYN-ACK. The reflector pool is not a misconfigured protocol that can be patched; it is every listening TCP port on the internet.
The multiplier comes from retransmission rather than packet size. A SYN-ACK is no bigger than the SYN that triggered it, but a server that gets no reply resends it, and Linux defaults to five retries, so one spoofed SYN can produce six SYN-ACKs. The victim could stop that by answering each one with a RST, and the firewall that silently drops them is exactly what keeps the retransmissions coming. Research published in 2014 as "Hell of a Handshake" found TCP reflectors with far higher multipliers from misbehaving stacks. Vendors reported waves of SYN-ACK reflection campaigns from 2019 onward, attractive precisely because every packet comes from a legitimate, well-reputed server.
There is a cheap filter for a pure server, and it is worth knowing. A SYN-ACK legitimately arrives at the ephemeral port the client chose, never at a listening service port. A stateless rule that drops inbound SYN-ACKs destined for port 443 or 80 removes most of the flood before any state lookup happens. It fails for hosts that also make outbound connections, which is most of them, so the real question is where stateless filtering stops and the stateful firewall begins.
What a DDoS test measures
A test characterizes the SYN-ACK rate each inline device can reject before its CPU saturates and legitimate handshakes start to time out, measured in packets per second and reported per device, because the load balancer and the firewall rarely fail at the same number.
It then checks the controls specific to this vector: whether a stateless SYN-ACK filter exists upstream of the stateful tier, whether it covers the reflected form arriving from thousands of real servers, and whether the origin's reflexive RSTs are adding outbound load during the attack. How a flood that loads the inline firewall can be exercised without taking down the production path is described in DDoS Testing Without Disrupting Production.