When attack traffic surges, websites can fail in very different ways. The network link may saturate first. Bandwidth may still be available while the connection table is exhausted. Other requests complete the handshake and reach the site over HTTPS, yet keep consuming login API and database resources.

Addressing these problems requires a DDoS-protected CDN to absorb traffic across a distributed network, identify and filter attacks at several stages, and forward permitted application requests to the origin. Terabit scale describes traffic volume; millisecond scale describes the speed of a particular response step. Both matter, but one does not stand in for the other.

CDN07 applies distributed terabit-scale protection, intelligent routing, real-time analysis, and layered filtering to website performance and security. To see how this approach works, follow a request from its entry into the protection network to its arrival at the origin.

What do “millisecond scale” and “terabit scale” actually measure?

A distributed denial-of-service (DDoS) attack uses many sources to generate traffic or requests that exhaust a target's network or computing resources, preventing legitimate users from accessing the service.

Traffic scrubbing means identifying, dropping, rate limiting, challenging, or allowing traffic as it enters the protection network. It is a continuous, inline process, not a batch operation performed after collecting all traffic.

In decimal units, 1 Tbps equals 1,000 Gbps. But a network's terabit-scale aggregate capacity, terabit-scale scrubbing resources available in a particular region, and terabit-scale protection guaranteed to one customer are three different claims.

Response time also has multiple stages: an attack begins, the system observes an anomaly, a rule is generated, edge locations enforce it, and the application returns to stable operation. These events do not happen at the same moment.

Existing rules can match subsequent traffic immediately. A new attack pattern often requires samples to accumulate and its characteristics to be assessed before the system chooses a response.

Fast enforcement and accurate classification must therefore be designed together. If a system blocks legitimate users in its rush to act, the website has not truly recovered.

Why does terabit-scale traffic require a distributed network?

If every attack packet must first cross one undersized upstream link before reaching a scrubbing server, even the fastest filtering algorithm cannot recover legitimate requests already lost to congestion on that link.

Placement matters: filter as far ahead of the application's bottleneck as practical, with enough capacity at network entry points, forwarding paths, and processing locations.

Distributed routing avoids concentrating all traffic in one place

Anycast is a common technique for distributed entry points. Multiple locations announce the same service address, and the routing system directs traffic to a corresponding location. RFC 4786 on Anycast operations also discusses node autonomy, route changes, and traffic distribution.

Anycast can spread traffic, but it does not guarantee an even load across locations or always select the geographically nearest one. Source networks, carrier routing policies, and interconnection capacity affect where traffic actually lands.

DNS-based routing can distribute entry points too, but changing DNS records does not immediately move established connections; caching and client behavior also affect when changes take effect. A large protection network may combine several routing methods, depending on its deployment.

Terabit-scale architecture therefore needs both aggregate capacity and local headroom. Spare bandwidth across the entire network does not guarantee enough capacity at an entry point facing a concentrated attack.

The same 1 Tbps can present very different processing demands

Large packets consume bandwidth. Small packets can drive packets per second sharply higher, exhausting NIC queues, CPU, or forwarding equipment first.

The following simplified Python 3 example illustrates how average packet size affects packet rate. It is not a CDN07 measurement:

attack_bps = 1_000_000_000_000  # 假设攻击速率为1Tbpsfor packet_bytes in (1500, 100):    packets_per_second = attack_bps / (packet_bytes * 8)    print(f"平均每包{packet_bytes}字节：约{packets_per_second / 1_000_000:.2f} Mpps")

The approximate output is:

平均每包1500字节：约83.33 Mpps
平均每包100字节：约1250.00 Mpps

This calculation uses average packet sizes measured at the same layer and excludes additional link overhead. It shows that equal bandwidth figures can represent vastly different packet counts.

The actual limit depends on which resource becomes the bottleneck first: bandwidth, packet-processing rate, connection-state capacity, or application throughput.

Why scrub traffic in layers after it reaches an edge location?

Running the most expensive application analysis on every packet wastes compute resources. Simple IP blocking alone, however, struggles with attacks spread across many addresses that resemble legitimate traffic.

A more efficient approach removes inexpensive-to-identify anomalies early and reserves costlier checks for connections and requests that need further analysis.

These are logical stages. A real system may run several on one edge server or distribute them among components.

Drop clearly malicious packets early

At this stage, decisions generally rely on packet properties and known traffic characteristics. Traffic using protocols the application does not need, malformed packets, or confirmed attack signatures can be filtered early.

XDP is a mechanism for early execution in Linux networking. In its published analysis of DDoS mitigation , Cloudflare describes one implementation that uses XDP and eBPF for packet filtering, passes samples to a detection system, and distributes rules after identifying an attack.

This industry example illustrates the value of early filtering: some drop decisions happen before traffic enters more expensive protocol processing. It describes Cloudflare's implementation; other networks can achieve similar functions with different components.

The full URL path and body inside HTTPS are not visible at this stage. Network-layer filtering can handle much of the basic scrubbing, but it cannot replace HTTP behavior analysis after decryption.

Validate connections before state resources run out

Establishing a TCP connection requires a handshake. Large numbers of incomplete handshakes can consume backlog and related state, preventing legitimate users from opening new connections.

RFC 4987's analysis of SYN floods and common mitigations covers SYN caches, SYN cookies, proxies, and their tradeoffs. A SYN cookie encodes necessary information in the initial response and creates corresponding connection state only after receiving a verifiable follow-up acknowledgment, reducing half-open state consumption.

Passing connection validation shows only that the sender can complete the relevant exchange. It does not prove a human is behind it. Bots can complete handshakes too, and attacks can move to established connections or HTTP requests.

Application-layer assessment is still needed after connection protection.

Assess application load at the HTTP layer

Once HTTPS is terminated and decrypted at the edge, application protection can examine URLs, request methods, headers, and relevant session information.

For example, repeated requests for a cacheable image and repeated requests to a search API requiring database work may have similar RPS figures but impose very different loads on the origin. The cost of each endpoint, caching behavior, and application flow should inform decisions.

AWS's guidance on DDoS-resilient architecture discusses global network capacity separately from web application protection: the former helps absorb traffic at scale, while the latter depends on WAF, application capacity, and anomaly detection.

In practice, login, search, downloads, and payment callbacks need different policies. Browser challenges may be appropriate for some paths but not mobile APIs. IP-only rate limits can also affect legitimate users behind shared egress addresses.

CDN07's discussion of coordinating WAF, bot management, and DDoS protection focuses on how these controls work together. Network scrubbing, bot detection, and application rules each have a role; none solves every problem by itself.

How millisecond-scale response works: separate analysis from packet-by-packet enforcement

One important design principle is to separate deciding what action to take from enforcing that action on live traffic.

The part that receives traffic and matches, drops, or forwards packets is the data plane. The part that analyzes samples, adjusts policy, and distributes rules is the control plane.

The data plane needs a short, predictable processing path. Once deployed, rules should run locally at the edge rather than waiting for a remote analytics system to answer for every packet.

The control plane can consider more signals: changes in packet rate over short windows, handshake completion, how concentrated requests are, and departures from normal application baselines. Once it confirms a pattern, it can send enforceable rules to the data plane.

This division creates two time scales. Existing rules can be enforced continuously and quickly. Recognizing a new attack requires observation and a decision. The time spent on the first process is not the full response time of the second.

AI analysis is useful for detecting combinations of anomalies

A single threshold creates a difficult tradeoff. Set it too low and a promotion or game launch may block legitimate users. Set it too high and the origin may be overwhelmed first.

Intelligent analysis can combine signals to find traffic that looks ordinary on individual measures but abnormal as a whole. The model's output still needs to become a specific action: rate limit a costly class of requests, adjust concurrency on a path, or challenge traffic with particular risk characteristics.

Automation also needs an exit path. Temporary rules should have expiration and rollback conditions so restrictions can be lifted progressively after the application recovers, rather than continuing to affect users after the attack ends.

Millisecond-scale enforcement, continuous learning, and reversible policy changes together determine whether protection is both fast and stable. An “AI score” alone does not replace this chain.

Why control cache and origin requests after scrubbing?

The preceding stages reduce attack traffic, but the origin may still face capacity pressure. A surge of legitimate users, anomalous traffic that passes filtering, and large numbers of cache misses can continue to consume backend resources.

Serve eligible content at the edge instead of fetching it repeatedly

Images, scripts, and public pages that qualify for caching can be returned from edge cache. This shortens the delivery path and reduces repeated origin fetches.

But caching must respect application permissions. Under RFC 9111's HTTP caching rules , an unqualified private response directive prevents a shared cache from storing the response. Personal data after login, orders, and similar content need access-aware caching policies; they should not all be made publicly cacheable to reduce load.

Investigate cache misses, too. Arbitrary query parameters can create many distinct cache objects. But if a parameter actually determines the product, language, or user authorization, ignoring it can return the wrong content. Design cache keys around the application's meaning.

Match origin request limits to actual application capacity

Before scrubbed traffic reaches the origin, connection reuse, concurrency controls, and request coalescing where appropriate can reduce short-lived spikes. Check whether the service supports these features and how they are enabled.

For the origin, request count alone is not enough. Each request also consumes CPU, database connections, and time in external services. Costly APIs need their own capacity boundaries rather than thresholds copied from static files.

Traffic must pass through the protection entry point. If attackers target an exposed origin IP directly, CDN rules cannot process that bypass path. Check historical DNS records, overlooked subdomains, and access restrictions using our guide to protecting an exposed origin IP .

How do the layers work together during a mixed attack?

Suppose a game event page faces three pressures at once: a flood of network-layer packets, abnormal traffic repeatedly opening connections, and HTTP requests hammering the login API. This is an illustration of the mechanisms, not a real attack record.

Distributed entry points first absorb traffic reaching the protection network. Packet filters drop confirmed malicious packets, while connection management limits how much invalid handshaking consumes state. Requests that complete HTTPS exchanges then undergo application-layer assessment.

Public images and scripts on the event page are served from cache, while the login API uses separate rules. Even if aggregate attack bandwidth falls, a growing login queue means the incident is not over. Continue watching endpoint load and legitimate user success rates.

Conversely, if legitimate users increasingly fail to log in as the number of blocked requests rises, check whether the rules are too broad. Scrubbed traffic volume alone is not a measure of success.

Layered protection handles each type of pressure at an appropriate point instead of leaving all of it for the application server.

How does CDN07 apply distributed protection to real applications?

CDN07's DDoS-protected CDN combines website performance acceleration with DDoS protection and offers configurable edge coverage, bandwidth, and security policies. For an application, these capabilities should serve one goal: legitimate users can still browse, log in, and complete transactions during an attack.

An international website serving users in Mainland China needs to consider both the user-to-edge and edge-to-origin network paths. Dynamic APIs require particular attention to authentication and endpoint capacity. Long-lived connections also need monitoring for continuity and reconnection behavior. Even with the same mitigation bandwidth, different workloads call for different policies.

Capacity planning must distinguish a network's aggregate protection resources from the specific coverage of the chosen plan. The proposal should spell out what happens when an attack exceeds agreed limits, whether capacity can expand during a sustained attack, and how additional charges are calculated. Our guide to DDoS-protected CDN plans and additional costs explains these distinctions.

Assess technical results in three areas:

P95 and P99 reveal the slower portions of the latency distribution. Comparing conditions before, during, and after an attack is more informative than a single snapshot of average response time.

Measuring millisecond-scale behavior requires sufficiently precise, time-synchronized event records. Minute-granularity monitoring charts show trends, not individual response times. If you need to validate protection, coordinate an authorized test with the relevant teams; do not launch unplanned attack traffic at a production service.

Frequently asked questions

Does millisecond-scale DDoS scrubbing mean the entire attack ends in a few milliseconds?

No. Scrubbing is continuous and may need to continue as long as the attack lasts. A millisecond-scale claim should identify the particular detection, rule-enforcement, or response step. It is not automatically the recovery time for the whole incident.

Does terabit-scale bandwidth stop every HTTP flood?

No. An application-layer HTTP flood can consume little bandwidth while repeatedly triggering database work, logins, or searches. Handling it requires application-layer detection, endpoint rate limits, and controls aligned with origin capacity.

Will traffic scrubbing slow down the website?

It can add processing overhead, and challenges can add user interaction. A well-designed architecture reduces unnecessary costs through early filtering, local enforcement, and caching. Measure the effect using legitimate user success rates and latency, not only whether the scrubbing location is online.

Can SYN cookies tell humans from bots?

No. They primarily mitigate certain forms of half-open connection-state exhaustion. Bots that complete handshakes can still launch application-layer attacks and need further detection.

Do I still need a DDoS-protected server after deploying a DDoS-protected CDN?

It depends on origin exposure, network-layer risks, and application protocols. A CDN primarily protects traffic through its proxy entry point. Public direct access to the origin, separate game ports, or other entry points need their own appropriate protection.

Why hasn't the application recovered after attack bandwidth dropped?

Application-layer attacks may still be running, or the database, thread pool, or task queue may already have a backlog. Evaluate mitigation alongside legitimate request success rates and origin recovery; lower inbound attack bandwidth is not the only sign that an incident is over.

The technical value of a DDoS-protected CDN lies in the entire processing path: a distributed network absorbs traffic, rapid rule enforcement cuts wasteful load, application protection safeguards critical endpoints, and caching and origin controls preserve backend capacity.

If you are planning protection for a website, API, or event workload, share target user regions, protocols, normal peaks, origin capacity, and available attack records through CDN07 technical consultation . When protection is matched to actual application load, terabit-scale capacity and fast response can translate into availability that users can experience.