What is DDoS: how the attack works in depth and mitigation techniques

What DDoS is

DDoS (Distributed Denial of Service) is an attack whose goal isn't to steal data, but to make a service unusable — flooding a server, network device, or application with so much traffic or so many requests that legitimate users can't get through. The difference from the older term DoS (Denial of Service) is the word "Distributed": instead of a single attacking device, the traffic arrives simultaneously from thousands to millions of sources — typically a botnet, a network of infected devices (computers, IoT cameras, routers) an attacker controls without their owners' knowledge. The distributed nature of the attack makes defense harder in two ways: the traffic comes from legitimate-looking IP addresses all over the world, so simply blocking one source address doesn't help, and the combined volume of traffic easily exceeds the capacity of a single connection or server, even though each individual infected device is only sending a small amount of data.

Our previous article on cyberattacks mentions DDoS as one of the common threats; this article goes significantly deeper — straight into the mechanics of the protocols that DDoS attacks exploit, and into the specific techniques the industry uses to defend against them at production scale.

TCP/IP in depth: why the internet is inherently vulnerable to DDoS

To understand why DDoS works the way it does, it helps to go back to the fundamentals covered in our TCP/IP article — specifically two properties that were designed in the 1970s and 80s for reliability and simplicity, not security: the lack of source address verification and the stateful nature of the TCP handshake.

Why the sender's IP address is trivial to fake

Every IP packet carries a source address field in its header — but the IP protocol is designed so that nobody along the path verifies it. Routers forwarding a packet only check the destination address to know where to send it next; the sender can therefore put any value it wants into the source address field, and the packet will be routed exactly as if it were authentic. This technique is called IP spoofing, and it's a foundational building block of most volumetric DDoS attacks described below — it lets an attacker either hide the attack's real origin or, in reflection attacks, direct a third party's responses straight at the victim.

The only effective defense at the internet-infrastructure level is BCP 38 (ingress filtering) — a recommendation that internet providers drop, at the edge of their own network, any outgoing packet whose source address doesn't fall within the range assigned to their own customers. The problem is that BCP 38 is only a recommendation, not an enforced requirement, and its adoption depends on the goodwill of thousands of independent networks worldwide — which is why IP spoofing still works today, three decades after this problem was first documented.

SYN flood: exploiting the TCP three-way handshake

TCP establishes a connection in three steps: the client sends a packet with the SYN flag set, the server responds with a SYN-ACK packet and simultaneously allocates memory in its SYN queue (backlog) for a new, still "half-open" connection in the SYN_RCVD state, and finally the client responds with an ACK packet, moving the connection into the ESTABLISHED state. The key detail is that the server allocates memory as soon as it receives the first SYN packet — before it has any certainty that the client on the other end actually exists and will respond.

In a SYN flood attack, the attacker sends a massive number of SYN packets, usually with a spoofed source IP address. The server responds to each one with a SYN-ACK and waits for an ACK — which never arrives, because the spoofed address either doesn't exist or belongs to a device that knows nothing about the request and simply discards the SYN-ACK. The SYN queue quickly fills up with half-open connections waiting for a reply that will never come, and once the queue is completely full, the server starts rejecting even legitimate new connections — not because it lacks compute power, but because it lacks memory in the queue to track their state.

Reflection and amplification: when a server "shouts" at the victim for you

While SYN flood exploits TCP's statefulness, reflection and amplification attacks exploit the opposite property — the connectionless nature of UDP. UDP has no handshake at all: a client simply sends a packet and the server responds without verifying anything. An attacker combines this property with IP spoofing as follows:

1. The attacker finds a publicly reachable server running a UDP service that responds to a small query with a much larger reply (e.g. an open DNS resolver, an NTP server, or a misconfigured memcached instance).
2. It sends that server a query with the source IP address spoofed to the victim's address instead of its own.
3. The server, in good faith, sends its (much larger) reply directly to the victim's IP address — who ends up receiving many times more data than the attacker actually had to send.

The ratio between the size of the original query and the size of the reply is called the amplification factor, and it determines how many times over the attacker multiplies their own bandwidth:

Fragmentation attacks

The IP protocol allows a large packet to be split into smaller fragments, which get reassembled on the destination device (reassembly). Older attacks like Ping of Death exploited bugs in reassembly logic — sending fragments that, once reassembled, formed a packet larger than the operating system could correctly handle, causing a crash or freeze on the target system. Teardrop sent overlapping fragments with mutually inconsistent offsets, which could completely lock up the reassembly algorithms of older TCP/IP stacks. Modern operating systems have long been resistant to these specific techniques, but fragmentation is still used today as a way to bypass simpler firewall rules that only inspect the header of the first fragment.

Classifying DDoS attacks by layer

Application-layer attacks like Slowloris are especially insidious because they don't need high volume — instead of flooding bandwidth, they keep thousands of slow, incomplete HTTP connections open at once (sending request headers extremely slowly, one byte at a time), exhausting the limited number of concurrent connections a web server can handle, even though the total traffic transferred is minimal and hard to distinguish from a slow mobile connection.

For scale context: according to industry reports, the largest attack recorded to date hit 31.4 Tbps in December 2025 (the Aisuru botnet), lasting only 35 seconds — compared to the 3.8 Tbps record from October 2024, that's an increase of over 700% in 14 months, illustrating how quickly the capacity of attack botnets is growing, increasingly built on unsecured IoT devices.

Mitigation techniques in depth

SYN cookies: a stateless solution to SYN flood

SYN cookies solve the SYN flood problem with an elegant trick: instead of allocating memory in the SYN queue as soon as a SYN packet arrives, the server encodes information about the connection (source and destination address, port, timestamp) into a cryptographic hash, which it uses as the Initial Sequence Number (ISN) in the corresponding SYN-ACK packet — and stores no state at all. If the client replies with a legitimate ACK, the server can reverse-verify the hash from the acknowledgment number it receives and reconstruct the needed connection information only at that point. Since an attacker using a spoofed address never sends back a valid ACK, the server never bothers allocating resources for it — the SYN queue physically can't fill up, because it's no longer actually being used as a state store.

Remote Triggered Black Hole (RTBH): fast, but blunt

RTBH is the oldest and simplest network-level defense — an operator announces a route via BGP that redirects all traffic destined for the attacked IP address into a null route (where packets are simply dropped). It works nearly instantly and can be deployed by anyone with a BGP session to an upstream provider, but it has a fundamental drawback: it's a completely indiscriminate measure — legitimate traffic to that address gets dropped right along with the attack traffic. In practice, RTBH means you finish the attacker's job for them — the server becomes unreachable, just for a different reason.

BGP Flowspec: a surgical alternative to RTBH

BGP Flowspec (RFC 5575, extended in RFC 8955) solves exactly this problem — instead of blocking the entire destination IP address, it lets much more granular filtering rules be distributed via BGP, combining multiple attributes at once: source and destination address, port, protocol, packet length, TCP flags, and more. Every Flowspec-capable router in the network effectively turns into a distributed firewall that can apply the rule within seconds across the provider's entire network. This granularity makes it possible, for example, to drop only UDP packets of a specific size characteristic of a particular amplification attack, while other traffic to the same IP address keeps flowing uninterrupted.

Anycast: spreading the attack across a global network

Anycast routing lets the same IP address be advertised simultaneously from dozens or hundreds of geographically distributed data centers; routing protocols automatically direct each client's traffic to the nearest one. During a DDoS attack, this means the volume of attack traffic automatically splits across the entire global network instead of concentrating on one location — an attack large enough to overwhelm a single data center becomes, once spread across hundreds of locations, just a fraction of each one's capacity.

Scrubbing centers and challenge-response for L7

Scrubbing centers are dedicated facilities through which all traffic gets redirected during an attack (typically via a BGP announcement or a DNS change) — there, attack traffic is separated from legitimate traffic using a combination of the techniques above plus checks against threat intelligence databases, and only clean traffic is sent back to the origin server, usually over a GRE tunnel or a dedicated L2 connection. For application-layer (L7) attacks, where the attack traffic looks like legitimate HTTP requests, challenge-response is also used — a CAPTCHA, a JavaScript challenge requiring code execution in the browser (which automated bots usually can't do), or a proof-of-work challenge that forces the client to perform a small computation before its request is even processed — an imperceptible delay of a few milliseconds for a normal user, but a significant obstacle for an attacker trying to hit millions of requests per second.

Behavioral detection and machine learning

Modern anti-DDoS platforms today combine all the techniques above with behavioral analysis — the system continuously builds a baseline of what normal traffic looks like for a specific application (volume, protocol distribution, geographic origin, packet sizes, source-address entropy), and flags any statistically significant deviation from that baseline as suspicious without needing it to match a predefined attack pattern. This approach is especially critical for L7 attacks, which in terms of volume often look like a legitimate traffic spike — only the combination of multiple behavioral signals at once reveals the difference.

How leading anti-DDoS vendors defend against attacks

The following overview maps the specific architectural approaches and techniques that the most significant players in the anti-DDoS market publicly describe as of 2026.

Cloudflare — pure Anycast, no separate scrubbing centers

Cloudflare architecturally differs from most of the competition in that it has no separate scrubbing centers — every one of its 335+ data centers across more than 120 countries can filter attack traffic locally, right where Anycast routing delivers it. This eliminates the detour to a remote scrubbing center, letting Cloudflare achieve mitigation latency on the order of 1–10 ms and automatic attack detection under 3 seconds. Total network capacity exceeds 200 Tbps, DDoS protection is included in every plan including the free tier, and deployment for HTTP/HTTPS traffic is as simple as pointing DNS at Cloudflare.

Akamai Prolexic — dedicated scrubbing centers and a human SOCC

Akamai takes the opposite, more traditional route: it operates 32 anycast scrubbing centers in metropolitan cities worldwide with over 20 Tbps of total dedicated capacity. Traffic during an attack is routed via Anycast to the nearest scrubbing center, where the Security Operations Command Center (SOCC) team — more than 225 security engineers — deploys both proactive and attack-specific custom mitigation rules. Clean traffic is returned to the customer's origin server via a GRE tunnel, an L2 VLAN connection, or direct VIP-to-origin mapping, with minimal perceptible latency. The combination of machine intelligence with human oversight makes Prolexic a choice for organizations that want direct access to experts, not just automation, during large or unusual attacks.

AWS Shield Advanced — automatic mitigation integrated into WAF

AWS Shield Advanced provides automatic inline mitigation across layers L3, L4, and L7, leveraging AWS's global threat intelligence. Since March 2026, the standard protection against HTTP request floods is the Anti-DDoS Managed Rule Group for AWS WAF, which replaced the older Layer 7 Auto Mitigation feature and can detect and mitigate an attack within seconds rather than minutes — the system automatically builds a baseline of normal traffic and adapts detection thresholds to the specific application's behavior. It also includes 24/7 support from the specialized AWS Shield Response Team (SRT) and so-called cost protection — a partial refund of infrastructure auto-scaling costs triggered by the attack itself.

Google Cloud Armor — machine-learning-based Adaptive Protection

Google Cloud Armor's key feature is Adaptive Protection, which uses machine learning out-of-band from the main traffic flow to continuously monitor traffic and build a baseline for each application or service separately. When it detects an anomaly, the system doesn't just generate an alert — it proposes a specific, narrowly targeted filtering rule tailored to that attack, which an operator can deploy with a single click. The granular models feature lets Adaptive Protection be configured to analyze traffic per individual host or URL path, significantly reducing false positives. Cloud Armor has historically focused mainly on L7 attacks (HTTP GET/POST floods), supplemented by a separate layer of advanced network DDoS protection for L3/L4.

NETSCOUT Arbor — hybrid on-prem and cloud defense

NETSCOUT offers a hybrid model: Arbor Edge Defense runs directly in the customer's network and handles smaller attacks locally without any redirection, but once attack volume exceeds local capacity, traffic automatically shifts to Arbor Cloud — a network of 16 global scrubbing centers with over 15 Tbps of capacity. Both detection and mitigation orchestration are powered by machine learning and global threat intelligence, which the vendor says cuts mitigation time from hours to seconds. This hybrid approach is typically the choice for large enterprises and internet providers who want control over the first line of defense in their own infrastructure while still needing a safety net for extremely large attacks that exceed their own capacity.

Radware — deep behavioral analysis, including encrypted traffic

Radware builds its protection on a behavioral analytics engine that constructs a multi-dimensional model of normal traffic — not just volume thresholds, but protocol distribution, packet-size distribution, source-address entropy, geographic patterns, and application-layer characteristics. A distinctive Radware feature is behavioral TLS fingerprinting, which can spot attack patterns in encrypted (HTTPS) traffic without decrypting it — by analyzing the characteristics of the TLS handshake itself rather than the connection's content, allowing L7 "Web DDoS" attacks to be caught without compromising legitimate users' privacy or needing to handle a customer's private encryption keys.

Where DDoS protection fits into the bigger picture

DDoS mitigation is rarely deployed as an isolated tool in practice — it's typically one layer of a broader SASE architecture, combined with ZTNA for access control and WAF rules for application-layer filtering. Signals from DDoS mitigation (e.g. an unusual traffic spike from a specific geographic region) are increasingly also fed into a SIEM platform for correlation with other security events — a massive DDoS attack sometimes serves only as a smokescreen for a parallel data-exfiltration attempt happening at the same time, one that would otherwise draw attention from a team watching through EDR/XDR on its own.

Summary

DDoS attacks work because they exploit properties that were built into TCP/IP on purpose — the lack of source-address verification enabling IP spoofing, the stateful nature of the TCP handshake enabling SYN queue exhaustion, and the trusting, connectionless nature of UDP enabling reflection and amplification with a factor of up to 51,000×. Defense has since evolved into a multi-layered system — from stateless SYN cookies, through granular BGP Flowspec rules, to globally distributed Anycast networks and machine-learning-powered behavioral detection. Leading vendors differ in their specific implementation — Cloudflare builds on pure Anycast distribution, Akamai on dedicated scrubbing centers with human oversight, Radware on deep behavioral analysis — but they're all solving the same underlying problem: how to tell a million legitimate requests apart from a million malicious ones, at a moment when both groups look identical at first glance.