A DDoS (distributed denial-of-service) attack is when a large number of hijacked machines send traffic at one target at the same time, so real users can’t get through. Nothing gets broken into and nothing gets stolen; the attacker simply uses up something you only have a fixed amount of, like bandwidth, connection slots or CPU.
That’s the whole idea. The details matter because each attack type burns a different resource, and the defense that works for one does nothing for another.
How a DDoS attack works
The “distributed” part is the point. A single machine flooding your server is easy to block: you drop its IP and move on. A DDoS comes from thousands or millions of sources at once, most of them ordinary devices whose owners have no idea they’re involved.
Those devices form a botnet. The template is Mirai, which in 2016 spread across cameras and home routers still using factory passwords and used them to knock major sites offline. The current generation is bigger. Cloudflare’s 2025 Q4 DDoS threat report puts the Aisuru-Kimwolf botnet at an estimated 1 to 4 million infected hosts, mostly compromised Android TVs, and credits it with a record 31.4 Tbps attack that lasted 35 seconds.
Attackers don’t even need their own botnet. “Booter” services rent attack time by the minute, so a game server can get hit over a grudge.
Gbps, packets per second and requests per second
Attack size gets quoted three ways, and they measure different things.
- Gbps or Tbps (bits per second) is raw volume. If your port is 1 Gbps and 5 Gbps of junk shows up, the link is full before your server sees a single packet.
- Packets per second (pps) is how many individual packets arrive. Routers, firewalls and network cards have a packet ceiling that has little to do with bandwidth, so a flood of tiny packets can knock over a box at a fraction of line rate.
- Requests per second (rps) is how many HTTP requests hit your web server or API. Each one costs CPU, memory or a database query. A few thousand expensive requests per second can sink an app with bandwidth to spare.
During one campaign in Cloudflare’s Q4 2025 report, peaks hit 9 billion packets per second and 205 million HTTP requests per second. Different attacks, different weak points. A provider that only talks about Gbps is answering one of three questions.
The three kinds of DDoS attack
CISA’s joint guide, Understanding and Responding to Distributed Denial-of-Service Attacks, splits attacks into volumetric, protocol and application-layer. It’s a useful map.
Volumetric attacks: UDP floods and amplification
These try to fill your pipe. The simplest is a UDP flood, where the botnet blasts junk UDP packets at random ports.
The nastier version is reflection and amplification. The attacker sends a small request to a public server (a DNS resolver, an NTP server, a memcached instance) but forges your IP as the sender. The server replies to you, and the reply is far bigger than the request. US-CERT alerts list amplification factors of 28 to 54 for DNS and about 557 for NTP. Memcached was worse: Cloudflare saw a 15-byte request produce a 750 KB response in 2018, a 51,200x amplification. DNS still leads. In Cloudflare’s H1 2026 report, DNS floods grew from 25.7% to 40.0% of network-layer attacks between Q1 and Q2.
Protocol attacks: SYN floods
These go after connection state rather than bandwidth. In a SYN flood, the attacker sends the first packet of a TCP handshake over and over, usually from spoofed addresses, and never finishes it. Your server holds a half-open slot for each one until the table fills up. Then legitimate connections get refused. Firewalls and load balancers that track state are just as exposed as the server behind them.
Application-layer attacks: HTTP floods
These look like real traffic. A botnet hits your login endpoint or a heavy API call over and over, from real IPs completing real TLS handshakes. Bandwidth is often modest; the damage comes from making your app do expensive work. Akamai’s 2026 State of the Internet report says Layer 7 DDoS surges are up 104% over two years, with APIs a growing target.
| Attack type | Layer | What it floods | Typical defense |
|---|---|---|---|
| UDP flood | 3/4 (network) | Bandwidth on your port and upstream links | Upstream filtering or scrubbing before traffic reaches your port |
| DNS / NTP / memcached reflection | 3/4 (network) | Bandwidth, via oversized replies from third-party servers | Upstream filtering by source port and protocol; drop what you don’t serve |
| SYN flood | 4 (transport) | Connection tables on the server, firewall or load balancer | SYN cookies, provider-side SYN proxying, connection limits |
| HTTP flood | 7 (application) | CPU, memory, database, worker processes | Rate limiting, caching, bot challenges, a WAF or reverse proxy |
How big and how often
Short version: more and bigger, but mostly small and fast.
Cloudflare’s H1 2026 DDoS threat report counted 23.2 million network-layer attacks in the first half of 2026, about 128,000 a day, including 935 over 1 Tbps (805 of them in Q2). That’s the headline. The quieter numbers matter more to most server owners: 96.62% of network-layer attacks stayed under 500 Mbps, and 90.60% ended in under 10 minutes.
So the attack most likely to hit you isn’t a record-breaker. It’s a few hundred megabits that’s over before anyone opens a ticket, and it can still saturate a small port or drop a game server’s players. Mitigation that waits for a human is too slow.
What a server owner can actually do
Upstream mitigation vs on-box firewalling
This is the part people get wrong. Your server’s firewall (iptables, nftables, Windows Firewall) only sees packets that already crossed your network port. If the attack is bigger than the port, the port is full and the firewall has nothing to decide. On-box filtering can’t stop a volumetric attack. Full stop.
What it can do is useful: drop traffic to ports you don’t use, enable SYN cookies, cap connections per IP and throttle abusive clients. That handles small protocol attacks and a lot of application-layer noise.
Anything that fills the pipe has to be stopped upstream, at your provider’s edge or a scrubbing network, before it reaches your port. That’s what “DDoS protection” from a host should mean. If it lives only on your server, it’s a firewall.
Rate limiting
For HTTP floods, rate limiting is the tool you control. Limit requests per IP on expensive endpoints like login and search. Cache whatever you can so repeat requests never touch your app, and put a reverse proxy (nginx, HAProxy or a CDN) in front of the app server to absorb the junk.
Don’t leak your origin IP
A CDN or proxy protects nothing if attackers can find the server behind it. Common leaks are mail. or dev. DNS records pointing at the same box, old DNS history and email headers. After moving behind a proxy, give the origin a new IP and lock its firewall to the proxy’s ranges.
Questions to ask a host before you buy
Most “DDoS protected dedicated server” listings say the same thing. The difference shows up in the answers to these:
- What happens when an attack exceeds what you’ll filter? Get the over-limit policy in writing.
- Do you null-route my IP during an attack? A null route (blackhole) drops all traffic to your IP, good and bad. It protects the host’s network. It takes you offline, which is exactly what the attacker wanted. If that’s the plan, you don’t have DDoS protection. You have an off switch.
- Is attack traffic billed against my transfer or 95th percentile? You shouldn’t pay for someone else’s flood.
- How fast does mitigation start? Automatic detection in seconds, or a ticket someone answers later? With 90% of attacks over in 10 minutes, this matters.
- Does it cover Layer 7, or only volumetric? Many plans filter network floods and leave HTTP floods to you. That’s fine if you know it.
Shopping for “cheap DDoS protected dedicated servers” is reasonable. Just price in the answer to question 2, because a cheap server that gets blackholed every time a competitor gets annoyed isn’t cheap.
DDoS protection on GigeNET dedicated servers
We’ve run networks since 1998, so these are the questions we’d want a host to answer for us.
On our Chicago dedicated servers, DDoS protection shows on the order form at $0. It’s included, not an add-on. How our mitigation works and what each tier covers is on the DDoS attack mitigation page. Ask us the five questions above before you buy, not after an attack. Builds in Chicago, Ashburn and Los Angeles are on the dedicated servers page.
FAQ
Yes. In the US, launching one or paying a booter service to do it is a federal crime under the Computer Fraud and Abuse Act. If you’re hit, CISA’s guide says to tell your hosting provider and report the attack to CISA or the FBI.
A firewall on your server can stop small protocol attacks and some application-layer floods. It can’t stop an attack bigger than your network port, because the port fills before the firewall sees the traffic. That has to be filtered upstream.
Most are short. Cloudflare found 90.60% of network-layer attacks in H1 2026 ended in under 10 minutes. Short attacks are often repeated, so one bad afternoon can be a dozen separate hits.
A DoS attack comes from one source, so blocking that source ends it. A DDoS attack comes from thousands of hijacked devices at once, so there’s no single IP to block. That’s why defense happens at the network edge.
If it’s public-facing, yes. Game servers, VPN endpoints, stores and APIs are frequent targets, and even a sub-500 Mbps attack can swamp a typical port. What matters is whether protection runs upstream and what the host does when an attack outgrows its filters.
If you want a server with DDoS protection included and straight answers on how mitigation works, request a custom quote and tell us what you’re running.
