Your web server can handle 10,000 requests per second. An attacker sends 10 million. Without rate limiting, your server processes every single one until it collapses. With rate limiting, you define the threshold — and everything above it is dropped before it reaches your application.
That’s the concept. But the implementation details determine whether rate limiting is a precision surgical tool or a blunt instrument that harms your legitimate users as much as it hurts the attacker.
The Basic Concept
Rate limiting restricts the number of packets, requests, or connections that pass through a network device within a defined time window. When traffic exceeds the configured threshold, excess packets are dropped — preventing the target system from being overwhelmed.
In its simplest form, rate limiting works like a valve on a water pipe. Set the valve to allow 1,000 liters per minute, and any flow exceeding that rate is diverted. The pipe never bursts.
But network traffic isn’t water. It comes from millions of different sources, uses dozens of different protocols, and mixes legitimate requests with attack traffic in the same stream. A simple global rate limit treats all traffic identically — and that’s the problem.
Three Types of Rate Limiting
1. Global Rate Limiting
Global rate limiting applies a single threshold to all incoming traffic, regardless of source. If you set a limit of 50,000 packets per second on UDP port 53, the 50,001st packet is dropped — whether it’s from an attacker or from your most important customer’s DNS resolver.
When it’s useful: Protecting services with well-defined, predictable traffic volumes. If your DNS server normally handles 10,000 queries per second and suddenly receives 500,000, a global limit of 20,000 stops the bulk of the attack.
When it fails: Any scenario where legitimate traffic is significant relative to the limit. During a large DDoS attack, a global rate limit randomly drops packets — some attack, some legitimate. Your users experience degraded service even though “mitigation” is active.
2. Per-Source Rate Limiting
Per-source rate limiting tracks each source IP address independently. Instead of one global counter, the system maintains a separate counter for every unique source. Each source gets its own threshold.
If you set a per-source limit of 100 packets per second, a legitimate user sending 50 packets per second passes through without restriction. An attacker sending 50,000 packets per second is throttled to 100 — while every other source remains completely unaffected.
When it’s useful: Nearly always. Per-source limiting is the most effective general-purpose rate limiting strategy because it isolates abusive sources without impacting legitimate traffic.
When it fails: Distributed attacks from botnets where each bot sends only a small amount of traffic. If 100,000 bots each send 50 packets per second, per-source limits of 100 PPS won’t trigger — because no single source exceeds the threshold. The aggregate, however, is 5 million packets per second.
3. Per-Rule Rate Limiting
Per-rule rate limiting applies a threshold to all traffic matching a specific firewall rule, regardless of source. This is a hybrid approach — more targeted than global limiting (it applies only to traffic matching specific conditions) but shared across all sources that match the rule.
When it’s useful: Controlling traffic to specific services or protocols. A rule that matches UDP port 53 with a rate limit of 100,000 PPS caps DNS-related traffic while leaving all other protocols unlimited.
Rate Limiting in Practice: Real Scenarios
Scenario 1: UDP Flood on a Gaming Server
A gaming server receives legitimate UDP traffic on ports 27015-27030 from ~5,000 concurrent players, each generating ~20 packets per second. Total legitimate traffic: ~100,000 PPS.
An attacker launches a 50 million PPS UDP flood targeting port 27015.
| Strategy | Result |
|---|---|
| No rate limiting | Server crashes. All players disconnected. |
| Global limit: 200K PPS | ~99.6% of traffic dropped randomly. Players experience severe packet loss. |
| Per-source limit: 100 PPS | Attacker’s sources throttled to 100 PPS each. Legitimate players unaffected. |
Scenario 2: SYN Flood on a Web Server
A web server normally receives 500 new connections per second. An attacker sends 2 million SYN packets per second from spoofed IPs.
| Strategy | Result |
|---|---|
| Global SYN limit: 5K PPS | Works, but may drop legitimate SYN packets during peak hours. |
| Per-source SYN limit: 10 PPS | Spoofed IPs each limited to 10 SYN/s. Legitimate users send 1-2 SYN/s. Perfect isolation. |
| Combined with stateful validation | CoreEdge™ validates handshakes AND rate-limits. Double-layer mitigation. |
Scenario 3: DNS Amplification Attack
Your network receives 500,000 DNS response packets per second from 10,000 different open resolvers. You sent zero DNS queries.
| Strategy | Result |
|---|---|
| Block UDP port 53 | Stops attack but breaks all outbound DNS. |
| Global rate limit UDP 53: 10K PPS | Reduces flood but some amplification traffic still reaches server. |
| Per-source limit: 50 PPS on UDP 53 | Each reflector limited to 50 responses/s. Legitimate resolvers unaffected. Attack neutralized. |
The Burst Problem
Real network traffic is bursty. A web application might receive 100 requests per second on average but spike to 500 during page loads or AJAX bursts. A rate limiter set to 100 PPS would drop legitimate traffic during these natural spikes.
The solution is burst tolerance — allowing the rate limiter to absorb short spikes above the threshold before enforcement begins. This is typically implemented as a token bucket or leaky bucket algorithm.
CoreEdge™ exposes a rate_limit_burst parameter (configurable from 1 to 10) that controls how tolerant the limiter is of short traffic spikes. A burst value of 1 enforces strictly. A burst value of 5 allows temporary spikes of up to 5x the configured rate before dropping begins.
Rate Limiting at Different Layers
Rate limiting can be applied at multiple points in the network stack, each with different trade-offs:
| Layer | Where | Speed | Precision | Example |
|---|---|---|---|---|
| NIC/XDP | Network card | Fastest | Packet-level | CoreEdge™ |
| Kernel | OS networking stack | Fast | Connection-level | iptables, nftables |
| Application | Web server/proxy | Slowest | Request-level | Nginx, HAProxy |
| CDN | Edge servers | Fast | HTTP-level | Cloudflare, Akamai |
The earlier in the stack you apply rate limiting, the less resource the attack consumes. CoreEdge™ operates at the XDP layer — the absolute lowest point where software can intercept packets. Attack packets are counted and dropped at the network card before they enter the kernel. Your server CPU never processes them.
How CoreEdge™ Implements Rate Limiting
CoreEdge™ provides three distinct rate limiting actions, each designed for specific operational scenarios:
RATE_LIMIT_RULE (Action 2) applies a global PPS threshold to all traffic matching a rule. Every packet matching the rule’s conditions (protocol, ports, IP ranges, packet length) is counted against a single shared counter. Use this for services with well-defined maximum traffic profiles.
RATE_LIMIT_SRC (Action 3) applies a PPS threshold per individual source IP. This is the precision tool — it isolates abusive sources while leaving legitimate traffic untouched. Each source IP gets its own independent counter and threshold.
CUSTOM_DEFAULT (Action 5) opens the full depth of rate limiting controls, with protocol-specific thresholds:
tcp_syn_rate— separate rate limit for SYN packets onlytcp_non_syn_rate— separate limit for established connection trafficudp_default_rate— global UDP rate thresholdicmp_echo_request_rate— ping request limiticmp_echo_reply_rate— ping reply limitglobal_source_pps— per-source limit across all protocols simultaneously
This layered approach means you can apply different rate limits to different traffic types within the same rule set. SYN packets get one threshold. UDP gets another. ICMP gets a third. And each can be applied globally or per-source.
Common Rate Limiting Mistakes
Setting Limits Too Low
A rate limit that’s too aggressive drops legitimate traffic during normal operation. Always set thresholds based on observed traffic patterns, not theoretical minimums. CoreTech’s Client Portal provides real-time traffic analytics that show your actual PPS, bandwidth, and protocol breakdown — use this data to inform your rate limit configuration.
Using Only Global Limits
Global rate limits are a fallback, not a primary defense. Per-source limiting should be your default approach for any service that accepts traffic from diverse sources.
Ignoring Protocol Differences
TCP and UDP require fundamentally different rate limiting strategies. TCP is connection-oriented — rate limiting SYN packets separately from established traffic prevents SYN floods without disrupting active sessions. UDP is connectionless — per-source limits are essential because you can’t distinguish connection states.
Not Using Burst Tolerance
Strict rate limiting with zero burst tolerance causes false positives during legitimate traffic spikes. Always configure a burst margin appropriate to your traffic profile.
Rate Limiting Alone Is Not Enough
Rate limiting is one component of a comprehensive DDoS mitigation strategy. It works best in combination with:
- Stateful connection tracking — verify TCP handshakes before forwarding packets
- Protocol validation — reject malformed packets regardless of rate
- GeoIP filtering — reduce attack surface by blocking traffic from irrelevant regions
- Behavioral analysis — detect anomalies that rate limiting alone can’t catch
CoreEdge™ and CoreDetection™ provide all of these capabilities as a unified system. Rate limiting handles the volume. Connection tracking handles the state. Protocol validation handles the structure. Behavioral analysis handles the unknown.
10-day free trial — configure rate limits, GeoIP rules, and TCP validation through the Client Portal. Full CoreEdge™ capacity from day one.
Want to see this in action?
Get a live demonstration of CoreTech's DDoS mitigation platform.
