清洗生效的标志之一，是正常请求延迟从剧烈波动回到稳定区间攻击流量可以被清洗，但业务延迟稳不住，清洗就没有真正完成。
很多运维在DDoS攻击后只盯着攻击流量大小,忽略正常请求延迟，攻击流量降下来了，正常用户访问却依然卡顿或超时，这种清洗只能算“半成品”，真正有效的清洗，必须让正常请求的延迟曲线回归攻击前基线，并且保持稳定。
流量清洗前后延迟对比：稳定才是清洗生效的标志
清洗前,正常用户请求和攻击流量混在一起，延迟可能从几十毫秒飙到几百毫秒甚至直接超时，清洗生效后，正常请求走清洗节点，延迟曲线应回到攻击前的基线附近，行业共识认为，判断清洗是否有效，不能只看清洗设备报表里的“拦截率”，要看真实业务的延迟是否恢复。
- 清洗前：延迟波动大，丢包严重，连接频繁超时
- 清洗中：延迟可能短暂升高，因为流量被牵引到清洗节点
- 清洗生效后：延迟回到基线，抖动变小，业务可用
如何确认延迟回到了基线
- 攻击前连续7天,每小时记录一次ping平均延迟，取中位数作为基线
- 清洗期间每30秒记录一次,对比基线偏移幅度
- 如果多数采样点延迟偏移在可接受范围内,判定清洗生效
DDoS清洗后正常请求延迟多少正常？看这三个指标
没有统一绝对值,因为业务类型、地域、线路不同，但可以关注三个指标，它们共同决定“延迟稳定”是否达标。
延迟绝对值回到业务容忍阈值
多数Web业务能接受150ms以内的延迟,实时交互业务则要求更低，清洗生效后，正常请求的延迟应回到攻击前多数采样点的水平，而不是长期停留在高位。
抖动控制在较小范围
抖动比平均延迟更影响体验,清洗生效后，延迟曲线应平滑，不会出现每隔几秒跳一次的情况，抖动大说明清洗节点处理能力不稳定，或者清洗策略在频繁切换。
丢包率接近零
正常请求丢包率应恢复到攻击前水平,持续丢包说明清洗策略误伤正常流量，哪怕平均延迟不高，业务也会出现卡顿。
| 指标 | 清洗未生效 | 清洗生效 |
| 平均延迟 | 波动大，频繁超时 | 接近攻击前基线 |
| 抖动 | 忽高忽低 | 曲线平滑 |
| 丢包率 | 较高 | 接近零 |
游戏服务器清洗后延迟高？先检查清洗策略
游戏常走UDP协议,很多清洗设备对UDP流量处理保守，容易把正常游戏包当攻击包丢掉或延迟转发，如果游戏服务器清洗后延迟高，按下面步骤排查。
游戏UDP流量的清洗排查步骤
- 第一步：对比直连源站与走清洗节点的延迟，用mtr或游戏客户端自带网络诊断，分别记录
- 第二步：在清洗设备上查看UDP会话表，确认正常游戏端口是否被限速
- 第三步：调整清洗策略，对游戏业务端口设置白名单或提高UDP容忍阈值
- 第四步：观察5-10分钟，游戏内延迟应逐步稳定
游戏场景对延迟极其敏感,清洗策略稍微保守一点，正常玩家的延迟就会明显上升，很多游戏服务器清洗后延迟高，问题都出在UDP会话表的老化时间太短，正常玩家的长连接被反复打断。
高防IP清洗价格与延迟关系：贵的不一定稳
很多用户以为高防IP越贵,延迟越低、清洗越稳，实际上价格主要反映防护带宽和清洗能力，延迟更多取决于清洗节点离用户距离和线路质量，近年来，不少用户反馈高价高防IP在跨地域访问时延迟并不理想，反而中端产品配合就近清洗节点表现更稳。
深圳高防服务器清洗延迟测试怎么做
如果你租用的是深圳高防服务器,可以在本地用以下命令测试清洗前后的延迟变化。
- 测试命令：
ping -t 深圳高防IP，持续观察延迟曲线 - 路径测试：
mtr --report 深圳高防IP，看经过的跳数和丢包点 - HTTP测试：
curl -w "连接时间:%{time_connect} 总时间:%{time_total}" -o /dev/null -s 网站地址
对比清洗前后数据,如果延迟曲线趋平，说明清洗对正常请求影响已消除。
| 类型 | 延迟表现 | 适用场景 |
| 入门高防 | 清洗节点较少，延迟可能略高 | 小型网站、非实时业务 |
| 中端高防 | 多节点，延迟较稳定 | 电商、App |
| 高端高防 | 优质线路，延迟接近直连 | 游戏、金融 |
实操：用命令判断清洗后延迟是否稳定
Windows环境
- 打开命令提示符,运行
ping -t 目标IP - 观察“时间”列，正常时应围绕一个值小幅波动
- 如果每隔一段时间出现大延迟或超时,清洗可能未完全生效
Linux环境
- 使用
mtr -r -c 100 目标IP - 查看最后一跳的丢包率和平均延迟
- 使用
curl -w "%{time_total}\n" -o /dev/null -s https://目标网站连续执行多次，记录总耗时 - 多次执行结果差值不大,说明延迟稳定
延迟稳定的判断标准（实操版）
- 连续采样5分钟,超过九成的采样点延迟偏差在基线的较小范围内
- 没有出现连续3次以上超时
- 业务日志中连接超时和重连次数明显下降
正常请求延迟稳定，是清洗生效最直接的业务信号，先让延迟回到基线，再谈清洗率和攻击峰值，运维判断才不会跑偏。
关于清洗生效与正常请求延迟稳定的常见问题
问：清洗生效后正常请求延迟还是忽高忽低怎么办？
先检查清洗策略是否误伤正常协议,再对比直连路径与清洗路径的延迟差，若清洗路径延迟高，可切换清洗节点或调整防护模式。
问：怎么判断是高防清洗延迟高还是源站本身延迟高？
在源站本地和外部网络分别测试,源站本地延迟正常，外部走清洗节点后延迟高，说明问题在清洗链路，若源站本身延迟高，先排除服务器负载和带宽跑满。
问：清洗生效的标志之一是正常请求延迟稳定，那延迟多少才算稳定？
没有统一绝对值,核心是回到攻击前基线附近，延迟曲线平滑、抖动小、丢包率接近零，即可判定稳定，事实是，业务能正常响应比单纯看延迟数字更重要。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/651759.html
