应用层慢速请求与网络层洪泛攻击的区分，不能只看某一刻的流量峰值。前者常用很少的连接拖住服务端，后者则以密集的数据包或连接请求冲击网络设备、链路或主机。判断时应把连接状态、流量走势和服务日志放在一起看。
先看连接：长时间占用，还是短时间涌入
慢速请求的典型例子是 Slowloris 一类攻击：客户端逐步发送请求内容，或迟迟不结束请求，使 Web 服务持续保留连接。监控上可能看到已建立连接持续偏多、连接存活时间变长，但每条连接传输的数据很少；网页请求成功率也可能下降，而总流量并不显著升高。
网络层洪泛则常见 SYN 洪泛、UDP 洪泛或 ICMP 洪泛。其特点是网络接口收到的数据包突然增多，连接请求或未完成握手的数量异常上升，甚至造成链路、路由器或主机网络栈拥塞。连接可能持续时间很短，也可能根本没有形成完整的应用请求。
用四类证据交叉判断
- 流量曲线：对照入站和出站字节数、数据包数量及带宽利用率。洪泛往往出现明显尖峰；慢速请求更可能表现为连接数和等待时间上升，带宽变化较小。单看带宽可能漏掉小包密集的情况。
- 连接状态：查看连接持续时间、已建立连接数，以及握手是否完成。大量长寿命、低数据量连接更像慢速请求；大量短时连接或未完成握手更需排查网络层洪泛。
- 服务日志：检查 Nginx 或 Apache 的访问日志与错误日志，观察请求是否迟迟没有完整记录、响应耗时是否变长，以及是否出现连接超时。日志只能反映到达应用层的流量，不能代表所有网络数据包。
- 抓包特征：使用 Wireshark 等工具，在受影响主机或边界设备上观察协议类型、握手过程和数据包间隔。若网络层计数骤增但应用日志没有相应请求，问题可能发生在请求到达服务之前。
按顺序排查，避免把症状当成原因
- 记录告警开始时间、受影响主机和用户可见症状，并与正常时段的基线比较。
- 先查看接口流量和数据包计数，再检查连接状态及连接持续时间；两者都要按同一时间窗口对照。
- 抽查服务日志和错误日志，确认是否有完整请求、超时或响应延迟。日志量过大时，可按时间段和请求路径筛选。
- 在边界或主机侧短时抓取样本，核对协议分布、握手完成情况和请求间隔；注意抓包本身也会增加系统负担。
- 若连接长期占用但网络流量不高，优先检查服务端请求超时、连接数限制和反向代理配置；若数据包激增或链路饱和，应由网络运维人员检查上游设备和流量来源。
关键差异与处置侧重点
慢速请求主要消耗应用服务可用连接，适合从请求读取超时、并发连接上限、反向代理缓冲和异常连接监控入手。Nginx 可通过请求体与请求头读取超时相关配置缩短连接长期等待的窗口；具体取值要结合正常客户端上传时长和服务用途，过短可能误伤慢速网络用户。
网络层洪泛主要考验链路和网络设备承载能力。若入口链路已经拥塞，单在应用服务器上调整超时通常无法恢复访问，需要网络团队结合边界设备计数和上游观测处理。两类情况也可能同时出现，因此不能因日志里请求少，就排除网络侧异常。
常见问题
连接很多就一定是慢速请求吗？
不是。正常访问高峰也会增加连接数。要同时比较连接持续时间、每条连接传输量和服务日志。
带宽没有跑满，是否能排除网络洪泛？
不能。小数据包密集或设备处理能力不足时，链路带宽未满也可能出现丢包或延迟。
应用日志没有异常，能说明服务正常吗？
不能。流量可能在抵达应用前已被网络设备丢弃或阻塞，需要结合边界计数与抓包判断。
实务上，先确认异常主要落在连接占用还是数据包涌入，再结合日志与抓包验证。这样做，才能把应用层慢速请求与网络层洪泛攻击的区分建立在可观察证据上，并选择对应的处置方向。