DDoS attack types: the complete map

Volumetric attacks fill the pipe. They send more traffic than the connection can carry, and the traffic itself is often meaningless: what matters is its volume in bits per second. Because the link saturates before anything reaches your server, nothing running on the server can help.

Protocol attacks exhaust state rather than bandwidth. Every connection a server, firewall, or load balancer tracks occupies a table entry, and those tables are finite. An attack that opens connections and never completes them fills the table with entries that will never be used, leaving no room for real ones. Traffic volume can stay modest.

Application attacks exhaust the application. Requests are valid, arrive over a completed connection, and ask for something expensive: a search, a report, a page that hits the database several times. Volume in bits per second is unremarkable. What is remarkable is cost per request.

A fourth category is cross-cutting rather than technical: attacks accompanied by an extortion demand, covered on ransom DDoS, because the response there is a set of decisions, and configuration plays little part.

This single fact reorganises how the rest of the material is arranged, and it is set out in full on attack layers, the place to start before choosing any defence.

The symptoms overlap enough that guessing is common, and three checks separate them quickly.

Look at where the failure appears. If the site is unreachable and your own outbound connections from the same network are slow, the link is saturated and the problem is upstream. If the server is reachable but refuses new connections while showing low processor usage, state is exhausted. If the server is busy, processing requests, and simply cannot keep up, the attack is at the application.

Compare bandwidth against request count. A large amount of traffic carrying few requests points to the first family. A modest amount of traffic carrying many expensive requests points to the third.

Check whether the traffic is well formed. Volumetric and protocol attacks frequently involve packets that no legitimate client would send. Application attacks look like ordinary requests, because that is what they are, which is why they are the hardest to separate from real users.

Each family is handled by a different party, and knowing which one you face tells you who to call.

Volumetric traffic must be absorbed or filtered before it reaches your link, which makes it a matter for whoever provides that link or for a provider with capacity to spare. Nothing you configure on the server changes the outcome.

Protocol attacks are addressed partly by the network stack, through mechanisms designed to hold minimal state until a connection proves itself, and partly by filtering upstream. Some of this is tuning you control.

Application attacks are where request inspection earns its place. Requests arrive complete, they can be examined, and decisions can be made per request: rate limits by client and endpoint, challenges for suspect clients, and rules that recognise abusive patterns.

Classification is a decision aid, not a first step. During an incident the order that helps is narrower.

1. Confirm the failure from outside your own network. A site that is unreachable from one office and fine from elsewhere is a different problem from one that is unreachable everywhere, and the two get confused constantly.
2. Ask upstream whether the link is saturated. This single answer decides whether anything you do on the server can matter, and it comes from whoever provides your connectivity rather than from your own graphs, which stop being delivered once the link is full.
3. Capture what you have before changing anything. Connection counts, request rates, and a sample of the traffic. Mitigation changes the evidence by design, and reconstructing what happened afterwards is far harder than saving a few minutes of counters now.
4. Resist broad blocks made under pressure. Blocking a country or a large network stops the attack and stops customers with it, and blocks added during an incident are the ones nobody remembers to remove. Narrow measures that expire beat wide ones that persist.

Two limits, because taxonomies invite more confidence than they deserve.

Real incidents frequently combine families. A volumetric flood that saturates the link while an application flood exhausts the backend is one event from the outside and two problems to solve. Classifying an attack is useful for choosing defences, not for describing what happened.

And the categories say nothing about intent. The same technique appears in extortion, in competitive sabotage, and in traffic that is not an attack at all: a misconfigured client retrying without limit produces a pattern indistinguishable from a small flood, and the response differs entirely.

The defences that matter are layered, and no single product covers all three families.

Capacity and upstream filtering handle what saturates links. Network stack behaviour and stateless filtering handle what exhausts state. Request inspection and rate limiting handle what exhausts the application. A provider that terminates traffic on your behalf can supply the first and the third; the second sits partly with your own configuration.

Bridge WAF filters at the application layer: requests are inspected before they reach your origin, rate limiting is applied per domain, and abusive patterns are blocked without a rule for every variation. What that does not do is stop traffic that saturates a link before it arrives, and any product claiming otherwise is describing a different layer than the one it operates on. See what the platform offers at Bridge CDN.