DDoS Attack Types Explained: From Volumetric Floods to CC and L7 Attacks

When businesses talk about DDoS protection, the first things that come to mind are usually bandwidth and scrubbing capacity: how many Gbps can it absorb? Can it handle Tbps-scale floods?

Those questions matter, but they no longer describe the full DDoS risk. Beyond Volumetric Attacks that saturate bandwidth, an attack can also drain TCP connections, Web Servers, APIs, or Database resources.

At Layer 7 (L7) in particular, attack traffic is not always especially large. A flood of normal-looking HTTP Requests can steadily drain application resources through high-cost Endpoints such as Login, Search, and APIs.

So assessing a DDoS attack is not just about asking "how big is the attack traffic?" You also need to answer: which resource is the attack consuming?

What Is a DDoS Attack?

DDoS (Distributed Denial of Service) is an attack that uses traffic or requests from many distributed sources to exhaust a target's resources, so that legitimate users can no longer access the service.

But different DDoS attacks consume different resources. From the network layer to the application layer, common DDoS attacks fall into three broad categories:

1. Volumetric Attack: traffic-based attacks
2. Protocol / L3-L4 Attack: protocol-based attacks
3. Application / L7 Attack: application-layer attacks

On top of that, at the application layer, Automated Bot Traffic can also overlap with HTTP Floods, CC Attacks, and API Abuse.

* Automated Bot Traffic is not necessarily DDoS in itself, but at the application layer it can overlap with HTTP Floods, CC Attacks, and API Abuse.

Type 1: Volumetric Attacks Aim to Saturate Bandwidth

The Volumetric Attack is the most intuitive type of DDoS attack. Its goal is simple: flood the target's network bandwidth with so much traffic that legitimate user traffic cannot get through.

Common methods include:

• UDP Flood
• DNS Amplification
• Reflection / Amplification Attack

These attacks are usually measured in BPS (Bits Per Second). When BPS spikes abnormally in a short period, approaching or even exceeding the bandwidth the network can carry, the result can be:

Packet Loss → Rising Latency → Connection Timeout → Service becomes unreachable

The defining trait of a Volumetric Attack, then, is using sheer traffic volume to consume network capacity. The flip side is that bandwidth not being maxed out does not mean you are free of DDoS, because the next type of attack targets an entirely different resource.

Type 2: Protocol Attacks Can Take a Service Down Without Saturating Bandwidth

Protocol Attacks do not target bandwidth itself. They target network protocols and connection resources. One of the classic examples is the SYN Flood.

A normal TCP connection requires a three-way handshake:

1. The Client sends a SYN
2. The Server replies with a SYN-ACK
3. The Client returns an ACK, and the Connection is Established

In a SYN Flood, however, the attacker sends huge numbers of SYN Requests without ever completing the connection.

The Server has to temporarily hold on to the Connection State for each of these unfinished connections. As half-open connections keep piling up, they can exhaust the connection resources of the Server, Firewall, Load Balancer, or other intermediate devices, leaving legitimate users unable to establish new Connections.

That is why BPS alone is not enough for this kind of attack. Metrics such as PPS (Packets Per Second), Concurrent Connections, and SYN Rate are often far more telling.

Put simply: Volumetric Attacks are about "how much traffic is there," while Protocol Attacks require you to watch "how many packets and connections the system is handling."

Type 3: Application Layer / L7 Attacks Are Not Always Large, but They Can Be Costly

At Layer 7, DDoS attacks become far more complex, because what the attacker sends is not necessarily an abnormal packet. It may be a Request that fully complies with the HTTP Protocol. For example:

GET /product/123
POST /login
GET /api/search

From the Network Layer's perspective, all of these may look like normal TCP / HTTPS Traffic.

The real question is: how much does it cost the server to process each Request?

For instance, a single Login Request may involve:

Account validation → Database Query → Token Verification → Session creation → Response

A single Search API call may involve a Database Query, a Search Index, or other Backend Computation.

If large numbers of Requests keep hitting these high-cost Endpoints, CPU, Database Connections, Application Threads, or API Resources can be heavily tied up, even when total Bandwidth shows no obvious increase.

This is what makes Application Layer DDoS so troublesome: the attack traffic can look almost identical to real users.

What Is a CC Attack, and Why Is It an L7 Attack?

CC Attack (Challenge Collapsar) is a term commonly used for application-layer attacks that send large volumes of HTTP Requests to continuously drain Web Server or Application Resources.

The biggest difference from a traditional high-volume DDoS attack is this: a Volumetric Attack mainly consumes network capacity, while a CC Attack is closer to consuming the service's processing capacity.

For example, an attacker may repeatedly request:

• /login
• /search
• /api/query
• /product
• Dynamic Page
• Uncached Content

Say a single /login Request is only a few KB, so its impact on Bandwidth is minimal. But if every Request requires a Database Query, Authentication, or other Application Logic, then as requests pile up, it is the backend resources that actually get exhausted.

So a website with plenty of bandwidth is not necessarily able to withstand a large volume of CC / L7 Requests. This is also why RPS (Requests Per Second) is usually far more meaningful than BPS alone when identifying a CC Attack.

BPS, PPS, RPS: What Should You Look at During an Attack?

In many DDoS incidents, the first step is not to start blocking IPs right away. It is to determine which layer of resources is actually behaving abnormally.

In short:

• BPS tells you how much traffic the network is carrying
• PPS tells you how many packets the network is processing
• RPS starts to tell you how many requests the application is handling

At L7, no single one of these metrics is enough to fully characterize an attack.

Why Are CC / L7 Attacks Harder to Identify Than Traditional DDoS?

Imagine three Requests:

• A real user: GET /product/123
• An ordinary Crawler: GET /product/123
• A malicious Bot: GET /product/123

Looking at a single HTTP Request, there may be no visible difference between them. So at L7, a protection system cannot just ask "is this IP on a blocklist?" It also needs to look at:

• Request Frequency and Request Interval
• URI / API Endpoint
• IP / ASN Distribution
• User-Agent, TLS / Device Fingerprint
• Cookie / Session, Navigation Pattern, and Historical Behavior

For example, a Client requesting a product page at perfectly identical intervals, or many different IPs producing highly consistent Request Sequences, can be far more revealing than IP Reputation alone.

And when Automated Traffic goes further, combining Distributed IPs, varied User-Agent / Client characteristics, varied Request Intervals, and varied APIs / Endpoints, or even mimicking ordinary browsing, the effectiveness of a plain IP Blocklist drops even more.

At L7, the question shifts from "where is this Request coming from?" to "what is this Client actually doing?"

Keep in mind that a Bot is not the same thing as DDoS. Search engine Crawlers, Monitoring Services, and other legitimate automated tools can also be Automated Traffic. What really needs to be identified is whether this automated behavior is generating large volumes of abnormal Requests, Login Abuse, Scraping, API Abuse, or other application and business risks.

The challenge at L7 is not just spotting abnormal packets. It is spotting abnormal behavior.

As Attacks Look More Like Normal Traffic, How Do You Tell Them Apart and Stop Them?

From Volumetric and Protocol to L7, different DDoS attacks target different resources: bandwidth → connections → application processing capacity.

That means businesses can no longer watch only BPS and PPS. Monitoring has to extend to RPS, API Endpoints, Sessions, Fingerprints, and Behavior. Once an attack reaches L7, malicious Requests may show no obvious difference from real users at all.

Which raises the next question: if different attacks happen at different Layers, is a single type of protection really enough?

In the next article, "From L3/L4 to L7: How to Build a Multi-Layer Defense Architecture", we look at this from an architecture perspective, breaking down which risks DDoS Protection, CC Defense, and Bot Management each handle, and how ByteShield helps businesses build a multi-layer defense from L3/L4 to L7.

FAQ

What are the main types of DDoS attacks?

From the network layer up to the application layer, common DDoS attacks fall into three broad categories: Volumetric Attacks (which consume bandwidth), Protocol / L3-L4 Attacks (which exhaust TCP connections and network resources), and Application / L7 Attacks (which drain Web Server, API, and Database resources). At the application layer, Automated Bot Traffic can also overlap with HTTP Floods, CC Attacks, and API Abuse.

How is a CC Attack different from a traditional high-volume DDoS attack?

A Volumetric Attack mainly consumes network capacity. A CC Attack sends large numbers of HTTP Requests to high-cost Endpoints such as /login, /search, and APIs, consuming the service's processing capacity instead. A single request may be only a few KB, but each one triggers a Database Query or authentication, and together they can saturate backend resources.

During an attack, should I look at BPS, PPS, or RPS?

BPS shows how much traffic the network is carrying and is the key signal for Volumetric Attacks. PPS, along with SYN Rate and Concurrent Connections, shows how many packets and connections the system is handling, which helps identify Protocol Attacks. RPS shows how many requests the application is taking on, which helps identify HTTP Floods and CC Attacks. At L7, you also need URI, Fingerprint, Session, and Behavior data to get the full picture.

If bandwidth is not maxed out, does that mean there is no DDoS attack?

Not necessarily. A Protocol Attack can exhaust the connection resources of a Server, Firewall, or Load Balancer with masses of half-open connections, and an L7 attack can concentrate on draining application resources with normal-looking HTTP Requests. Neither has to cause a noticeable spike in bandwidth.

Is all bot traffic DDoS?

No. Legitimate automated tools such as search engine Crawlers and Monitoring Services also count as Automated Traffic. What really needs to be identified is whether automated behavior is generating large volumes of abnormal Requests, Login Abuse, Scraping, API Abuse, or other business risks.

If your website, app, or API is facing abnormal traffic, explore ByteShield's security protection services, or contact the ByteShield team and we will help you pinpoint which layer of resources the attack is consuming.