RockCloud vs SuDun: how to judge an anti-DDoS CDN
Both serve the Chinese-speaking market, but the difference is not the headline mitigation number — it is how the stack is built and how much you can do yourself once an attack lands. RockCloud combines a purpose-built DPDK scrubbing plane, Anycast absorption and AI behavioural detection with a console where rules apply in seconds and every request decision is visible, backed by a 113-strong engineering team on 24/7 direct contact. Here is what each of those choices actually solves.
Start a free 24-hour trialCapability comparison
| Dimension | RockCloud | SuDun (typical category practice) |
|---|---|---|
| Scrubbing architecture | In-house DPDK data plane handling small packets at line rate — 7T+ network-wide, 3 Tbps per IP | Commonly built on the standard kernel stack, where CPU saturates before the pipe does |
| Network design | Anycast announces one IP from 3,000+ nodes, so attacks are absorbed close to their source | Traffic is typically diverted to a scrubbing centre — its uplink becomes the ceiling, and users detour with it |
| CC detection | Game Shield AI models behaviour and blocks within three seconds, with far fewer false positives | Mostly static rules on UA, IP ranges and rate thresholds — tighten and you block humans, loosen and you let bots through |
| Console capability | Self-service visual rule editing, pushed network-wide and live within seconds of saving | Limited console scope; most policy changes go through a ticket and wait for a human |
| Observability | Per-request logs with the verdict and action taken, plus exportable attack timelines for post-mortems | Usually an aggregate protection graph; incident detail has to be requested from support |
| Acceleration and mitigation | CN2 acceleration and terabit scrubbing on one path — one onboarding, one bill | Acceleration and mitigation often sit on separate paths, adding a hop, latency and a second invoice |
| Service standards | Written SLA, transparent billing, full audit trail on tickets and config changes, 24/7 direct engineering contact | Response times and credits are often verbal commitments with incomplete change records |
Four engineering choices you feel the moment an attack lands
None of them matter on a quiet day. All of them matter in the forty minutes an attack is live.
A DPDK data plane, because small packets break things first
The hard part of DDoS is not the gigabits, it is the packet rate. SYN floods and UDP reflection are won or lost on packets per second, and every packet crossing the Linux kernel stack costs an interrupt, a context switch and several memory copies. CPU saturates long before the pipe does, legitimate requests stall alongside the attack, and your bandwidth graph still looks fine. Our scrubbing tier is built on DPDK: it bypasses the kernel and drives NIC queues directly from user space with polling and zero copy, so a single box absorbs a small-packet flood at line rate and drops it before it ever reaches your application path. That is what 7T+ of network capacity and 3 Tbps per IP rest on.
Anycast, so the attack dies closest to where it starts
The conventional model diverts attacked traffic to a scrubbing centre, which means every attack source in the world converges on one entry point and that facility’s uplink becomes your hard ceiling. Your real users are diverted too, and their latency jumps immediately. We announce the same IP via Anycast from 3,000+ nodes, so BGP pulls attack traffic to the node nearest each source and it is scrubbed in parallel, fragmented by design rather than by effort. Legitimate visitors enter at the same nearby edge, with acceleration and scrubbing on one path. The more distributed the botnet, the better this architecture performs — and users never feel a diversion.
Behavioural AI that separates people from scripts in three seconds
The real difficulty in CC mitigation is not blocking traffic, it is blocking the wrong traffic. Rule-matching leans on static signals — user agent, IP range, rate thresholds — and an attacker rotates the UA, buys a proxy pool, throttles under the threshold and walks straight through. Tighten the rules and the first casualties are real customers: a site-wide CAPTCHA and a visible drop in conversion. The Game Shield AI engine judges behaviour instead: request sequencing, timing rhythm between actions, parameter distribution, how connections are held open. A script can forge every header and still not move like a person. Detection and blocking complete within three seconds, and only anomalous sessions are touched.
A console that lets you change a rule without opening a ticket
During an incident, the slowest component is usually process, not mitigation. Adding a rate limit to your login endpoint should take a minute; instead it takes a ticket, a queue and a support handover, and half an hour later the attack window has already done its work. Our console hands that control back: protection rules are edited visually, go live network-wide within seconds of saving, and need no human in the loop. Real-time logs show the verdict and action for individual requests, and every incident leaves a complete timeline — start and end, attack type, peak, blocked volume, rules matched — exportable for a post-mortem and for the write-up your management and customers will ask for.
Why customers switch to RockCloud
The reasons we hear most often, almost always after one real incident.
- Waiting on a ticket during an attack — rule changes queued for a human while the attack window lasted forty minutes; now rules are self-service and live in seconds.
- No visibility into what actually happened — a single aggregate graph saying "protected" cannot tell you the peak, the vector, how much was blocked or whether real users were caught.
- Tightening CC rules kept blocking real customers — site-wide CAPTCHAs and whole corporate NAT ranges dropped; behavioural detection only acts on anomalous sessions.
- Acceleration and mitigation ran as two paths and two invoices — an extra hop, stacked latency, and two vendors pointing at each other when something broke.
- SLA and billing were never written down — overage terms, credit levels and who changed what were verbal, and verbal is worthless when you need accountability.
Switching takes four steps
No application changes, validate in parallel, and one DNS record away from rolling back.
Map the current setup
Share your domains, cache and origin rules, plus the type, peak and timing of recent attacks, and we design the protection policy around them.
Free 24-hour trial
Run a low-traffic hostname or one region alongside production and test hot-applied rules, live logs and attack timelines on your own real traffic.
Full cutover
Repoint the main CNAME — effective network-wide in five minutes. Leave the old configuration in place so rollback stays instant and users notice nothing.
Lock the origin and set a review cadence
Rotate the origin IP, allow only our fetch ranges, and fold attack timelines into a regular review so policy keeps tightening over time.
Anti-DDoS CDN selection FAQ
Three things, all of which you can verify yourself during a trial. First, the scrubbing architecture: purpose-built data plane or off-the-shelf, capacity per IP and network-wide — ours is DPDK-based, 7T+ overall and up to 3 Tbps on a single IP. Second, how CC traffic is identified: pure rule matching either leaks or over-blocks under a real attack, so ask whether there is behavioural modelling. Third, console and service standards: can you change rules yourself, how fast do they apply, can you inspect incident detail, is there a written SLA. Then run a free 24-hour trial on your own traffic — far more reliable than a spec sheet.
False positives almost always come from threshold rules: you lower the rate limit to stop the attack and the first casualties are power users, everyone behind a corporate NAT egress and your app’s batched API calls. We replace static signals with behavioural ones — the Game Shield AI engine models request sequencing, timing rhythm and connection handling, acts only on anomalous sessions, and completes detection within three seconds, so normal users never see a CAPTCHA. If something legitimate is still affected, real-time logs pinpoint the exact rule that matched and a precise allow rule fixes it in seconds.
Yes, request by request and fully retrospective. The console provides live logs and an attack timeline: start and end time, vector (SYN flood, UDP reflection, HTTP CC and so on), peak bandwidth and packet rate, blocked request volume, the rules that matched and the action taken — all viewable and exportable. That means you can run your own post-mortem, decide whether policy needs tuning, and produce a record your management and customers can follow, instead of a single line saying you were protected.
Self-service, hot-applied within seconds, no ticket and no queue. Every protection control — rate limiting, precise access rules, geo and IP allow/deny lists, origin and cache policy — is edited visually and pushed to every node the moment you save. This matters most mid-incident: you need that endpoint tightened now, not after a support round-trip. For more involved policy combinations our 24/7 engineering team will get on a call and tune it with you, but the controls stay in your hands.
Yes, a written service level agreement covering the availability commitment, incident response and restoration targets, credit levels and how to claim them — see the Service Level Agreement page. Billing is equally explicit: bandwidth and protection tiers, how overage is calculated and how invoicing works are all stated before you sign, not explained afterwards. Tickets and configuration changes carry a full audit trail, so if there is ever a dispute both sides are reading the same record.
A standard anti-DDoS CDN targets HTTP/HTTPS sites and APIs: layer-7 acceleration plus scrubbing, where cache hit ratio and origin policy carry the weight. Game Shield targets real-time workloads on persistent connections and custom TCP/UDP protocols — games, card and board titles, IM — where jitter is punishing, a single disconnect becomes a complaint, and attacks often target specific players or a launch window. It adds distributed mitigation-node scheduling, real server IP concealment and AI behavioural detection, with player latency as low as 30 ms. A public site and a game backend can run side by side under one console.
Still haven't found what you're looking for? Talk to our team.
Third-party trademarks belong to their respective owners. Products and pricing may change — refer to the latest official information.
Skip the spec sheet — run your own traffic through it
Tell us your workload, your recent attack history and what you run today, and we will open a free 24-hour trial so you can test the console, the live logs and the mitigation yourself.