你的最终目标是让更多的用户购买你的产品。

如果您在一两个小时内释放w00t包，并在一系列IP地址上释放它们，而不是同时将它们释放到任何IP地址，会怎么样呢?

假设你有255袋w00t。1.0.0.0可以在第一分钟购买，2.0.0.0可以在第二分钟购买(可能有2袋w00t可用)，等等。

然后，在255分钟之后，你已经为每个人提供了几袋w00t，尽管很可能不是所有255袋w00t都剩下了。

这将真正的攻击限制在拥有>255台计算机的用户，尽管机器人用户可能能够“拥有”分配给他们的IP范围的w00t包。

没有要求你匹配包的IP公平(你肯定应该使用某种类型的MD5 /随机种子的东西)…如果你增量地分配10袋w00t，你只需要确保它在你的人群中均匀地分配。

如果IP不好，那么您可以使用cookie，并排除向未经过cookie的用户提供一袋w00t的用例。

如果您注意到某个特定的IP、cookie或地址范围具有非常大的流量，请按比例在稍后/最后向它们提供w00t包，以便偶尔/稳定/缓慢的访问者在重度/快速/可能的bot用户之前获得机会。

——罗伯特。

我同意OP在这里-请不要验证码-这不是一个非常woot的做事方式。

首先设置一些机器人陷阱。我会在主页上更经常地提到BOC，让机器人看起来不智能，所以每次措辞都不同。“中行投诉上升!”所以扫描关键词的机器人会被困住。

然而，我认为真正的问题是双重的，首先是你需要解决的性能问题，今天是机器人造成了一个问题，但它向我表明，有一个性能问题需要解决。

其次，这是一个商业机会，可以把一些真正的垃圾转化为利润。所以我将保持整体woot风格并声明“我们检查机器人”。如果我们认为你是机器人，你就会得到一盒垃圾。”

机器人检查将在销售完成后的某个时间离线完成，使用机器人陷阱，IP号码，cookie，会话，浏览器字符串等。对你获得的购买者数据做一些认真的分析，以决定谁得到了废话。如果你决定发布垃圾，那么你就可以把一些正常的垃圾卖给别人。

Provide an RSS feed so they don't eat up your bandwidth. When buying, make everyone wait a random amount of time of up to 45 seconds or something, depending on what you're looking for exactly. Exactly what are your timing constraints? Give everyone 1 minute to put their name in for the drawing and then randomly select people. I think this is the fairest way. Monitor the accounts (include some times in the session and store it?) and add delays to accounts that seem like they're below the human speed threshold. That will at least make the bots be programmed to slow down and compete with humans.

我将要描述的方法有两个要求。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.

问:你如何阻止脚本写手在一秒钟内上百次地攻击你的网站? A:你不需要。外部代理无法阻止这种行为。

你可以使用大量的技术来分析传入的请求，并尝试启发式地确定谁是人，谁不是人……但它会失败。最终，即使不是马上。

唯一可行的长期解决方案是改变游戏，使网站不再对机器人友好，或者减少对编剧的吸引力。

你是怎么做到的?那是另一个问题了!: -)

...

好吧，上面已经给出了一些选项(并拒绝了)。我对你的网站不是很熟悉，只看过一次，但由于人们可以阅读图像中的文本，而机器人无法轻松做到这一点，所以将公告更改为图像。不是验证码，只是一个图像-

generate the image (cached of course) when the page is requested keep the image source name the same, so that doesn't give the game away most of the time the image will have ordinary text in it, and be aligned to appear to be part of the inline HTML page when the game is 'on', the image changes to the announcement text the announcement text reveals a url and/or code that must be manually entered to acquire the prize. CAPTCHA the code if you like, but that's probably not necessary. for additional security, the code can be a one-time token generated specifically for the request/IP/agent, so that repeated requests generate different codes. Or you can pre-generate a bunch of random codes (a one-time pad) if on-demand generation is too taxing.

运行真实的人对这个问题的响应的时间试验，并忽略('哎呀，发生错误，对不起!请再试一次’)的反应比一半的时间要快。此事件还应该触发警报，提醒开发者至少有一个机器人已经弄清楚了代码/游戏，所以是时候修改代码/游戏了。

继续定期地改变游戏，即使没有机器人触发它，这只是在浪费编剧的时间。最终，编剧会厌倦这款游戏，去别的地方……我们希望;-)

最后一个建议:当你的主页收到请求时，把它放到一个队列中，然后在一个单独的进程中按顺序响应请求(你可能不得不入侵/扩展web服务器来做到这一点，但这可能是值得的)。如果来自同一IP/代理的另一个请求进入，而第一个请求在队列中，忽略它。这将自动减轻机器人的负载。

编辑:另一种选择，除了使用图像，是使用javascript来填写购买/不购买的文本;机器人很少解释javascript，所以他们不会看到它

我不能百分之百地确定这是否可行，至少不尝试一下是不行的。

But it seems as if it should be possible, although technically challenging, to write a server-side HTML/CSS scrambler that takes as its input a normal html page + associated files, and outputs a more or less blank html page, along with an obfuscated javascript file that is capable of reconstructing the page. The javascript couldn't just print out straightforward DOM nodes, of course... but it could spit out a complex set of overlapping, absolute-positioned divs and paragraphs, each containing one letter, so it comes out perfectly readable.

机器人将无法阅读它，除非它们使用完整的渲染引擎和足够的人工智能来重建人类将看到的内容。

然后，因为这是一个自动化的过程，您可以根据您的计算能力经常重新打乱站点-每分钟，或每十分钟，或每小时，甚至每次页面加载。

当然，写这样一篇含糊不清的文章会很困难，而且可能不值得。但这只是一个想法。