Types of DDoS Attacks Explained: Volumetric, Protocol, and Application

"DDoS attack" gets used as if it names a single thing. It does not. The floods that knock services offline fall into a few distinct families, and each one breaks a different part of your setup. That difference matters, because the defense that stops one type can be useless against another. If you are choosing protection, or trying to work out why a service you already pay for still went down, knowing which kind of attack you are facing is the part that makes everything else make sense.

This guide explains the main types of DDoS attacks in plain language, what each one actually does to your server, and why telling them apart changes how you defend against them.

The three families of DDoS attacks, and where a filtering layer sits in front of a service.

First, what a DDoS attack is

A DDoS attack, short for distributed denial of service, is an attempt to knock a service offline by overwhelming it with traffic from many sources at once. "Distributed" is the important word. Instead of one machine, the traffic comes from hundreds or thousands of them, often a botnet, which is a group of computers or devices an attacker controls without their owners knowing.

The goal is almost always the same: to make a website, game server, or application stop responding for real users. What changes from one attack to the next is the method, and the method is what sorts them into families. Security teams usually group DDoS attacks into three of them:

• Volumetric attacks overwhelm your internet connection's capacity, sending so much traffic that the link fills up before it reaches you.

• Protocol attacks overwhelm the machinery that tracks connections, using fake or half-finished connections to clog the server.

• Application-layer attacks overwhelm the application itself, with requests that resemble real visitors but arrive in floods.

  The rest of this guide takes each one in turn, because the differences between them decide which defense actually helps.

Volumetric attacks: filling the pipe

A volumetric attack tries to send more data than your internet connection can carry. Picture a single-lane road: it does not matter how fast your car is if ten thousand other cars are jammed onto the road ahead of you. Once your connection is full, legitimate visitors cannot get through, and your own firewall never gets a chance to help, because the congestion happens upstream, out on the wider internet, before the traffic reaches anything you control.

These attacks are measured in bandwidth, usually gigabits per second (Gbps), which is just the amount of data arriving each second. Common examples include UDP floods, which throw large volumes of packets at your ports to saturate the link, and reflection or amplification attacks, which bounce small requests off other servers so those servers reply with much larger responses aimed at you.

Because the damage happens on the connection itself, the only real fix is to filter the traffic earlier, inside a network with far more capacity than your own link. That is the model behind network and ASN protection, where large floods are absorbed upstream and only clean traffic is handed back to you. Rules on your own server cannot solve a problem that arrives before the server does.

Protocol attacks: exhausting the machinery

The second family does not try to fill your bandwidth. It targets the parts of a network connection that keep track of who is talking to whom.

Here is the plain version. Every time a device connects to your server, the two sides run a short back-and-forth to agree that the connection is real. This is called a handshake, and your server sets aside a small amount of memory for each one while it waits. A SYN flood abuses this by starting thousands of handshakes and never finishing them, so your server fills up with half-open connections that lead nowhere and has no room left for genuine visitors. Related versions, such as ACK floods and connection-exhaustion attacks, burn processing power or hold connection slots open so real clients are locked out.

These are often called Layer 3 and Layer 4 attacks, named after the parts of network communication that handle addresses and connections (the formal terms are the network and transport layers). You do not need to memorize the numbering. The useful idea is that these attacks jam the plumbing of a connection rather than flooding the pipe, so defending against them means filtering out the fake or unfinished connections before they pile up. Sterile Networks handles this class with always-on Layer 4 protection for applications, which filters SYN floods, ACK floods, and connection-exhaustion attempts at the edge before they reach your origin.

Application-layer attacks: traffic that looks legitimate

The third family is the trickiest, because the attack barely looks like an attack.

An application-layer attack sends requests your server treats as normal, a page load, a login, a search, but sends far more of them than the application can handle, or aims them at the most expensive actions. Because each request completes a real connection and speaks the correct language, the usual defenses that catch fake or unfinished traffic wave it straight through. This is often called a Layer 7 attack, after the application layer where your actual software runs.

The hard part is separation. For a single request, a flood of bot traffic and a first-time customer can look identical. That is also why a plain rate limit, which caps how many requests you accept, tends to fail against this kind of attack: the cap cannot tell the flood from your real users, so it starves both at the same time. We went through exactly that failure in why rate limiting alone can't stop modern DDoS attacks. Stopping application-layer floods depends on judging traffic by how it behaves over time, not by any single packet.

Each family of attack targets a different point on the path to your application.

Why the category changes your defense

It is worth learning the difference because each family defeats a different defense.

• A firewall on your server can handle small floods but is helpless once your connection is saturated by a volumetric attack, because the congestion sits upstream of it.

• Challenge-based tricks that drop fake connections stop many protocol attacks but pass application-layer floods, which complete real connections.

• A rate limit can blunt some abuse but cannot separate a disguised flood from genuine demand.

  Real incidents often mix families, for example a volumetric flood to fill the link while an application-layer flood hammers a login page at the same time. Protection that only covers one type leaves a gap for the others.

  Two more things decide whether a defense holds. The first is whether it is always on. A flood can fill a connection in seconds, so protection that switches on only after someone notices an attack tends to arrive too late. The second is where the filtering runs. If it sits in front of your infrastructure, inside a network built to absorb floods, the attack never reaches you. If it runs on the server itself, you have already paid for the traffic in bandwidth and processing before anything gets filtered.

  Without upstream filtering the flood reaches the server; with it, only clean traffic gets through.

What to ask a protection provider

When you compare options, the useful questions follow the three families:

• Can it absorb large volumetric floods measured in gigabits per second, upstream of my connection?

• Does it filter protocol attacks like SYN and ACK floods before they reach my server?

• How does it handle application-layer floods that complete real connections and look like ordinary users?

• Is the protection always on, or does it activate only once an attack has been detected?

  A provider that answers only the first question is solving about a third of the problem. Game servers, hosting companies, and online applications are among the most frequent targets precisely because attackers can rent floods cheaply and switch between types until something works.

Getting the right protection in place

You do not need to become a network engineer to make a sound decision here. Start by naming what you actually run, a single game server, a web application, or a whole network with its own address space, and match it to protection that covers all three attack families rather than one. From there you can review the available protection plans, or contact the Sterile Networks team to talk through your specific setup.

Stay online. Stay Sterile.