Why a flood can shut out real visitors
A server has limited capacity: it can handle only so many network connections and requests at once. Each request may require memory, processor time, or a trip to a database. When incoming work arrives faster than the system can finish it, tasks pile up in queues. Those queues consume resources too, and eventually new visitors may time out or be refused—even if the server itself has not been physically damaged.
The attack does not always need to send unusually complicated requests. A sufficiently large volume of ordinary-looking traffic can occupy the same connections and processing capacity that genuine visitors need. In other cases, attackers target a particularly expensive operation, making each request consume more of the server’s effort.
Why blocking traffic is difficult
When requests come from many compromised devices, their addresses can be spread across different networks and regions. Some may resemble normal visitors, so bluntly blocking broad ranges can also cut off legitimate users. The defender has to distinguish harmful patterns while the system is already under strain.
Protection often works by spreading the job: network providers and specialized filtering services can absorb or inspect traffic before it reaches the target server. Systems may also limit how much work a connection can request, or require extra checks when traffic looks suspicious. These measures can reduce the flood, but they involve tradeoffs: stricter checks may slow real users, while filtering too lightly lets more attack traffic through.
The practical consequence is that resilience depends not only on a server’s raw power, but on where traffic is screened and how quickly the service can separate useful requests from the flood.
