Understanding DDoS Attacks: How They Work and Safe Traffic Simulation

01 // Fundamentals

What exactly is a DDoS attack?

A distributed denial-of-service attack attempts to make an online service slow or unavailable by exhausting a limited resource. That resource may be internet bandwidth, packet-processing capacity, connection state, CPU, memory, application workers, database connections, or an expensive business function such as search.

“Distributed” means pressure arrives through many systems, networks, or identities rather than one obvious source. Those systems may be compromised consumer devices, rented infrastructure, or reflected traffic from misconfigured services. Legitimate users then compete with unwanted traffic and experience latency, timeouts, or errors.

Availability is the target. A DDoS incident does not necessarily imply that data was stolen or the server was breached, although defenders should never assume it is the only activity underway. Treat it as an operational and security incident until logs and evidence show otherwise.

02 // Distinction

DoS versus DDoS

The difference is not merely the number of machines. Modern defensive systems also evaluate request behavior, protocol mix, geographic distribution, fingerprints, error patterns, and the resource being exhausted.

03 // Failure layers

Three broad categories of DDoS pressure

• Volumetric attacks attempt to saturate network capacity with more bits than the path can carry.
• Protocol and state exhaustion pressure network devices, load balancers, or connection-tracking tables with excessive packet or connection work.
• Application-layer attacks resemble ordinary web or API requests but target expensive routes, limited worker pools, databases, authentication, or search.

Real incidents can combine categories and shift quickly. That is why a single rate limit at the application is not a complete strategy: traffic must be detected and filtered as far upstream as practical, while the application protects its own scarce resources.

04 // Current scale

The 2025 record wave, in context

Cloudflare reported mitigating 47.1 million DDoS attacks during 2025—121% more than the previous year, or an average of 5,376 per hour. Its largest publicly disclosed event peaked at 31.4 Tbps and lasted about 35 seconds. During a separate December campaign, HTTP attacks exceeded 200 million requests per second.

Microsoft separately reported stopping a 15.72 Tbps, 3.64-billion-packet-per-second event against one Azure endpoint in October 2025. These are provider observations, not a census of the entire internet, but they demonstrate why manual intervention alone cannot handle modern peaks. Detection and mitigation must be always-on and automatic.

Primary reports: Cloudflare Q4 2025 DDoS Threat Report and Microsoft Azure's October 2025 report.

05 // Browser-only model

Safe interactive traffic simulation

Adjust normal and modeled hostile traffic, then toggle edge filtering. The numbers illustrate relationships between attempted load, admitted load, latency, and successful responses. They are educational estimates—not measurements from a real network.

06 // Controlled validation

A bounded localhost smoke test with k6

Simulation teaches concepts; performance testing measures your own software. The script below is intentionally hard-coded to the loopback interface, ramps to only ten virtual users, sleeps between requests, and stops on excessive failures. Run it only against a local service you started yourself.

import http from "k6/http";
import { check, sleep } from "k6";

export const options = {
  stages: [
    { duration: "5s", target: 2 },
    { duration: "10s", target: 10 },
    { duration: "5s", target: 0 }
  ],
  thresholds: {
    http_req_failed: [
      { threshold: "rate<0.02", abortOnFail: true }
    ],
    http_req_duration: ["p(95)<500"]
  }
};

export default function () {
  const response = http.get("http://127.0.0.1:3000/health");
  check(response, { "status is 200": (result) => result.status === 200 });
  sleep(1);
}

Run it with k6 run localhost-smoke.js while watching application latency, CPU, memory, worker queues, database connections, and logs. A load generator shows symptoms; service telemetry explains the bottleneck. Grafana recommends starting small, correlating results with observability, defining stop conditions, and supervising risky tests.

Reference: Grafana k6 automated performance testing guidance.

07 // Layered resilience

How defenders reduce DDoS impact

• Establish a baseline. Know normal request rates, latency, errors, bandwidth, geography, and expensive routes before an incident.
• Use upstream protection. Anycast networks, CDNs, managed DNS, and provider scrubbing can absorb or discard traffic before it reaches the origin.
• Protect the origin. Restrict direct access to trusted proxies, remove exposed historical addresses, and separate administrative services.
• Apply context-aware limits. Rate-limit by route, identity, cost, and behavior—not only IP address—and return inexpensive failure responses.
• Cache and degrade gracefully. Serve static or cached content, disable nonessential expensive features, and preserve critical paths.
• Remove resource cliffs. Bound uploads, sessions, queues, connection lifetimes, retries, and concurrency; isolate dependencies and handle backpressure.
• Instrument every layer. Combine edge events, network flows, load-balancer metrics, application traces, database saturation, and customer impact.

OWASP emphasizes that denial-of-service resilience is never a one-step control. Rate limiting, caching, bounded resource use, asynchronous work, graceful degradation, and removal of single points of failure must reinforce one another.

08 // Incident response

A practical DDoS response sequence

1. Confirm customer impact. Distinguish an attack from a release failure, dependency outage, or organic traffic spike.
2. Declare the incident. Assign an incident lead, communications owner, and infrastructure contacts.
3. Engage providers early. Share timestamps, destination resources, protocols, and safe traffic samples with the CDN, host, ISP, or mitigation provider.
4. Protect critical paths. Increase filtering, reduce expensive features, enable cached responses, and preserve authentication and status communication.
5. Avoid blind blocking. Broad geographic or IP rules can remove real customers while bot traffic shifts elsewhere.
6. Preserve evidence and review. Record decisions, metrics, configuration changes, costs, false positives, and recovery time; improve the runbook afterward.

Defensive references: CISA's DDoS guidance and OWASP Denial of Service Cheat Sheet.

09 // Quick answers

Frequently asked questions

Can a CDN stop every DDoS attack?

No single service guarantees perfect availability. A CDN can absorb and filter substantial traffic, but origin exposure, application bottlenecks, provider limits, and configuration errors still matter.

Is a traffic spike automatically an attack?

No. Product launches, breaking news, crawler activity, retry storms, and software defects can produce similar symptoms. Intent and cause require evidence.

Does the simulator test my server?

No. It is deliberately disconnected. Use a separately authorized performance-testing process when you need measurements.

10 // Conclusion

Availability is an architecture property

DDoS defense is not a panic button added after launch. It begins with understanding resource limits, moving filtering upstream, designing graceful degradation, monitoring user impact, and rehearsing provider coordination.

Use the browser model to understand cause and effect. Use bounded, authorized load tests to validate your own system. Never confuse defensive learning with permission to generate traffic against someone else's service.