只看峰值数值会误判攻击峰值带宽评估结果

在安全事件复盘中，监控图上突然出现的最高流量值很容易成为结论依据。但一次持续数百毫秒的尖峰，与连续十分钟的高流量，对互联网线路、防火墙、负载均衡器和源站造成的影响完全不同。准确的攻击峰值带宽评估，重点不是寻找最大数字，而是还原攻击流量在时间、方向、协议和设备层面的实际压力。

为什么单一峰值会误导判断

网络监控通常同时提供1秒、10秒、1分钟或5分钟聚合数据。同一段攻击流量，如果只在1秒内突然冲高，5分钟平均值可能并不突出；反过来，持续的中高流量虽然没有最高尖峰，却可能更快耗尽线路或设备资源。因此，带宽利用率必须同时记录瞬时值、短时平均值和较长时间窗口的趋势。

大包流量主要占用字节带宽，小包攻击则可能先耗尽数据包速率处理能力。SYN flood还会增加半连接表压力，UDP流量可能让防火墙频繁执行规则匹配。也就是说，线路尚未达到标称容量时，边界设备仍可能因为每秒处理的数据包数量、连接状态或规则复杂度而丢包。

先统一测量范围。明确统计的是入口、出口、单个网卡、整个机房，还是某个公网地址。入口流量和出口流量不能混为一个峰值，清洗节点前后的数据也要分别保留。
保存多种时间粒度。至少保留1秒或5秒级原始采样，并生成1分钟、5分钟聚合结果。对短促尖峰记录开始时间、结束时间和持续时长，避免只留下监控系统上的一个最高点。
分别计算带宽与包速率。带宽可按“统计周期内字节数×8÷周期秒数”换算；数据包速率则按“数据包总数÷周期秒数”计算。两者应按TCP、UDP、ICMP等协议拆分。
对照设备实际限制。查看路由器、防火墙、交换机和清洗设备的端口速率、包处理能力、会话表使用率、丢包计数及CPU占用。厂商标称值通常与特定包长、规则数量和测试环境有关，不能直接当作生产上限。
核对业务影响。把入口峰值与网页响应时间、错误率、连接建立失败、源站CPU和数据库连接池变化对齐。如果边缘流量很高但源站指标稳定，说明部分流量可能已被拦截或缓存；如果回源流量同步上涨，风险更接近真实业务承压。

建议将事件按持续时间分层，而不是只按最高带宽分级。几秒以内的尖峰要重点检查采样精度和是否存在批量转发、监控补报；持续数分钟的高流量要观察线路利用率、丢包与连接状态；持续更久的攻击则应检查清洗策略是否稳定、源站回源是否增加，以及采样窗口变长后平均值是否仍接近资源上限。

还要注意方向差异。反射类UDP流量可能在入口形成明显峰值，而攻击请求经过过滤后未必等比例到达源站；针对应用层接口的请求，带宽不一定高，却可能通过大量小响应、复杂查询或重复握手消耗应用资源。因此，攻击峰值带宽评估应将网络层、传输层和应用层结果并列查看。

容量规划至少应形成三组结果：短时最大值、可持续高位值和源站实际收到的有效流量。线路扩容适合解决持续接近端口上限的问题；升级防火墙或清洗能力，通常针对包速率、连接数或规则处理瓶颈；优化缓存、限流和接口校验，则更适合回源压力明显但入口带宽并未饱和的场景。

报告中应写清测量点、采样周期、攻击持续时间、协议构成、是否包含报文头开销，以及异常期间的丢包和业务指标。这样得到的攻击峰值带宽评估才能支持设备选型和应急阈值设置，而不是被一个偶然尖峰牵着走。

不一定。短时大包峰值可能很高但影响有限，小包高包速率或持续连接攻击则可能更快耗尽设备资源。

两者都需要。1秒数据用于识别尖峰和突发丢包，5分钟数据更适合判断线路是否长期处于高负载状态。

可能是边缘规则、清洗设备或缓存拦截了大部分流量。应比较清洗前后的流量，并核对回源请求和源站日志。