All DDoS Definitions
DDoS Testing Definition

Application-Layer Attack

Unlike a volumetric attack, which tries to fill the pipe, an application-layer attack does nothing to the network link. It works one tier higher, at Layer 7, sending requests that are individually valid but collectively ruinous, and reproducing that pressure honestly is one of the harder jobs a DDoS test takes on. Because each request completes a real handshake and reads as legitimate traffic, an L7 attack slips past the bandwidth and packet filters that stop the other classes and goes to work on CPU, worker threads, and the backend database instead.

Application-layer (L7) attack: valid requests, exhausted app tier Attacker low bandwidth HTTP flood each request is valid Slowloris / RUDY (slow) each request is valid Login / search / checkout each request is valid Volumetric filter (bandwidth / pps) PASS: volume looks normal Application tier CPU Worker threads Backend database exhausted at low bandwidth Test measures the request rate at which the app tier degrades, and whether L7 controls catch the flood without blocking real users. BlackNeuron
Application-layer attack: valid-looking L7 requests pass the volumetric filter and exhaust CPU, worker threads, and the backend database

How an application-layer attack works

The unifying trait of the class is a cost asymmetry. The request is cheap to send and expensive to serve: a lookup that fans out into a database query, an uncached page that has to be rendered, an endpoint that writes to disk. The attacker pays for one packet, the origin pays for all the work behind it, which is why the class is counted in requests per second rather than bits per second.

Within that shape there are two families. The first overwhelms by rate: a very high volume of valid requests aimed at the endpoints that cost the most, of which an HTTP flood is the archetype, steered at search, login, or checkout rather than a cached homepage. The second overwhelms by duration: a modest number of connections held open by trickling data a byte at a time, pinning a worker thread with no volume at all. Slowloris and RUDY are the canonical low and slow attacks. One family arrives fast and the other arrives slow, but both drain the same finite pool of workers, which is the resource the whole class is really aimed at.

Because the handshakes complete, the source addresses are genuine. An application-layer attack cannot be dropped for looking spoofed the way a reflection flood can, and it cannot be cheaply turned away the way a SYN flood can with cookies. It needs a real botnet of hosts that can each carry out a full request, which is a cost to the attacker and, once running, a headache for the defender: the traffic is indistinguishable from a crowd of real people by any test that only counts packets.

Application-layer attack: the worker pool fills, not the pipe Expensive L7 requests Worker / thread pool Each request pins a worker while it renders a page and queries the database pool limit 503: real user shut out Low bandwidth, valid requests: the volumetric filter sees nothing to drop BlackNeuron
Animated application-layer attack: expensive but valid L7 requests each pin a worker thread until the worker pool is full and a legitimate user is answered with a 503, while the volumetric filter sees nothing worth dropping

Why it matters under attack

Nothing in the network is full. The link carries a trickle, the packet counters read ordinary, and the first sign of trouble is that requests start timing out at the application. That is what sets this class apart from a protocol attack, which exhausts a state table, or a volumetric flood, which saturates a link: the bottleneck is the code, not the plumbing, so the graphs a network team watches can stay green while the service is already down.

The other difficulty is that a valid-request flood is shaped exactly like a surge of real customers. A launch, a discount, or a viral link can send genuine traffic vertical, so a rule that keys on request count alone cannot tell the two apart and will shed paying users along with the attack. What separates an L7 attack from a spike is how a client behaves, not how much it sends, so the defenses that hold up are the ones that score behaviour rather than count arrivals. Get that judgement wrong in either direction and there is a bill: miss the attack and the site falls over, clamp down too hard and you have finished the attacker's work for them.

What a DDoS test measures

A test finds the request rate at which each endpoint gives way, and it does it endpoint by endpoint, because a static page and a database-backed query fail at points that are nowhere near each other. What it hands back is a per-endpoint rate, and the weakest endpoint sets the ceiling for the tier as a whole.

Then it puts the defensive controls under the same load and watches where they break. Does behavioural scoring keep the false-positive count low enough that real buyers get through while the attack is shed? Where the tier autoscales, the question shifts from availability to economics: does a concurrency ceiling or a runaway bill arrive before the servers themselves give out? And do the idle-connection timeouts that defeat a slow attack actually fire before every worker is pinned? What that means for defending endpoints that cannot simply be rate-limited without turning away real buyers is worked through in Layer 7 DDoS Testing.