An HTTP flood attacks with requests that are individually valid. Every one is a well-formed request for a real page, which is what makes it hard: there is no malformed field to filter on, only a question of how many the application can serve. Reproducing that pressure honestly is one of the harder parts of a DDoS test. It is the archetypal application-layer attack: every request completes a real TCP and TLS handshake and reads as legitimate, so the flood exhausts CPU, worker threads, and the backend database instead of the network link.
How an HTTP flood works
An HTTP flood is counted in requests per second, not bits or packets per second. That unit is the whole story: the attacker is not trying to fill a pipe, they are trying to make the server do expensive work. A single 200-byte GET can trigger a database join, a template render, and several backend calls, so the cost asymmetry runs the wrong way for the defender. Small request in, large amount of server work out.
The two common shapes are a GET flood and a POST flood. A GET flood hammers read-heavy endpoints such as search, category listings, or anything with a query string. A POST flood is usually more expensive per request because the server has to accept and parse a body, and it often lands on login, checkout, or comment endpoints that write to a database.
Attackers steer the flood at the requests that cost the most. A static homepage served from cache is cheap, so a competent HTTP flood avoids it. Instead it targets uncacheable paths, and where a CDN sits in front, it appends randomized query strings so every request looks unique and misses the cache, forcing each one through to the origin. That cache-bypass move is why an edge that shrugs off a volumetric flood can still buckle at the application tier.
Because each connection is a real, completed handshake, the source addresses are genuine. An HTTP flood therefore cannot be filtered by dropping spoofed traffic the way a reflection flood can, and it needs a real botnet of hosts that can each carry out a full request. That is the trade the attacker accepts: more effort to build, far harder to tell apart from real users once it is running.
Why it matters under attack
The hard part is not stopping the requests, it is deciding which requests to stop. An HTTP flood looks like a flash crowd. If a sale, a news mention, or a product launch can send legitimate traffic through the roof, then a filter tuned to "too many requests" will also throw away paying customers. The detection surface is request semantics, not volume, which is why L7 defense leans on behavioral scoring, rate limiting, and bot management rather than a bandwidth threshold.
The scale is real. In June 2022 Cloudflare reported mitigating a 26 million request-per-second HTTP flood, and the notable detail was the source: roughly 5,000 hijacked cloud servers and virtual machines, each capable of thousands of requests per second, rather than a large fleet of weak IoT devices. A small, powerful botnet on fat uplinks is now enough to generate an L7 flood that a single origin cannot answer.
What a DDoS test measures
An HTTP flood test characterizes the request rate at which the application tier degrades, and it does that per endpoint, because the knee point for a cached homepage and for a search query are nowhere near each other. The result is a rate, not a bandwidth figure.
It then checks the parts that are supposed to catch the flood without catching customers. Do rate limiting and bot management separate the flood from a genuine spike, and what is the false-positive cost when they engage? Does a cache-busting pattern slip past the CDN and reach the origin? And where autoscaling absorbs the load, does the bill or a concurrency cap become the real failure before the CPU does. Seeing HTTP floods in the context of the other vectors is the point of Understanding DDoS Attack Vectors.