我建议使用基于防火墙的解决方案。Netfilter/iptables与大多数防火墙一样，允许您设置单位时间内新页面请求的最大数量。

例如，为了限制分配给人类的页面视图的数量——比如说，每30秒6次请求——你可以发布以下规则:

iptables -N BADGUY
iptables -t filter -I BADGUY -m recent --set --name badguys

iptables -A INPUT -p tcp --dport http -m state --state NEW -m recent --name http --set
iptables -A INPUT -p tcp --dport http -m state --state NEW -m recent --name http --rcheck --seconds 30 --hitcount 6 -j BADGUY
iptables -A INPUT -p tcp --dport http -m state --state NEW -m recent --name http --rcheck --seconds  3 --hitcount 2 -j DROP

请注意，此限制将独立应用于每个访问者，因此一个用户滥用网站不会影响其他访问者。

希望这能有所帮助!

As for CAPTCHAing everyone, why not use the Google solution of only requiring CAPTCHAs from IPs you suspect as being bots, or even just users that hammer the site? I'm sure asking someone for a CAPTCHA when they purchase isn't so bad if they've been hammering the site anyway, its just about the same as staying up and hitting F5 repeatedly. That or maybe require a periodic CAPTCHA when hammering, say every hundred (maybe smaller?) or so refreshes, to stop alarm-bots from working. You need some sort of CAPTCHA to prevent botting, but you also need to account for the fact that your real users will act like bots.

我将要描述的方法有两个要求。1) Javascript被强制执行2)一个具有有效http://msdn.microsoft.com/en-us/library/bb894287.aspx浏览器会话的web浏览器。

如果没有其中任何一个，你就是“故意”倒霉的。互联网被设计成允许匿名客户查看内容。简单的HTML没有办法解决这个问题。哦，我只是想说，简单的，基于图像的验证码很容易被击败，甚至作者也承认这一点。

Moving along to the problem and the solution. The problem is in two parts. The first is that you cannot block out an individual for "doing bad things". To fix this you setup a method that takes in the browsers valid session and generate a md5sum + salt + hash (of your own private device) and send it back to the browser. The browser then is REQUIRED to return that hashed key back during every post / get. If you do not ever get a valid browser session, then you reply back with "Please use a valid web browser blah blah blah". All popular browsers have valid browser session id's.

现在我们至少有了该浏览器会话的标识(我知道它不会永久锁定，但是通过简单的脚本很难“更新”一个浏览器会话)，我们可以有效地锁定一个会话(例如;让脚本编写人员很难访问你的网站，而不会对有效用户造成任何惩罚)。

Now this next part is why it requires javascript. On the client you build a simple hash for each character that comes from the keyboard versus the value of the text in the textarea. That valid key comes over to the server as a simple hash and has to be validated. While this method could easily be reverse engineered, it does make it one extra hoop that individuals have to go through before they can submit data. Mind you this only prevents auto posting of data, not DOS with constant visits to the web site. If you even have access to ajax there is a way to send a salt and hash key across the wire and use javascript with it to build the onkeypress characters "valid token" that gets sent across the wire. Yes like I said it could easily be reversed engineered, but you see where I am going with this hopefully.

现在为了防止不断的交通滥用。有几种方法可以在给定有效的会话id后建立模式。这些模式(即使使用Random来抵消请求时间)的epsilon比人类试图重现相同的误差范围时要低。由于您有一个会话ID，并且您有一个“看起来像一个bot”的模式，那么您可以用一个简单的轻量级响应屏蔽该会话，该响应是20字节而不是200000字节。

You see here, the goal is to 1) make the anonymous non-anonymous (even if it's only per session) and 2) develop a method to identify bots vs. normal people by establishing patterns in the way they use your system. You can't say that the latter is impossible, because I have done it before. While, my implementations were for tracking video game bots I would seem to think that those algorithms for identifying a bot vs. a user can be generalized to the form of web site visits. If you reduce the traffic that the bots consume you reduce the load on your system. Mind you this still does not prevent DOS attacks, but it does reduce the amount of strain a bot produces on the system.

已经发布了一些其他/更好的解决方案，但为了完整起见，我想我会提到这个:

If your main concern is performance degradation, and you're looking at true hammering, then you're actually dealing with a DoS attack, and you should probably try to handle it accordingly. One common approach is to simply drop packets from an IP in the firewall after a number of connections per second/minute/etc. For example, the standard Linux firewall, iptables, has a standard operation matching function 'hashlimit', which could be used to correlate connection requests per time unit to an IP-address.

虽然，这个问题可能更适合于上一个so播客中提到的下一个so衍生产品，它还没有推出，所以我想可以回答:)

编辑: 正如novatrust指出的那样，仍然有ISP实际上没有分配ip给他们的客户，因此有效地，这样一个ISP的脚本客户将禁用该ISP的所有客户。

对每分钟发出如此多请求的用户代理进行计时。例如，如果有人在10分钟内每5秒请求一个页面，他们可能不是用户。但要做到这一点可能很棘手。

如果他们触发警报，将每个请求重定向到一个静态页面，尽可能少地使用DB-IO，并发送消息让他们知道他们将在X分钟内被允许返回。

重要的是，你应该只在页面请求上应用这个，忽略所有的媒体请求(js，图像等)。

那么使用Flash呢?

是的，我知道使用Flash的开销，加上一些用户将无法购买这些垃圾(即iPhone用户)，这可能会造成不利影响，但在我看来，Flash可以防止屏幕抓取或至少使其变得困难。

我错了吗?

编辑添加

在你的提交表单上添加几个“隐藏”字段怎么样，就像我下面发现的那样:

Actually, best practice seems to be to use two hidden fields, one with an initial value, and one without. It's the rare bot which can ignore both fields. Check for one field to be blank, and the other to have the initial value. And hide them using CSS, not by making them "hidden" fields: .important { display : none ; } Please don't change the next two fields. Bots tend to like fields with names like 'address'. The text in the paragraph is for those few rare human beings who have a non-CSS capable browser. If you're not worried about them, you can leave it out. In the logic for processing the form, you'd do something like: if (address2 == "xyzzy" and address3 == "") { /* OK to send / } else { / probably have a bot */ }