DDoS Protection for Real-Time WebSocket and gRPC Services

Most DDoS thinking still assumes HTTP: a request lands, gets checked, gets served or dropped, and the transaction is over in milliseconds. WebSocket and gRPC don't work that way. A WebSocket handshake upgrades a plain HTTP/1.1 connection into a full-duplex channel that stays open, sometimes for hours, and either side can send a frame at any moment for as little as 2 to 10 bytes of overhead. gRPC runs on HTTP/2 and Protocol Buffers, multiplexing hundreds of independent streams over one TCP connection, with binary payloads that a signature-based rule set can't even read. Once you accept that these connections persist and accumulate state on the server, the whole defense problem changes shape. This isn't a bigger version of the same volumetric fight, it's a structurally different one, and it opens three attack surfaces that stateless HTTP never had to deal with.

The first is connection exhaustion. An attacker opens thousands of WebSocket or gRPC streams and just holds them, barely sending anything, until file descriptors and memory on the server run out. It's the DDoS equivalent of reserving every table at a restaurant and never ordering.

The second is message-layer flooding. Once a connection is open and authenticated, an attacker can push a high volume of frames through it, and because most perimeter tools only watch new-connection rates, this traffic is invisible to them. The front door has a bouncer, but there's no one checking what happens once you're inside and start throwing things.

The third is the slow-message attack, a cousin of Slowloris. Instead of flooding, the attacker trickles frames just often enough to dodge the server's timeout, pinning a connection slot open indefinitely while contributing almost nothing to bandwidth graphs.

gRPC has its own wrinkle on top of these: because multiplexing lets one connection carry hundreds of streams, an attacker can open new streams faster than the server can close old ones, exhausting stream IDs or memory without ever tripping an IP-based threshold. WebSocket, lacking that multiplexing, makes connection count itself a fairly honest proxy for server load, and that is why connection floods are the primary vector against it. Either way, Protobuf's binary format defeats plaintext pattern matching. And current botnet tooling doesn't help: current botnet tooling routes traffic through residential and mobile IP ranges and reproduces browser-grade handshake behavior convincingly enough to make IP reputation and static rule matching close to useless on their own.

Splitting the whole problem into two phases makes it more tractable: the handshake, where traditional controls still have some grip, and everything after the handshake, where most of them have no grip.

How the broader DDoS environment makes 2026 harder

The backdrop isn't calm. StormWall's analysts clocked a 198% jump in DDoS attacks in 2025, with 70% of websites hit at least once during the year. Their forecast for 2026 puts the number as high as 58 million attacks, with the share of affected websites potentially topping 85%. None of that is comforting for anyone running a real-time service, but the more relevant number might be the multi-vector figure: an 83% rise in multi-vector attacks in 2025, with close to a third of all incidents already combining two or more attack types, and StormWall projecting up to 65% of 2026 incidents will be multi-vector.

Application-layer targeting has caught up with the shift toward persistent protocols too. Current attack reporting identifies WebSocket, GraphQL, and gRPC endpoints specifically, not just generic HTTP floods, as deliberate targets. These are exactly the surfaces described above, connection exhaustion, message flooding, and slow drips designed to sit under detection thresholds, and that overlap is what makes it matter.

The cost math backs up the urgency. Kentik's data puts the average attack duration at 45 minutes, 18% longer than in 2023, and estimates unprotected organizations lose around $270,000 per incident, working out to roughly $6,000 a minute. Multiplying that by a multi-vector event makes the arithmetic ugly fast.

Then there's the AI angle, which is less a future risk than a current one. Thales' Bad Bot Report found AI-powered bot attacks rose 12.5 times year over year in 2025, and agent-based AI traffic grew 7,851%. Agentic workflows, by design, open and hold connections at scale, which makes them a natural, if unintentional, amplifier of the persistent-connection issue this piece is about.

Putting it together, a real-time service under a serious attack in 2026 is fighting three battles at once. It's absorbing volumetric pressure at the network layer, connection exhaustion at the transport layer, and message flooding at the application layer, all at once, and each of those three planes needs its own control strategy. Treating them as one problem is how services go down.

Different defenses for WebSocket and gRPC

Lumping WebSocket and gRPC together as "the persistent connection problem" is a useful start and a bad place to stop. They don't share an authentication model, a load-balancing story, or even a payload format, and defenses built for one will misfire against the other.

WebSocket is stateful, schemaless, and browser-native. It runs over an upgraded HTTP/1.1 TCP connection, one connection equals one channel, there's no built-in multiplexing, and the payload can be JSON, binary, or plain text, whatever the application wants. gRPC, by contrast, enforces a schema through .proto contracts, runs over HTTP/2 with native multiplexing, and serializes everything as binary Protobuf. A single gRPC TCP connection can carry hundreds of independent streams, and the protocol has built-in support for mutual TLS and per-call tokens.

Authentication diverges just as sharply. WebSocket typically authenticates once, at the upgrade handshake, using a cookie or token, and after that the connection is simply trusted. A spoofed or hijacked handshake becomes an authenticated flood with nothing further to check. gRPC's mTLS and per-call tokens give each stream its own identity, at least in theory, but that requires deliberate configuration, and plenty of internal microservice deployments skip it and run insecure by default, which is its own quiet liability.

Load balancers treat the two protocols differently too. WebSocket needs sticky sessions or shared state, and most load balancers will break it silently unless someone configures that explicitly. gRPC's HTTP/2 multiplexing means a load balancer can see a perfectly reasonable connection count and still watch a single backend get saturated, because all the damage is happening inside one connection across hundreds of streams.

Proxies compound the mismatch. Ingress proxies like Envoy or NGINX ship with defaults tuned for HTTP/1.1, and those defaults break streaming endpoints in different ways for each protocol unless buffering gets disabled and timeouts get reset intentionally.

Performance benchmarks add a final twist: streaming 10,000 events per second to 100 clients, gRPC outpaces WebSocket on throughput, thanks to HTTP/2 multiplexing and binary encoding. That's good news for legitimate load, since a gRPC service can absorb more of it before buckling. It's also bad news under attack, because that same efficiency lets a malicious stream carry more damage per connection. Same underlying problem, opposite tools required.

The two-layer control model: connection phase and message phase

No single control stops application-layer DDoS on a persistent connection. A defense-in-depth approach splits the job into two phases, and the split isn't cosmetic, it's the whole architecture.

Layer one is the connection phase, where the traditional toolkit still functions. Rate-limit new connection attempts per IP or per authenticated user before the WebSocket upgrade or the gRPC stream even opens. Terminate TLS at the edge and reject anything that isn't wss:// for WebSocket or encrypted-transport-wrapped for gRPC, rather than merely discouraging plaintext. WAF inspection works here too, though only here: for gRPC, managed WAF rules operate on headers during the connection phase and never touch the content of an open stream, as developer documentation on the limitation states. Schema enforcement, of the API Shield variety, can validate a gRPC stream against its .proto contract at the edge and reject malformed or unexpected types before they ever reach origin. Bot fingerprinting signals are richest right here, at the TLS and HTTP handshake. Residential-proxy and headless-browser detection has to happen there, before the connection ever gets the chance to upgrade.

Layer two is the message phase, where most of the connection-phase tooling goes blind. Rate limits need to apply per message and per connection, not just per new connection per IP, because a single authenticated WebSocket can flood the application layer all by itself. Backpressure matters here too: slow down or disconnect clients that blow past a byte-in threshold before the server itself buckles. PingIdentity's ASE documentation describes five independently configurable flow-control variables for WebSocket specifically: client spike threshold, bytes-in threshold, bytes-out threshold (which doubles as data-exfiltration protection), server connection quota, and client flow control that drops sessions once limits are crossed. gRPC needs its own equivalents: stream-count limits per connection, per-stream deadline enforcement, and server-side cancellation of streams that go idle or run too long. Both protocols benefit from liveness checks, ping/pong for WebSocket and deadline propagation for gRPC, so dead or zombie connections get cleared instead of sitting there pinning a server slot for no reason.

The two layers don't substitute for each other. A control that stops a connection flood at the handshake does nothing against a flood of messages inside a connection that already passed inspection, and the reverse is equally true. A control that stops a connection flood at the handshake does nothing against a flood of messages inside a connection that already passed inspection, and the reverse is equally true.

Where WAF and WAAP rules break down for these protocols

Traditional WAFs were built around HTTP request and response pairs, checked against signature rules, on the assumption that every transaction is discrete, readable, and stateless. WebSocket and gRPC break that assumption almost by definition. That is why the industry now talks about WAAP, Web Application and API Protection, as Gartner's term for the next step beyond plain HTTP inspection, extending coverage to API-specific abuse across REST, GraphQL, and gRPC.

The gRPC gap is this: WAF managed rules run only against headers during the connection phase, and developer documentation is explicit that they never inspect the content of an open gRPC stream. That's not a setting someone forgot to flip; it's how the mechanism works. There's a related access-control gap too: standard reverse-proxy access controls don't cover gRPC traffic sent through a reverse proxy, and gRPC traffic gets ignored by those access layers if gRPC is enabled. The practical implication is direct: sensitive origin servers behind that kind of access control need a separate authentication path for gRPC traffic, or gRPC exposure to origin should be restricted.

None of that leaves the message phase undefended, it just means the defense has to come from somewhere other than the WAF. Schema enforcement through API Shield-style .proto validation rejects structurally invalid Protobuf before it ever reaches the application. Client certificate authentication, mTLS, authenticates each gRPC stream on its own rather than trusting the TCP connection as a whole. Behavioral rate limiting, applied per connection and per stream rather than matched against signatures, catches anomalies a WAF rule was never built to see. And bot management scoring at the handshake layer catches credential-stuffed or botnet-sourced connection attempts before they ever get to upgrade.

The bot side of that gap is widening fast. Thales' Bad Bot Report clocks AI scraper traffic growing 597% in 2025, from roughly 2 million to 25 million requests a day. Bots at that volume are sophisticated enough to complete a full WebSocket handshake and hold the connection open convincingly. Behavioral scoring inside the session isn't a nice-to-have anymore, it's load-bearing. Anyone running gRPC behind a WAF without knowing about the stream-content gap isn't protected at the message layer. They just think they are, which is arguably worse.

Bot management for persistent connections: why connection-time detection is not enough

Thales' 2026 Bad Bot Report puts a number on how fast this has moved: AI-powered bot attacks up 12.5 times year over year in 2025, agent-based AI traffic up 7,851%. Agentic bots are now a primary source of persistent-connection abuse, and they didn't get there by accident, they got there because the connection model rewards patience.

Each detection category has a specific blind spot against this kind of traffic. Network signals, IP reputation and ASN checks, get walked around by residential proxy networks, since a botnet routed through home IP ranges looks legitimate at the network layer no matter what it's actually doing. Browser fingerprinting gets patched over by production-grade headless browser frameworks that now reproduce browser-grade TLS stacks and HTTP/2 behavior convincingly enough to pass. Behavioral signals need enough session interaction to generate a usable pattern in the first place, and a bot that opens a WebSocket connection and simply holds it open, without sending anything anomalous, may not produce a detectable signature for a long time, if ever.

None of the three categories works alone, and treating any one of them as sufficient is the mistake. The case for combining network, fingerprint, and behavioral signals together, because each covers a gap the others leave open. The 2026 automated traffic mix bears this out: simple scripts, residential-proxy abuse, headless browsers, credential-stuffing tools, AI crawlers, API abuse, and agentic workflows all appear in the numbers, and the last two categories map directly onto WebSocket and gRPC endpoints specifically.

For a persistent-connection service, scoring has to start before the upgrade happens and, ideally, keep running through the life of the session, watching for anomalies in message cadence and payload volume. A bot that clears handshake inspection cleanly can still give itself away later through timing that's just a little too regular, or a payload pattern no human would produce. DataDome's published figures describe analyzing 5 trillion signals a day with layered AI, stopping fraud in under 2 milliseconds, and holding a false-positive rate under 0.01%, numbers that illustrate the scale this kind of detection now runs at. Running that scoring on the same edge pipeline as the WAF, DDoS mitigation, and schema enforcement, rather than as a bolt-on layer traffic has to detour through, is the practical argument for a unified platform over a stack of point solutions: separate inspection layers add latency, and latency is what a real-time connection can't absorb.

Infrastructure choices that determine how much protection is achievable at the edge

Raw mitigation capacity sets a hard ceiling on what's possible. The largest DDoS attack on record peaked at roughly 31.4 Tbps, and a mitigation network has to absorb traffic at that scale while still serving every other customer on the same infrastructure. Networks operating in the 300 Tbps range have more than fifty times that peak in headroom, which is the kind of margin this fight actually requires.

Capacity alone doesn't finish the job for real-time protocols, though. Latency under load counts just as much as raw absorption, because a mitigation layer that adds even a few tens of milliseconds of jitter can wreck the experience of a collaborative editing tool or a live financial data stream, even while successfully blocking the attack. Stopping the flood and killing the product are not meaningfully different outcomes if the fix breaks the thing it was protecting.

Geography matters just as directly. A WebSocket or gRPC connection terminates at a specific edge location, and if that location sits far from the client, round-trip latency compounds across every single frame exchanged over the life of the connection. That's not a one-time cost; it's a tax paid on every message. The edge node needs to sit close to both the user and the origin, not just one or the other.

Anycast routing is the mechanism that makes volumetric floods survivable at scale, spreading incoming traffic across an entire network instead of funneling it toward one scrubbing point. That distribution matters most for connection floods specifically, since attack traffic in that scenario tends to arrive from a large spread of source IPs simultaneously, and a single choke point would just recreate the exhaustion it's supposed to prevent.

None of this is exotic engineering. The unglamorous, load-bearing infrastructure decisions, capacity headroom, latency budget, edge placement, and anycast distribution, decide whether a WebSocket or gRPC service actually survives 2026's attack environment or just adds another incident report to the pile.