Rate limiting caps how many requests any single source can make in a given window. It doesn't try to identify a specific attack pattern — it simply ensures no one source can consume a disproportionate share of protected resources.
Written for business and infrastructure decision-makers, not protocol engineers.
Rate limiting measures every source, regardless of protocol, against a token-bucket budget before it can consume protected resources. Unlike the flood-specific modules that recognize a particular attack pattern, rate limiting is the general-purpose backstop that sits behind all of them — it catches excessive volume from a source even when the traffic itself looks otherwise legitimate.
A store lets each shopper take a limited number of items per visit, no matter how orderly each individual purchase looks. One shopper repeatedly trying to buy far more than their share gets turned away once they hit the limit — while everyone else checks out normally. Rate limiting applies the same per-source budget to network requests.
Availability risk that belongs in business-continuity planning.
Availability risk that belongs in business-continuity planning.
Availability risk that belongs in business-continuity planning.
Availability risk that belongs in business-continuity planning.
Rate limiting is one of the oldest and most broadly applicable DDoS defenses because it doesn't depend on recognizing a specific attack signature. Any traffic type — HTTP requests, DNS queries, login attempts, API calls — can be flooded, and a rate limit provides a floor of protection regardless of what the flood-specific modules were built to catch.
Attacks against one customer can become an infrastructure and service-quality issue.
Availability, latency and shared network resources are immediately visible to end users.
If users cannot connect, they cannot transact, work or consume the service they pay for.
NeuroWall enforces a per-source token bucket at the XDP layer — tunable at runtime, with no traffic interruption while thresholds change. It sits behind the six flood-specific modules, catching excessive request volume from any source regardless of protocol.
Book a Demo →Rate limiting caps how many requests a single source can make in a given time window, using a rate and burst budget, so no one source can consume a disproportionate share of protected resources.
A token bucket is an algorithm where each source is given a budget of tokens that refill over time; every request consumes a token, and requests are dropped once the bucket is empty.
No. Rate limiting throttles a source once it exceeds a threshold; it does not require permanently blocking the source, and legitimate traffic under the threshold is never affected.
No. It is a general-purpose backstop against excessive request volume from any single source, working alongside protocol- and volumetric-specific modules such as SYN flood or ICMP flood protection.
Yes. NeuroWall enforces a per-source token bucket at the XDP layer as part of its DDoS protection capabilities.