When the Flood Is the Attack

A Distributed Denial-of-Service (DDoS) attack floods a service with so much traffic that it cannot serve legitimate users — or so much junk that it chokes the infrastructure in front of it. The "Distributed" is the point: tens of thousands of compromised devices (a botnet) or real users of open amplification services deliver the flood from every direction at once, which is why DDoS is cheap to launch and hard to filter.

The Three Families of Flood

Volumetric attacks aim to saturate the pipe itself: UDP floods, and amplification attacks where a tiny query to an open DNS/NTP/CLDAP server triggers a response hundreds of times larger, spoofed to the victim's IP. Protocol attacks target the connection machinery, not the bandwidth: a SYN flood opens TCP handshakes and never finishes them, exhausting the kernel's connection table, or Slowloris opens many connections and dribbles headers forever, pinning the thread pool. Application-layer attacks are the survivors' domain: HTTP floods aimed at expensive pages (search, login, PDF generation), often spread over years of crawled API endpoints to look less like bots.

Why the Target Cannot Win Alone

The victim cannot filter its own flood because the flood arrives at the victim at line rate; the filtering has to happen closer to the attacker, on infrastructure with more capacity than the victim will ever own. That is the fundamental reason DDoS defense is purchased, not built: scrubbing centers (Akamai, Cloudflare, Arbor, cloud provider protections) attract the traffic, drop the attack in their own capacity, and forward only clean requests. Their DNS sits in front of your public hostnames, so inbound traffic lands on their network before it ever reaches an origin. Mitigation is a procurement decision, not a coding one — the coding is the prevention half.

Defense Deep Layers

Scale: put your origin behind anycast routing and a CDN so the advertised "you" is a distributed set of edge servers rather than one resolved IP. Absorb: budget for spikes with autoscaling and transaction rates you have actually load-tested. Detect: alert on the classic signatures — TPS spikes, connection-table exhaustion, latency cliffs — because the first minute of an attack is when the decision to engage the scrubbing provider gets made. Filter: rate limit at the edge, challenge clients with a JS or JS-verified challenge for HTTP-level floods, and blocklist misbehaving sources automatically. And practice the runbook: mid-attack is the wrong time to discover your provider's activation process or your point-of-contact list.

Application Hardening That Shrinks the Attack

Make the legitimate path cheap so the attacker's path is proportionally more expensive. Cache aggressively (a static CDN cache serves millions of identical requests for nothing); gate expensive endpoints (login, search, export) with rate limits and CAPTCHAs at the edge; prefer asynchronous processing over blocking per-request work; and put connection-level limits (maxconn, timeouts, proxy buffers) in your server config so Slowloris-esque connections cannot pin workers (the firewalls lesson overlaps here). DDoS looks like a firewall problem but it runs on capacity and design: a service that serves the same cached reply to everyone at high speed resists a flood that would destroy a service that must compute a unique reply for every inbound request.