In the Hong Kong DDoS protected server market, terms like "unlimited upgrades," "unlimited protection," and "unlimited attack limits" are used, seemingly implying that purchasing such services guarantees protection against DDoS attacks. However, "unlimited protection" does not equate to "never missing a defense." The underlying elastic scrubbing capabilities and SLA commitments are the true keys to determining the quality of protection.

What is "unlimited protection"? What does it actually protect against?

"Unlimited protection" typically refers to an elastic billing or elastic scrubbing model, not unlimited physical capacity. Its core technical logic is: the service provider builds a large-scale distributed scrubbing cluster (potentially reaching Tbps levels). When a customer is attacked, the scrubbing system automatically allocates more resources for defense, and the customer pays based on the actual scrubbing volume or enjoys the "unlimited" upgrade benefits included in the package.

However, please note three technical limitations:

First, physical limits objectively exist. Any scrubbing cluster has a total capacity limit, such as 5Tbps. If multiple large customers simultaneously suffer massive attacks, exceeding the cluster's capacity, resource contention may still occur. True "unlimited protection" is actually "allocating resources on demand within the cluster's capacity, with best-effort usage for any excess capacity."

Second, strong scrubbing capabilities do not equate to complete protection. Missed protection refers to attack traffic bypassing scrubbing or incomplete scrubbing, allowing a small amount of malicious traffic to still penetrate to the origin server. This is often not a capacity issue, but rather a problem with the accuracy of the scrubbing algorithm—for example, new types of reflection amplification attacks, encryption attacks, and slow attacks, which traditional fingerprint databases may not be able to identify in time.

Third, link bandwidth remains a bottleneck. Even if the scrubbing cluster has terabit-level capacity, if the customer's access bandwidth is only 1Gbps, attacks exceeding 1Gbps will still clog the access link—this has been explained in detail in the previous article. Unlimited protection cannot physically overcome bandwidth limits.

Therefore, "unlimited protection" is essentially a commercial flexibility commitment. Its core value lies in the fact that you don't need to purchase a fixed, high-cost defense bandwidth in advance; it automatically expands when an attack occurs, and you are charged based on actual usage or receive free upgrades within the package. This is very user-friendly for those with fluctuating business operations and uncertain attack scales, but it is by no means a technical guarantee of "absolute invulnerability."

Elastic Scrubbing Capabilities: The Technical Foundation of Unlimited Protection

Elastic scrubbing capabilities are the technical foundation for the implementation of "unlimited protection." A mature DDoS protected system typically employs a distributed scrubbing node + Anycast redirection + dynamic traffic scheduling architecture.

1. Distributed Scrubbing Cluster

Scrubbing nodes are deployed across multiple data centers globally, each with local scrubbing capacity ranging from hundreds of gigabytes to several terabytes. These nodes are interconnected via a backbone network, forming a scrubbing resource pool.

When an attack is detected on an IP address, the system uses BGP routing policies to redirect the attack traffic to the nearest scrubbing node. If that node is overloaded, it will further redirect traffic to other idle nodes. The elasticity is reflected in the system's ability to automatically allocate 1, 5, or even 20 nodes to participate in scrubbing simultaneously based on real-time attack volume, thereby aggregating a total scrubbing capacity far exceeding the capacity of a single node.

2. Dynamic Cleaning Algorithm

The cleaning device is not a simple "packet dropper," but achieves accurate identification through a combination of technologies:

- Behavioral Baseline Learning: Building a model of normal business traffic (packet rate, connection count, protocol distribution, etc.)

- Fingerprint Feature Recognition: Matching packet characteristics of known attack tools (e.g., specific TTL values, window sizes, etc.)

- Source Verification Challenge: Initiating verification of suspicious traffic (e.g., SYN cookies, HTTP redirects)

- Machine Learning Classification: Real-time decision on whether traffic is malicious

The flexibility is reflected in the fact that when attack methods change, the algorithm model can be retrained and deployed within minutes, rather than relying on a fixed rule base.

3. Elastic Scaling of Cleaning Capacity

If attack traffic exceeds the physical port capacity of a cleaning node (e.g., 400G per node), the system will distribute the traffic to multiple nodes. Each node processes a portion, ultimately achieving a total cleaning capacity equal to the sum of the capacities of all nodes.

Theoretically, as long as the total cluster capacity is sufficient, attacks of any scale can be cleaned—this is the technical source of "unlimited defense." However, please note that cross-node traffic splitting and forwarding introduces additional latency (typically 5-20ms) and requires business protocol support (e.g., TCP Anycast is effective against SYN Flood, but may have out-of-order issues for UDP attacks).

Why does "unlimited protection" still sometimes fail to detect attacks?

Attacks failing to detect attacks (i.e., attacks passing through) mainly occur in the following four typical scenarios:

Scenario 1: The cleaning algorithm fails to identify new types of attacks

Attackers use zero-day DDoS techniques, such as QPack dynamic table compression attacks based on HTTP/3, or amplification through CDN/WebSocket tunnel reflection. The cleaning device's fingerprint database has not yet included these attacks, potentially misclassifying them as normal traffic. In this case, even a large capacity is ineffective—identification capability is crucial.

Scenario 2: Application layer attacks bypass L3/L4 cleaning

CC attacks (such as slow POST requests or high-frequency requests with random parameters) have traffic characteristics highly similar to normal users, and the total bandwidth is very small (possibly only 10Mbps), so they will not trigger the large-volume cleaning threshold. Attack requests directly reach the origin web server, consuming CPU and database connections. This situation requires a dedicated WAF and rate limiting module; the "basic scrubbing" of Hong Kong DDoS protected servers may not cover it.

Scenario 3: Residual Attacks After Scrubbing

Even after scrubbing, a small number of malicious packets may still slip through. For example, some TCP reflection attacks cannot be distinguished between reflected packets and normal responses by the scrubbing equipment, resulting in connection table corruption. If the proportion of residual attacks exceeds the business tolerance threshold, it manifests as a "breach."

Scenario 4: Link Bottlenecks Cause Scrubbing Failure

As repeatedly emphasized: if the access bandwidth is less than the attack traffic, the scrubbing equipment will not receive the complete traffic. Although service providers may claim "elastic scrubbing with automatic scaling," the physical bandwidth of the last mile (from the server's network card to the switch) is fixed, making scaling meaningless.

SLA Commitment: Putting "Unlimited Protection" on Paper

Verbal promises of "unlimited protection" from service providers have no legal effect. What truly protects customer rights is the SLA (Service Level Agreement). A rigorous high-defense SLA should quantify the following key metrics:

1. Availability

Typically, it promises a 99.9% to 99.99% availability rate for the scrubbing system. Calculation: Monthly downtime = Duration of scrubbing functionality failure during an attack. Note: Should the service interruption caused by the attack, even if the scrubbing system itself is functioning normally, be included? This needs clarification.

2. Efficacy

It promises the percentage of attack traffic that is passed through after scrubbing, such as "Attack traffic scrubbing rate ≥ 99%" or "Residual attack traffic ≤ 1%". Some vendors may use "effective blocking rate" to describe this. This metric directly addresses the issue of "missed protection".

3. Time to Mitigate

The time interval from the start of the attack to the effective scrubbing, typically promised to be ≤10 seconds or ≤30 seconds. The slower the start-up, the more severe the service disruption.

4. False Positive Rate

The percentage of legitimate user requests mistakenly blocked. Our premium defense service promises ≤ 0.01%. A high false positive rate is equivalent to attacking your own users.

5. Elastic Scaling

When an attack exceeds the currently allocated defense capacity, the system automatically increases the response time of the cleaning resources, and provides a scaling limit description (e.g., "A single customer can enjoy a maximum of 5Tbps of cleaning capacity").

6. Compensation Mechanism

Compensation for failing to meet SLA targets is typically a service fee deduction (e.g., 10%-100% of the monthly fee). Carefully review the disclaimers (e.g., force majeure, customer violations, etc.) and compensation limits.

Selection Recommendations: How to Properly View "Unlimited Defense"?

Based on the above analysis, here are three practical suggestions:

Unlimited defense is suitable for fluctuating businesses, but it does not equal absolute security. If your business experiences drastic changes in attack scale (e.g., game launches, e-commerce promotions), the elastic billing model of unlimited defense is very cost-effective. However, you still need to focus on the cleaning algorithm capabilities and application-layer protection, and add a WAF if necessary.

Prioritize requesting the "cleaning effectiveness" clause in the SLA. Does the service provider dare to promise a cleaning rate of over 99%? Are they willing to include this in the contract? This is key to measuring the true level of their technology. Avoid vendors that only talk about "unlimited capacity" without mentioning "cleaning quality."

Test the vulnerability rate of unlimited protection. Utilize free testing opportunities to launch mixed-type attacks (high-volume UDP attacks + slow CC attacks), while monitoring whether the origin server is still receiving abnormal traffic. If business latency increases or a few erroneous requests occur during the attack, this is normal; if there are obvious connection denials or database crashes, it indicates serious vulnerability.

Unlimited protection addresses "capacity" elasticity, while the cleaning effectiveness and false positive rate in the SLA address the "quality" baseline. A qualified elastic high-defense product should be a trinity of "unlimited scalability + quantifiable commitment to cleaning quality + evidence-based compensation for vulnerability breaches." Those that only emphasize the former while avoiding the latter two essentially transfer the risk to the user. When making a purchase, please keep your eyes open and make sure that every promise is written in black and white in the contract.