我有一个奇怪的问题 - 在一个高流量的网站上（每月有数百万访问者），每天我们会遇到大约 20 次左右的情况，其中一个主机开始不断地请求同一个页面，一遍又一遍 - 每秒多次，时间长度从几分钟到一整天。
这次攻击显然不是恶意的，因为我已经回溯了 IP 地址，并将其与我采访过的一些注册用户进行了匹配。他们说，当这种情况发生时，我们网站上的 JavaScript 计数器会“不断刷新”，他们的计算机会变慢，但其他方面都可以使用。这种情况不是每次页面加载时都会发生，而是偶尔发生。
日志命中有以下特点：
- 它们以“正常”方式启动——首次加载页面时实际上会访问页面的所有资源以及 .php
- 然后主机开始不断请求 php 页面，没有资源，通常每秒一个（但有时更快，有时会慢几秒钟）
- 远程浏览器始终是 Firefox 3.5.x
- 后续点击没有 referrer，尽管第一个页面请求有一个 referrer
我们对此束手无策。简单的 DoS 过滤器并不合适——我们有这个，并且触发它的阈值远高于每秒单个页面请求（没有相关图像、css 等）。
该堆栈是 LAMP、Redhat 安装、PHP 5.2、Apache 2.2.3，并带有作为软件负载均衡器运行的 NGINX 盒。
这正在摧毁我们的网站——请帮忙！在没有好主意的情况下，我们将诉诸编写一个虚拟过滤器，将 IP+URI 的密钥存储在 memcached 中，并增加每个页面请求。一旦它在一定时间内超过某个阈值，我们将对进一步的请求进行 403 处理。然而，我不认为这是网络堆栈中处理此问题的合适位置。
感谢您做出的任何贡献！
答案1
根据您自己的描述，我建议您先移除该计数器，看看是否真的有影响。这很容易测试，我很惊讶您还没有这样做。
答案2
寻找命中并发送 403 只会掩盖问题。听起来解决问题的更好方法是修复有问题的页面上的错误 javascript。
答案3
memcached 解决方案的问题在于，您仍然会获得命中，但您计划通过检查 memcached 并确定这是否是错误请求来避免为其提供服务的任何密集工作。这本身就是一项工作，但可以肯定的是，它可能会为您的网络服务器或数据库服务器节省一些 CPU。
使用 memcached 的另一种方法是计算该 URI 的响应，如果它对于 IP 是唯一的，则将以 IP+URI 为键的响应存储在 memcached 中，如果不是，则仅以 URI 为键，并使用任何其他会改变响应的唯一请求参数。然后使用任何少于 X 秒的缓存响应回答所有请求。现在您仍然每 X 秒重新计算一次，但这比每秒许多条关系要少。我相信 memcache 感知代理或 Web 服务器可以配置为执行此操作，而无需编写任何额外内容，例如内存代理， 或者Nginx分别。
最好找到不良行为的主要原因。如果它与 JavaScript 相关，则可能是与页面上的特定广告相关的 JavaScript。您需要开发一种机制来重新加载每个可能的广告的页面。如果没有这个机制，您最终无法捕获给一些用户带来问题的广告。