抗DDoS攻击测试：攻击拦住了，业务就一定没事吗？——业务流量叠加攻击下的防护验证方法

做抗DDoS攻击测试时，大家最先看的通常是Gbps和PPS：攻击打多大，设备拦住了多少。

可到了现场，客户问得更直接：攻击起来以后，网站还能不能打开？DNS还能不能解析？正常用户会不会被一起拦掉？

这时候，单看攻击侧报表就不够了。攻击被清洗，不等于业务没有受影响。

攻击压力当然要有。压力不够，设备边界测不出来。但攻击侧统计只能说明设备处理了多少异常流量，不能说明用户是否还能正常访问业务。

有些问题并不会出现在清洗数字里：合法连接被重置、DNS查询被误判、HTTP响应明显变慢。策略松了，攻击可能穿透；策略紧了，正常请求又可能被误伤。

再加上网络层攻击、应用层攻击和正常访问可能同时出现，只测一种攻击，结果往往比真实情况更乐观。

图1  只看攻击侧与同时观察业务侧的差异

方法并不复杂。攻击开始前，先让正常业务跑稳，记下成功率和响应时间；随后逐步增加攻击压力，不要一上来就拉到峰值；攻击期间，业务持续运行，一直观察到攻击停止并恢复。

真正值得盯住的，是攻击前后业务怎么变：有没有瞬时抖动，防护生效后是否稳定，攻击结束后能不能及时恢复。业务没有完全中断，也不代表没有问题，时延升高和偶发失败同样要查。

图2  业务指标应覆盖攻击前、攻击中和攻击后的完整过程

测试节奏可以拆成四段：先建立稳定基线，再逐步加压，随后保持一段时间，最后停止攻击并观察恢复。这样做的目的不是把流程写复杂，而是分清问题发生在策略切换的一瞬间，还是持续压力下逐渐累积。

记录结果时，攻击压力、防护动作和业务指标最好使用同一条时间轴。否则只能看到“业务抖过一次”，却很难判断它发生在攻击启动、策略生效还是压力回落阶段。

网络层攻击更看重吞吐、PPS和报文构造；应用层测试更依赖协议交互、会话状态和服务端响应。两类流量分开跑不难，难的是把它们和正常业务放到同一个场景里。

一种常见做法是：Renix负责L2-3层的高吞吐、高PPS压力；ALPS负责L4-7层的正常业务仿真，也可以构造应用层攻击。这样，攻击侧和业务侧使用同一条时间线，结果才对得上。

图3  Renix与ALPS组合测试的通用方法示意

图中只画了方法，没有展开具体组网。实际场景里，流量怎么配、协议怎么组合、观测点放在哪里，都要结合设备、部署方式和业务模型重新设计。

Renix和ALPS放在一起，并不是简单地“一个发攻击、一个跑业务”。攻击流量、应用交互和正常访问沿同一条时间线运行后，设备什么时候开始识别、业务什么时候出现波动、策略调整后有没有恢复，才有机会一一对应。

组合之后还有一个容易被忽略的好处：场景可以重复。设备换了、策略改了，仍然用相同的业务模型和攻击节奏再测一次，前后结果才有可比性。对选型、调优和验收来说，这往往比单次跑出一个峰值数字更有用。

当然，工具不会替项目做决定。网站、DNS、API或其他业务，各自关心的成功率、响应时间和可接受波动并不一样。测试前先把这些问题问清楚，再决定协议、流量比例和压力节奏，产品能力才能真正落到业务场景里。

只看平均值。短时间的失败或时延尖峰，很容易被全程平均数抹平。除了平均结果，还要保留攻击启动、策略生效和攻击停止前后的变化。

只确认有流量。端口上有收发，不等于业务真的成功。还要确认连接或会话是否完成、返回状态是否正常，以及服务端是否持续响应。

攻击与业务各看各的。两套结果的时间对不上，出现异常时就很难区分是攻击穿透、防护策略误伤，还是后端业务自身波动。

以一组典型时序为例：

背景流量先在1分钟内完成爬升，随后稳定运行2分钟，第3分钟开始叠加攻击；攻击持续30分钟后停止，背景流量继续运行30分钟，至第63分钟结束。

这里关注的不是某个绝对数值，而是三个阶段之间的连续变化。

正常情况下，背景流量在第1分钟达到目标水平，并在第1至第3分钟保持稳定。攻击开始后，总流量再次爬升并形成相对稳定的高位平台；第33分钟停止攻击后，总流量应回落到攻击前的背景水平，并稳定保持到测试结束。

图4 典型抗D测试场景总流量曲线（示意）

1. 背景或切入阶段异常。

若背景平台不稳，或攻击切入时总流量跌破原背景线，可优先排查：

①防护策略切换是否误伤合法业务；

②连接跟踪或会话表是否被快速占满、重置；

③入口、出口接口队列是否拥塞或丢包；

④后端服务连接池、处理线程是否出现瓶颈。

2. 高位平台异常。

若攻击阶段迟迟形成不了稳定平台，出现锯齿、周期性抖动或持续下滑，可优先排查：

①防护设备CPU、内存或转发队列是否接近上限；

②清洗、限速或封禁策略是否反复切换；

③攻击流量是否穿透并挤占后端资源；

④链路或出口带宽是否出现阶段性拥塞。

3. 回落和恢复异常。

若攻击停止后回落过慢、低于原背景水平，或恢复阶段持续波动，可优先排查：

①防护、限速策略是否及时退出；

②连接跟踪、NAT或会话表状态是否释放；

③路由、邻接或负载均衡状态是否重新收敛；

④后端连接池、线程或缓存是否完成恢复。

4. 需要注意：

总流量曲线只能提示异常发生在哪个阶段，不能单独判断原因。最终还要把业务成功率、响应时间、错误码、端口统计和设备日志放到同一时间轴上，才能区分攻击穿透、防护误伤还是后端业务波动。