Real-Time Backend
DDoS and Abuse
In 2016, Dyn DNS was hit by a DDoS via the Mirai botnet. Twitter, Netflix, and GitHub went down. WebSocket servers are vulnerable in a particular way: one connection stays open for hours, and the attacker pays for it once while the server pays continuously.
- **Cloudflare** blocks over 140 billion threats daily, applying connection rate limiting at the anycast network level, before traffic ever reaches the customer's origin server.
- **Discord** runs multi-layered gateway protection: connection limit per IP, message rate limit (120/60s), and real-time ML detection of spam bots across 26+ million concurrent users.
- **Stripe** uses circuit breakers to isolate payment providers: a single gateway failure does not cascade to the others, and the 99.99% SLA holds even during partial downstream outages.
Connection Flooding
Connection flooding is an attack where an adversary opens thousands of WebSocket connections without sending any useful data. Each connection consumes memory (typically 2-8 KB per socket in Node.js) and a file descriptor. With 100,000 concurrent idle connections, the process burns through ~500 MB on buffers alone, before processing a single message.
In 2023, Cloudflare absorbed an HTTP/2 Rapid Reset attack peaking at 201 million rps, a record at the time. The same logic applies to WebSocket: the cost of opening a connection on the client is close to zero, the cost on the server is significant.
For production: a connection limit per IP is the first line, not the only one. Add backpressure at Nginx/HAProxy (limit_conn), analyze TLS fingerprints (JA3) to block bots, and trigger a CAPTCHA challenge during abnormal spikes.
The server is receiving 50,000 new WebSocket connections in 10 seconds from different IPs. Most connections send no data. What is the first sign that distinguishes this attack from legitimate traffic?
Message Spam
Message spam is a scenario where a client with a legitimate connection sends hundreds of messages per second. Discord handles ~26 million concurrent users and applies rate limiting at the gateway level: no more than 120 messages per 60 seconds per client. Exceeding the limit triggers an immediate disconnect. This protects downstream services from avalanche load.
The token bucket algorithm is the standard tool: the bucket refills at a fixed rate (say, 10 tokens/sec), and each message consumes a token. Advantage over a fixed window: bursts up to the bucket capacity are allowed, but the average rate cannot be systematically exceeded.
A token bucket of capacity 20 refills at 5 tokens/sec. The client stays silent for 4 seconds, then sends 25 messages at once. How many messages get through?
Circuit Breaker
In the WebSocket server context, a circuit breaker is a pattern that protects downstream services from cascading failures. When the backend (say, Redis or the database) starts to respond slowly or with errors, the circuit breaker moves to OPEN state and rejects new requests immediately, without waiting for a timeout. Netflix Hystrix popularized the pattern; today it is implemented in Resilience4j (Java) and equivalents for Node.
Three circuit breaker states: CLOSED (normal operation), OPEN (fast failure without touching downstream), HALF_OPEN (a trial request to check for recovery). Stripe uses circuit breakers to isolate payment providers, so a Visa outage does not bring down Mastercard.
A circuit breaker is configured with threshold=3 failures, timeout=10s. Three requests in a row fail. The state becomes OPEN. 15 seconds later a new request arrives. What happens?
Abuse Detection
Abuse detection is behavioral analysis layered on top of rate limiting. Rate limiting answers the question 'how much', abuse detection answers 'how'. Patterns: messages with identical payloads (spam), rapid enumeration of roomId (scanning), invalid JSON after N legitimate messages (fuzzing). Twilio and Stripe combine rule-based and ML models for real-time detection.
Do not ban on a single signal. Combine several: high duplicate ratio plus a growing invalidMessageCount equals a high probability of abuse. False positives on legitimate clients (for example, a mobile client with retries) carry a real reputational cost.
Rate limiting is enough to protect against abuse - as long as limits are not exceeded, everything is fine
Rate limiting protects against volume overload, not against behavioral patterns of abuse within the limits
A client can systematically scan resources, spam duplicates, or probe the API, all within the rate limit. Abuse detection analyzes the pattern, not just the count.
A client sent 200 messages in a minute. 180 of them are the identical JSON {"type":"ping"}. Rate limit is not exceeded (300 msg/min). How should this behavior be classified?
Summary
- **Connection flooding** attacks server resources (FD, memory) without sending data. Defense: a connection limit per IP at the network layer.
- **Token bucket** rate limiting allows controlled bursts and shields downstream from message spam. It is the standard in production WebSocket servers.
- **Circuit breaker** isolates downstream service failures (CLOSED → OPEN → HALF_OPEN), and abuse detection reveals behavioral patterns invisible to a rate limiter.
Related topics
DDoS and abuse protection overlap with several adjacent areas:
- Authentication and JWT — Authentication during the handshake is the first line of defense against anonymous connections
- Monitoring and Alerting — Connection count and message rate metrics are the basis for real-time anomaly detection
- Load Balancing — A load balancer can absorb connection floods before they reach application servers
Вопросы для размышления
- How do you distinguish a legitimate mobile client with aggressive reconnect retries from a connection flood bot?
- Under what conditions can a HALF_OPEN circuit breaker amplify load on a recovering service?
- Which behavioral patterns of a WebSocket client indicate automated scraping that stays within the rate limit?