SYN Flood.

In a SYN flood, the attacker opens — but never finishes — large numbers of TCP connections. Each spoofed or unanswered SYN forces the server to allocate a half-open connection in its backlog queue and reply with SYN/ACK, awaiting a final ACK that never arrives. When the backlog fills, the server refuses new legitimate connections. SYN floods can come from a single host or, more commonly, a botnet, with source IPs spoofed to make filtering harder.

flowchart TD
  A[Attacker] -->|"1. SYN (spoofed src IP)"| S[Target server]
  S -->|"2. SYN/ACK to spoofed IP"| V[Nonexistent / silent host]
  S -.->|3. allocates half-open entry| Q[(Backlog queue)]
  V -.->|final ACK never arrives| S
  A -->|repeat at high rate| S
  Q -->|queue full| R[New legitimate clients refused]

The attack was first publicized in 1996 via exploit code in Phrack magazine; in September 1996 a flood took down the mail servers of New York ISP Panix for days, prompting CERT advisory CA-1996-21. The definitive reference is RFC 4987 (2007), "TCP SYN Flooding Attacks and Common Mitigations," which surveys countermeasures and their trade-offs. The most effective host-side defence is SYN cookies, devised by Daniel J. Bernstein: instead of storing state, the server encodes connection parameters into the initial sequence number of the SYN/ACK and reconstructs them from the client's ACK, so no backlog entry is consumed until the handshake completes. Other mitigations include larger or dynamically sized SYN queues, connection-rate limiting at firewalls and load balancers, stateless filtering at the network edge, and upstream DDoS scrubbing.