总而言之，我遇到过这样的情况：所有 Apache 线程都挂起了，因为它们在发送 HTTP 页面后都在等待来自客户端的 TCP ACK，因此，Apache 线程在转到下一个请求之前要等待 300 秒（conf 的超时值）。然后又发生了同样的事情。
事情的发生是这样的：流量突然达到峰值，apache 和 db 服务器负载如预期上升，在某个时刻，每个 apache 线程都进入这种状态，apache 和 db 负载变为 0。这种情况持续了几个小时。apache 重新启动后，页面再次正常处理，负载上升，然后再次发生这种情况，负载变为 0。现在，尚不清楚这是一次攻击还是某些不良软件/硬件的后果。
详细信息：当一切都挂起时，您可以查看 apache 的服务器状态页面，所有线程都标记为“W”（工作），并且您会看到计时器 SS（处理请求的时间）上升到 300 秒，然后转到下一个 HTTP 请求并再次从 300 秒开始。
在通过 netstat 的套接字部分中，我们看到这些 Apache 线程的所有套接字都处于 CLOSE_WAIT 状态，并且 Send-Q 值较高（发送的数据包未被确认）。使用 strace，我们确实看到 Apache 在套接字上执行了 300 秒的 poll()，等待数据包被确认。
现在，无论是攻击还是某些不良网络配置导致数据包丢失，我的问题是：我们如何防止这种情况发生？这似乎是一种特别恶劣的攻击。
我知道慢速 loris 攻击，当你非常缓慢地发出 HTTP 请求时，如果你有 CDN、反向代理等，这种情况可以得到缓解...但是对于这种特殊情况，我没有看到可以阻止这种情况的东西？
您将如何防止这种情况发生？
谢谢！
答案1
在 Apache 前面放一个 litespeed。这可以解决你的问题。这正是我们针对缓慢请求、反射和常规 DDoS 问题所做的。解决意味着至少在某种程度上。
编辑部分：
当然，
Litespeed 是一种 Web 服务器/负载均衡器，是一种反向代理，也是速率限制可用的 DDoS 攻击缓解软件。我们遇到过与您提到的相同类型的攻击，而且更严重，每秒有近 400,000 个 http 请求。我们安装了一台 litespeed 服务器，配备 24 核 128 GB RAM，litespeed 在安装的 RAM 中运行，操作系统在 raid0 条带 ssd 磁盘中运行。这解决并阻止了这次攻击。
您还可以通过配置和设置阻止慢速 loris 攻击。我们仍然有一个负载平衡器，但传入流量首先通过 litespeed，然后通过代理传输到我们的硬件负载平衡器。