同一个防护配置，套在不同业务上效果可能天差地别：游戏被打的是 pps 和延迟，直播被打的是带宽，下载站和商城被打的是连接数与动态接口。本文用 9 个问答讲清这三类业务的 DDoS 攻击特征、判断方法和分层防护重点，帮你在有限预算下把防护装到刀刃上。
Q：为什么同一套防护在不同业务上效果差这么多？
- 因为攻击面完全不同，防护资源必须匹配业务的瓶颈所在。
- 看三个维度就能定性：业务协议（UDP 实时流、TCP 长连接、HTTP 短连接）、用户对延迟的容忍度（游戏十几毫秒就掉线，网页慢两秒还能忍）、单用户资源占用（一个下载用户能占满几十兆带宽，一个网页用户只占几 KB）。
- 最容易踩的坑：把网页用的
limit_req直接套到游戏服，真实玩家会被当场限掉；反过来，对带宽型攻击只做频率限制则完全无效。
Q：游戏业务被打的典型形态有哪些？
- 常见四类：登录服与匹配服被打（四层 SYN Flood 叠加七层接口请求）、战斗服 UDP Flood（小包高频，带宽看着不高，pps 却能上千万）、掉线与回档（延迟抖动、连接被重置）、畸形包与协议攻击（伪造游戏协议打崩逻辑处理）。
- 先确认是带宽型还是小包型，因为两者的防护选型完全不同：
# 带宽与 pps 一起看：有些攻击带宽只有几百兆，pps 却高得离谱
sar -n DEV 1 5 | grep -E 'IFACE|eth0'
# 抓一段包看包长分布与协议占比（小包攻击平均包长通常远低于正常业务）
tcpdump -i eth0 -nn -c 2000 -w attack.pcap
tcpdump -r attack.pcap -nn | awk '{print $5}' | awk -F. '{print $NF}' | sort | uniq -c | sort -rn | head
# 看防护规则的包计数增长速度，判断是否被持续打
iptables -L INPUT -v -n | head -20- 防护重点：入口必须上四层高防或游戏盾，选型按 pps 与新建连接数衡量，不能只看 Gbps；源站只放行回源网段；战斗服的 UDP 流量需要清洗设备支持 UDP 特征识别，只做 TCP 清洗毫无意义。
Q：直播和视频业务的防护重点是什么？
- 直播是被 DDoS 打起来最直接的一类：只要出口带宽被塞满，所有观众立刻卡顿，攻击者甚至不需要打应用层。
- 推流地址泄露同样致命：别人拿着你的推流密钥往源站推垃圾流，一样吃满带宽，日志里还像「正常推流」。
- 防护重点有两件事：拉流走 CDN、推流入口做鉴权。
# 源站只接受指定推流 IP，其他来源直接拒绝
location /live/push {
allow 203.0.113.10;
allow 203.0.113.11;
deny all;
return 403;
}
# 回源只允许 CDN 回源段（网段请替换为实际值）
location / {
allow 198.51.100.0/24;
deny all;
proxy_pass http://origin_backend;
}- 补充两条：推流密钥定期轮换并按流隔离带宽配额；拉流域名与推流域名分开，别让同一域名同时承担两种角色。
Q：下载站和商城的攻击面又有什么不同？
- 下载站的特点是大文件、单用户高带宽占用，攻击者只要并发请求几个安装包就能把出口占满，形态上更接近流量盗刷而不是典型 CC。
- 商城的特点是动态接口密集：搜索、筛选、加购、下单都要查库，四层攻击还会同时打满连接跟踪表，导致新连接被直接丢弃、连 SSH 都进不去。
- 先看清楚是「带宽被占」还是「连接被打满」：
# 单 IP 并发连接 TOP（下载站被打时通常能看到极不均匀的分布）
ss -ant state established '( sport = :80 or sport = :443 )' \
| awk 'NR>1 {print $5}' | cut -d: -f1 | sort | uniq -c | sort -rn | head -20
# 连接表与半开队列是否接近上限
ss -s
conntrack -C 2>/dev/null || echo "conntrack 命令不可用"
dmesg | grep -i 'table full' | tail -5- 防护重点：下载站把大文件全部交给 CDN 与对象存储，源站只保留鉴权接口，并对下载路径限速限并发；商城把搜索、下单这类动态接口单独限流，并给核心链路预留资源。
Q：怎么快速判断是 DDoS、CC 还是业务自身的问题？
- 三个量同时看，缺一个都会误判：带宽（Mbps）、pps、连接数。只看带宽会漏掉小包型攻击，只看 QPS 会漏掉四层攻击。
sar -n DEV 1 5 | grep -E 'IFACE|eth0' # 带宽与包速率
ss -s # 连接状态总览
netstat -s | grep -i -E 'overflow|drop|reset' # 内核丢弃与溢出计数
ss -ant state syn-recv | wc -l # 半开连接堆积- 判据：带宽或 pps 异常且来源分散，基本是 DDoS；带宽正常、应用 CPU 高、来源集中在少数 IP，更像 CC；带宽与连接都正常但数据库慢查询暴涨，那是应用层或缓存问题，别急着封 IP。
- 这三层结论决定你该找 CDN、找高防厂商还是找开发改代码。
Q：预算有限时，防护优先级怎么排？
- 按「先减少暴露面，再顶住流量，最后精细化拦截」的顺序排，五步走。
- 第一步，隐藏源站 IP：对外流量走 CDN 或高防，源站只放行回源段。这一步不花钱但收益最大，源站 IP 泄露等于所有防护归零。
- 第二步，接四层高防：顶住流量型攻击。选型看清洗容量、pps 处理能力和新建连接速率，不能只看标称 Gbps。
- 第三步，上七层防护：游戏用游戏盾，网站用 WAF 加 CC 防护，覆盖四层漏过来的应用层请求。
- 第四步，静态与流媒体交给 CDN：减少源站直接暴露的路径，也摊薄带宽成本。
- 第五步，监控与预案：没有监控的防护是盲防，没有预案的防护临场必乱。
Q：监控和告警要看哪些指标？
- 通用五项：出口带宽、pps、新建连接速率、活跃连接数、源站 5xx 比例。
- 业务专属项：游戏看延迟、丢包与掉线率；直播看推流断流与观众卡顿率；下载站看单 IP 下载并发与出向流量；商城看下单成功率与接口耗时。
# 状态码分布：5xx 突增往往先于业务告警触发
awk '{print $9}' access.log | sort | uniq -c | sort -rn | head
# 每 10 秒取样一次 pps，便于对齐攻击时间点
sar -n DEV 10 30 | grep eth0- 阈值设置两条原则：必须有近 14 天同时段的基线（否则夜间低峰的正常值会被当成攻击）、优先用双条件告警（如带宽超过基线 150% 且 pps 同时超基线 200% 才报警），能显著减少误报。
Q：应急预案里必须写清哪些内容？
- 预案不是一句「攻击时联系服务商」，至少包含五项：触发条件（什么指标到什么值启动）、决策人与升级路径、处置动作顺序（先切清洗还是先降级）、降级档位（哪些功能先关）、对外口径（客服话术、公告模板）。
- 再加上最容易被跳过的一条：恢复与复盘——什么时候解除限流、如何确认没有残留临时规则、事后怎么调阈值，都要落在纸面上。
- 判断预案好不好用只有一个标准——演练过；没演练的预案，第一次用基本都会出问题。
Q：还有什么补充建议？
- 把攻击挡得离源站越远越好：能在 CDN 或高防节点解决的问题，不要留给源站服务器，源站每多处理一个恶意请求都是在浪费业务资源。
- 把源站 IP 当机密管理：DNS 历史记录、邮件头、证书透明度日志、测试域名都可能泄露源站，定期自查直连是否可达。
- 三类指标一个都不能少：带宽、pps、连接数。小包攻击打 pps，带宽型攻击打出口，连接耗尽型攻击打连接表，漏一个就有一类攻击看不到。
- 按业务而非按价格选防护：游戏认 pps 和清洗能力，直播认带宽冗余，下载站与商城认连接数和七层规则，买的和用的对不上，花了钱也扛不住。
- 一句话总结：游戏的命门是 pps 与延迟，直播的命门是带宽与推流鉴权，下载站和商城的命门是连接数与动态接口——先认清自家业务吃哪一口，再决定装什么防护。