Understanding L3, L4 and L7 DDoS Attacks
A plain-English guide to the three layers DDoS attacks hit — volumetric floods, protocol abuse and application-layer attacks — and what actually stops each one.
On this page
“DDoS protection” gets thrown around like a single feature, but attacks come in very different shapes, and defending against one kind does nothing against another. Understanding the three broad categories — named after the network layers they target — makes it obvious why real protection has to work at several levels at once.
The quick map
| Type | What it attacks | Example | What stops it |
|---|---|---|---|
| L3/L4 volumetric | Raw bandwidth / connection tables | UDP flood, SYN flood, ICMP flood | Massive upstream scrubbing capacity |
| Protocol | Weaknesses in how a protocol works | SYN/ACK abuse, fragmented packets | Stateful filtering at the edge |
| L7 application | The app itself (CPU, DB, logic) | HTTP request floods, login spam | Rate-limiting and behavioural analysis |
Layer 3 / 4: volumetric floods
These are the “firehose” attacks. The goal is simply to send more traffic than your connection can carry — hundreds of gigabits or even terabits per second of junk UDP, SYN or ICMP packets — until legitimate traffic can’t get through. Your server never even gets a chance to respond; the pipe is full before packets arrive.
You cannot filter this on the server itself, because the flood saturates the link upstream of the machine. The only defence is scrubbing capacity far larger than any attacker can muster, applied out at the network edge. Kerit Cloud sits behind 17+ Tbps of mitigation — OVH’s TCP Shield plus Cloudflare Magic Transit — so volumetric floods are absorbed and cleaned before they ever reach your server. More detail on the DDoS protection page.
Protocol attacks
These are subtler. Instead of raw volume, they abuse how a protocol is supposed to work — for example, opening thousands of half-finished TCP connections (a SYN flood) to exhaust the connection table, or sending malformed fragmented packets that tie up processing. They can knock a server over with far less bandwidth than a volumetric attack.
The defence is stateful filtering at the edge: validating handshakes and dropping connections that never complete, so the abuse never consumes resources on your machine. This is also why game servers need protocol-aware protection — see keeping a game server online through an attack.
Layer 7: application attacks
The trickiest category. L7 attacks look like real traffic — genuine HTTP requests, real logins, real API calls — just far too many of them, aimed at the most expensive operations. A few thousand requests per second hitting a search endpoint or a login form can exhaust your CPU and database without ever coming close to saturating your bandwidth.
Because each request looks legitimate, you can’t just block by volume. Defence relies on rate-limiting and behavioural analysis — spotting patterns that humans don’t produce and challenging or dropping them. Kerit Cloud’s edge rate-limiting handles millions of requests per second, and SMART-NET behavioural filtering auto-tunes to live traffic to catch adaptive attacks.
Why layered protection is the whole point
An attacker will use whichever layer you’re weakest at. Scrubbing terabits of UDP does nothing against an L7 login flood; clever rate-limiting is useless if the pipe is already full. Real protection covers all three:
- Volumetric → huge upstream scrubbing capacity.
- Protocol → stateful handshake validation at the edge.
- Application → rate-limiting plus behavioural filtering.
That’s the model every Kerit Cloud plan runs by default, with no setup on your side. Learn how our protection works, or read on for how anycast and scrubbing keep you online.