Types of DDoS Attacks: The Complete Taxonomy

Two events can both be filed as “DDoS” and have almost nothing in common. One saturates an uplink with terabits per second of spoofed UDP packets. The other holds a few hundred sockets open from one laptop and sends a few kilobytes a minute.

The control that stops the first cannot see the second at all. That is why the taxonomy is worth getting right. Sorting attacks by the way they cause failure, rather than by name, tells you which part of your stack decides each outcome and which whole class you have never put under load.

This post is the map. Each of the ten simulation types Obsidio runs has its own detailed post covering mechanics, mitigation and how to test it, and they are listed below. For how to structure a first run across the classes, start with our guide on how to test your DDoS protection.

How are DDoS attacks classified?

The industry standard split follows the OSI layers, and it is useful as far as it goes.

Volumetric attacks work at layer 3 and 4 and try to fill a pipe. Protocol or state-exhaustion attacks also sit at layer 3 and 4 but aim at a table rather than a link. Application-layer attacks work at layer 7, where every request costs the target real computation.

Slow attacks are technically layer 7 as well, and are often filed under the application-layer heading. In operational terms that is a mistake.

An application-layer flood is loud, and every rate-based control has something to trigger on. A slow attack sends less traffic than a single real user and defeats those controls by staying below every threshold they measure. Treating them as one class is how teams end up believing a flood test covered both.

So four classes: volumetric, protocol and state exhaustion, application-layer, and slow. Obsidio’s public product page groups its ten simulation types into four platform categories that map onto this closely, splitting off DNS and scripted browser work into their own group rather than treating volumetric floods as testable.

Note that both fours are counts of groupings. The catalogue itself is ten.

Volumetric attacks: can your pipe absorb the traffic?

A volumetric attack does not care what your application does. It sends more bits per second than your uplink, your edge router or your scrubbing contract can carry, and everything behind that bottleneck becomes unreachable whether or not it is healthy. Success is measured in gigabits or terabits per second.

The main techniques in this class:

• UDP flood. Raw UDP datagrams sent to random or fixed ports with no connection to establish and no state to keep on the sender’s side. Cheap for the attacker, which is why it dominates: Cloudflare’s 2025 Q3 DDoS threat report named UDP floods the top network-layer vector that quarter, up 231% quarter over quarter.
• ICMP flood. The classic ping flood. Fourth most common network-layer vector in the same Cloudflare quarter, and largely a solved problem at any competent edge.
• Reflection and amplification. The attacker sends small queries to open third-party servers with your address forged as the source, so the servers send you the much larger replies. DNS, NTP, SSDP, CharGEN and memcached have all been abused this way. The amplification ratios are what make it dangerous: Cloudflare’s 27 February 2018 write-up of the memcached attacks documented a 15 byte request producing a 750 kilobyte response, an amplification factor of 51,200 times.
• Carpet bombing. Rather than one target address, the traffic is spread thinly across an entire prefix so no single host crosses a detection threshold while the aggregate still saturates the link.

Scale in this class has moved fast. Cloudflare’s 2025 Q4 report describes a record 31.4 terabits per second attack that lasted 35 seconds, and NETSCOUT’s DDoS Threat Intelligence Report for the second half of 2025 counted more than 8 million DDoS attacks across 203 countries in that period alone.

What decides the outcome. Not your servers. Upstream capacity, your transit providers, and whether your scrubbing provider detects and diverts fast enough. Anything you configure on the host is downstream of the bottleneck and therefore irrelevant to this class.

Testability, honestly. Obsidio does not simulate spoofed-source or reflection attacks, and neither should anyone else. Forging source addresses and pointing third-party servers at your network abuses infrastructure that belongs to other people, which cannot be authorized by you and is not something we will build.

What is worth testing is the detection and diversion path: whether your provider notices, how long the divert takes, and whether anyone on your side is told. Parts of that are answerable with authorized application-layer load, and the rest belongs in a tabletop exercise with your provider.

Protocol and state-exhaustion attacks: how many connections can you hold?

This class does not try to fill your bandwidth. It fills a table.

Every established or half-established connection occupies a slot somewhere: a kernel socket, a conntrack entry, a file descriptor, a load balancer session, a TLS session cache. Those slots are finite and usually much smaller than people assume.

• SYN flood. Sends the first packet of the TCP handshake and never completes it, filling the backlog queue with half-open connections. Still the reference attack for this class after three decades. It has its own post: how a SYN flood works and how to test for it.
• ACK, RST and TCP flag floods. Packets that do not belong to any known session, forcing the target to look each one up in its state table and decide what to do. The lookup is the cost.
• TCP connection flood. Fully established connections, opened and held idle. No spoofing, because the handshake has to complete. This is a different failure from a SYN flood and defeats a different set of controls, which is why TCP Connection Flood is a separate simulation type.
• TLS handshake flood. Completes the full handshake, letting the server pay the asymmetric-crypto cost, then abandons the connection. Server-side CPU cost per handshake runs roughly fifteen times the client side, so the asymmetry favours the attacker heavily. See TLS Flood.
• Fragmentation attacks. Malformed or incomplete IP fragments that force the target to hold reassembly buffers for fragments that never arrive.

SYN floods sat third among network-layer vectors in Cloudflare’s 2025 Q3 report, behind UDP and DNS floods, with those four vectors together accounting for just over half of all network-layer attacks that quarter.

What decides the outcome. SYN cookies, backlog and conntrack sizing, per-source connection limits, and whether your load balancer terminates connections or passes them through. A CDN in front helps only if your origin address cannot be reached directly.

Testability. Partly. Obsidio’s TCP Connection Flood and TLS Flood test the fully-established end of this class directly and thoroughly, from real distributed devices, so per-source connection caps face the source diversity that a real attack would bring. Half-open SYN floods are a different matter: they require source-address spoofing, so they are outside what an authorized test can reproduce. The SYN flood post covers what you can verify by other means.

Application-layer attacks: how much work does one request cost you?

At layer 7 the economics change. Every request is valid, arrives over a completed TCP and TLS handshake, and asks the target to do something: run a query, render a page, check a session. A few thousand requests per second aimed at a search endpoint can be far more damaging than a hundred times that volume of packets aimed at a router.

These attacks are also harder to distinguish from customers, because structurally they are customers. Cloudflare’s 2025 Q3 report found nearly 70% of HTTP DDoS attacks came from botnets it already recognised, and around 20% came from fake or headless browsers or carried suspicious HTTP attributes. The remainder looked like nothing in particular.

• HTTP flood. High-concurrency well-formed requests against a real endpoint, targeting the request-processing path rather than the network. See HTTP Flood.
• Cache-busting floods. The same idea with randomized query strings and rotating browser-like headers, so every request misses the CDN cache and reaches origin. GoldenEye is this pattern.
• Real-browser floods. Traffic from actual browser engines that execute your JavaScript and fetch every sub-resource, which is what makes bot-detection challenges so much less decisive than their datasheets suggest. See Browser Flood.
• Expensive-request exploits. Requests crafted so the server does disproportionate work per request. Apache Killer is the canonical case, using overlapping Range headers against CVE-2011-3192 so a small request forces the server to allocate the response body many times over.
• Protocol-abuse floods. HTTP/2 Rapid Reset (CVE-2023-44487), disclosed jointly by Cloudflare, Google and AWS in October 2023, opened and immediately cancelled streams to make the server do the work while the client did almost none. Cloudflare reported mitigating 201 million requests per second from a botnet of roughly 20,000 machines.
• Targeted endpoint abuse. Login pages, password resets, search, cart and checkout, report generation, any API path that writes to a database. Low request rates, high cost per request.

What decides the outcome. Rate limiting granularity, bot management, WAF rules, and how far the damage travels once a request is accepted. Application-layer attacks reach the parts of your system a network attack never touches, which usually means the database connection pool.

Testability. Fully. Four of Obsidio’s ten simulation types live in this class, and Puppeteer Script covers the adjacent question of how a real user journey behaves while the system is under pressure.

Slow attacks: what happens when the traffic never arrives?

The fourth class inverts every assumption the other three rely on. A slow attack sends as little as possible, as slowly as possible, for as long as possible. Rate-based defenses have nothing to count, volumetric detection sees no spike, and the request rate graph stays flat while the service is already unreachable.

• Slow headers. Send the request line, then trickle header lines forever and never send the terminator. The server stays parked in “reading request headers” state. See Slowloris, whose original tool was released on 17 June 2009 and still works, because the behaviour it exploits is not a bug.
• Slow body. Advertise a truthful Content-Length on a POST, then send the body one byte at a time. Headers are complete, so a header-read timeout does not fire. See RUDY.
• Slow read. Send a perfectly valid request and then stop reading the response, so your receive buffer fills and the server’s send buffer backs up. Nothing about the request is wrong. The attack is on the read side.
• Connection churn. Valid keep-alive requests that sit idle and then reset abruptly, stressing teardown and connection accounting rather than capacity.

What decides the outcome. Timeouts with a minimum transfer rate rather than a bare deadline, per-source connection limits, and whether your reverse proxy fully buffers requests before forwarding them. This class is settled by configuration values in files, which is exactly why it drifts.

Testability. Fully, and this is the class most worth testing, because a configuration review tells you the setting exists and nothing about whether the pool holds under real concurrency.

Which types can you actually test?

Being clear about this is more useful than a longer capability list. Across the four classes:

• Directly testable with Obsidio’s ten simulation types. Application-layer floods including cache-busting and real-browser traffic, memory-amplification request exploits, both slow-attack directions, established-connection exhaustion, TLS handshake load, DNS resolver load over TCP, and scripted user journeys under concurrency.
• Testable in part. Detection and escalation for volumetric events. You cannot authorize a spoofed terabit flood, but you can find out whether your monitoring and your on-call rotation react to a genuine distributed traffic event at all. Whether anyone was paged is a real finding regardless of which class produced the traffic.
• Not testable, by design. Reflection and amplification off third-party servers, and any spoofed-source attack including SYN floods. These need infrastructure you do not own and address forging you cannot consent to on the internet’s behalf. Verify these through configuration review, your provider’s own drill programme, and network-level filtering checks.

Any vendor claiming to test the whole taxonomy is either being loose with words or doing something you should not want your name attached to.

Why does the class matter more than the name?

Attack names come and go. The classes do not, because they describe which finite resource runs out, and that set is small.

The practical consequence is coverage. A team that runs one volumetric test a year has measured a single bottleneck. Their timeouts, their connection limits and their per-endpoint rate limiting remain entirely unmeasured, and each of those is a different way to be offline.

Cloudflare’s 2025 Q3 report also noted that 71% of HTTP DDoS attacks and 89% of network-layer attacks end in under ten minutes, so the question is rarely whether you would survive a long siege. It is whether anything at all happens automatically in the first two minutes.

Class membership predicts your blind spots too. A volumetric attack is obvious in every graph you own, and settled entirely by someone else. An application-layer flood generates so much alerting that the signal disappears inside it.

Connection exhaustion shows up as a connection count that nobody has a dashboard for, and a slow attack produces no graph movement at all, often not even an access-log line. Those are four different detection failures, and fixing one does nothing for the others.

Strength is proven, not promised. Knowing the taxonomy tells you what could happen to you. Only a controlled, authorized simulation against your own infrastructure tells you what does.

Where should you start if a class has never been tested?

Pick the class where you have the least evidence, not the one that sounds most frightening. For most organisations that is the slow class, followed by established-connection exhaustion, because both are decided by settings nobody has looked at since installation.

Then run something real against it. Obsidio runs each of its ten simulation types as a controlled, authorized simulation against infrastructure you own. Domain ownership is verified by DNS TXT record before any traffic flows, runs ramp up gradually from conservative limits, and live metrics let you abort instantly.

Load comes from 100,000+ globally distributed real devices rather than a handful of datacenter instances, which is the difference between testing a per-source rate limit and testing whether it means anything against source diversity. Our post on running a DDoS stress test covers the sequencing, and the pillar guide covers scoping a first programme.

Banking and financial services ranked fourth among the most-attacked industries in Cloudflare’s 2025 Q3 report, and for regulated institutions the result of a run has to be filable rather than screenshotted. Obsidio produces cryptographically attested, tamper-evident reports mapped to FINMA, DORA and NIS2, generated inside Trusted Execution Environments, so a test leaves an artifact an auditor can check independently.

To scope authorized simulations across the classes that apply to your stack, see the Obsidio platform or get in touch with the team. Independent, neutral, verifiable: resilience you can prove.