A DDoS attack overloads one of a limited set of resources — the channel's bandwidth, the number of open connections, or the application's processor time. A site goes down not "from a hack" but from exhausting one of these resources.
How DDoS differs from DoS and from a hack
The three terms are often confused, even though their mechanics and their goal differ. The table shows the difference across three traits.
| Term | Goal | Source | What remains afterward |
|---|---|---|---|
| DoS | Make the site unavailable | A single traffic source | Availability returns right after the source is stopped |
| DDoS | Make the site unavailable | Many distributed sources at once | Availability returns after the traffic is filtered |
| Hack | Gain access to data or control | A single attacker exploiting a vulnerability | Stolen data or altered site files |
Three levels where the overload happens
Different resources can be overloaded, and each level has its own signs in logs and metrics.
| Level | What gets exhausted | How it shows up |
|---|---|---|
| Channel | Network bandwidth | A sharp rise in incoming traffic on the channel graph |
| Transport | The number of open network connections | Many half-open connections sitting in a waiting state |
| Application | Processor time and memory of the application | Response time grows at an ordinary traffic level |
Why the attack is distributed
A single traffic source is easy to stop: a firewall rule blocks the specific address, and the attack stops. With thousands of sources this does not work — blocking each one individually cannot keep up.
The sources are usually infected devices joined into a network under shared control (a botnet). Their owners most often do not know their device is taking part in an attack.
What happens to a site step by step
From a site owner's point of view, the overload develops predictably, and every step is visible in the server's own metrics.
- The server's response time to ordinary requests grows.
- The queue of unprocessed requests grows faster than the application can work through it.
- The application hits a limit on concurrent connections or processes.
- The server starts returning an error or stops responding at all, even to ordinary visitors' requests.
How to tell an attack from a wave of real visitors
A spike in load does not always mean an attack — sometimes it is a genuine wave of visitors. Logs carry signs that tell one from the other.
- Requests arrive from an unusually large number of different addresses at once.
- The requests are uniform: the same path, the same method, and nearly identical parameters.
- There are almost no requests for static files — styles, scripts, images that a browser normally loads.
- The request headers are missing fields typical of a real browser, or they look identical across all of them.
Why defense is built in layers
Each level of overload needs its own defense: filtering at the network edge does not save the application itself from being overloaded, and the other way around. That is why a single firewall is not enough.
How defense is arranged at the different levels is covered in the articles on DDoS protection and protection with Nginx and Cloudflare.
What to do before an attack
Part of the preparation needs no special tools — only order and attention to the server's normal state.
- Know your site's normal load figures so a deviation is noticed quickly.
- Keep hosting support contacts and the domain's DNS zone holder's contacts on hand.
- Keep server logs for a reasonable period — without them, reviewing an attack after the fact is impossible.
- Do not publicly disclose the server's real address where it is not necessary.