时不时会有一堆非常慢的 HTTP 客户端决定从我的网站上获取页面。这很糟糕，因为当有足够多的客户端这样做时，它会大大减少可用于处理来自世界其他地方的请求的可用 Apache 进程的数量。我不知道这是某种蹩脚的 DDoS 攻击还是只是客户端速度非常慢。
在过去的几年里，我知道 lingerd 是解决这个问题的一个方法。但现在似乎没有太多关于它的活动。事实上，Debian 中缺少 lingerd 包（有一个旧的非官方包）表明有更好的方法。
我一直在使用 mod_limitipconn 来部分解决该问题，但我需要将该数字保持在足够高的水平，以免对普通浏览器造成不利影响。这使得它成为一种半吊子的解决方案。我想到我可以将 Squid 放在 Apache 之前，但这似乎有点太重了。或者我对 Squid 的印象有偏差。
无论如何，我正在寻找一些我错过的明显事物的想法或指示。
有想法吗？
答案1
如果这是 DDoS 攻击，您会看到来自多个位置的许多此类连接。您的问题中没有提供任何统计数据，因此我们无法真正判断。
如果许多缓慢的请求都来自同一位置，特别是针对大型对象时，则可能是人们使用下载管理器打开了许多连接。
如果您没有因为特定原因而无法使用 Apache，则可以考虑迁移到基于事件驱动架构的服务器，而不是基于威胁/流程的服务器，例如 nginx。这样可以更有效地扩展并发连接数，因为每个基本请求只需要很少的额外资源（尤其是 RAM）——尽管脚本资源请求的可扩展性可能因您的设置而有很大差异，例如，获得 modPHP 的效率（除非您已经在 (faast)CGI 模式下运行它）可能需要更多的设置工作，当然，您可能正在使用 Apache 之外不支持的其他模块/功能。
您也可以分配更多 RAM 并增加 Apache 进程/线程的最大数量。
这两种解决方案之间的折衷方案是，如果缓慢的请求针对的是静态资源，则可以使用轻量级 Web 服务器来提供静态内容（占用的 RAM 比 Apache 要少得多），并将脚本请求（以及其他需要除提供文件之外的额外功能的请求）代理到 Apache 的设置。许多大型高负载站点的运行方式与此类似。
我一下子不知道有什么方法可以限制单个请求所需的时间——这可能无论如何都无法解决你的问题，因为无论是在 DoS 情况下还是在下载管理器的情况下，都会立即尝试建立新的连接。