When a server stops accepting new connections while its bandwidth graph looks entirely normal, a SYN flood is the usual explanation. The attack fills the queue of half-open connections rather than the pipe, so the failure appears in a place most monitoring is not watching. Finding that ceiling before an attacker does is a core part of a DDoS test. It abuses the TCP three-way handshake: the attacker sends a stream of SYN packets but never returns the final ACK, leaving every connection half-open. As a protocol attack it exhausts a finite state table rather than saturating a link, and the table it targets is the kernel's SYN backlog.
How a SYN flood works
A normal TCP connection opens in three steps: the client sends SYN, the server replies SYN-ACK and reserves state for the pending connection, and the client completes it with ACK. A SYN flood stops after step one. The attacker sends SYN after SYN, usually with a spoofed or randomized source address, and never sends the ACK that would finish the handshake.
Each of those unfinished handshakes sits in the SYN backlog, the queue of connections the kernel is holding half-open while it waits for the ACK. The kernel does not give that slot up immediately. It retransmits the SYN-ACK several times over tens of seconds before it finally times the entry out, so a single spoofed SYN holds a slot far longer than it took to send. Send them faster than they expire and the backlog fills; once it is full, the next legitimate SYN has nowhere to sit and is dropped.
The economics are what make the vector durable. A bare SYN is a tiny packet, roughly 40 to 60 bytes with no payload, so a SYN flood is counted in packets per second, not bits per second. An attacker can fill a backlog at a traffic rate that barely registers on a bandwidth graph, which is exactly why provisioning more link capacity does nothing to stop it.
It is worth separating the two queues involved, because they fail differently. The SYN queue holds half-open connections waiting for the ACK; the accept queue holds completed connections waiting for the application to pick them up. A SYN flood attacks the first. Note also that spoofing is optional: a botnet with thousands of real hosts can send genuine SYNs and simply never proceed, which defeats source-address filtering because every packet comes from a legitimate address. That is why the defense has to change the cost of a half-open connection rather than try to identify bad senders.
Why it matters under attack
A SYN flood tests kernel-level resilience, not raw throughput, and that is the point teams miss. The failure is silent on the metrics most dashboards watch: bandwidth looks idle while new connections quietly fail.
This is not a new attack. In September 1996 the New York ISP Panix was knocked offline for days by a SYN flood, one of the first high-profile denial-of-service incidents on the public internet. The response produced the defense still in use today: SYN cookies, designed by Daniel J. Bernstein that same year, which let a server validate a completing ACK without having reserved backlog state for it in the first place.
The structural defense is SYN cookies (net.ipv4.tcp_syncookies), which encode the connection state into the SYN-ACK sequence number instead of allocating a backlog entry. When the ACK returns, the server reconstructs the state from the acknowledged number, so an unanswered SYN costs nothing. A SYN proxy on an inline device does the same job one hop earlier, completing the handshake on the server's behalf and only forwarding connections that prove real.
What a DDoS test measures
A SYN flood test characterizes the knee point: the SYN rate at which the accept queue and backlog saturate and handshakes begin to fail. That number, not a bandwidth figure, is the resilience result for this vector.
It also checks that the mitigations are actually engaged and correctly sized. SYN cookies plus backlog tuning (tcp_max_syn_backlog, somaxconn) can look correct in a config file and still fail under load, and a defense that held last quarter can regress after a kernel or OS upgrade quietly resets a default. Where a SYN proxy or firewall sits inline, the test also has to confirm the device's own SYN backlog is not the first thing to fall, since a stateful appliance in front of the origin often exhausts before the server does.
The mechanics of L4 attacks alongside the other vectors are covered in Understanding DDoS Attack Vectors.