我很确定你的服务器已经记录了所有传入请求的ip(大多数都是这样)——所以数据已经在那里了。

也许你可以:

只需验证“获胜者”，验证它的IP在日志中显示的值小于某个阈值(我使用“grep | wc -l”来获得计数)。如果它超过你的阈值，暂时阻止该IP(一个小时左右?)

取消任何与“上一位”中奖者有相同收货地址或付款信息的“中奖者”的资格，或者在一定时间内中奖的“中奖者”，以分散“中奖”。

机器人不会把他们弄到那里的。

把刮刀惹毛: 当“随机垃圾”条目出现时，通过“代码混淆器”运行该页面的HMTL输出……这不会改变页面的“显示”…只是用随机生成的id打乱代码等。

更阴险的:

根据获胜IP在日志中出现的次数，增加“获胜”项目的价格。即使机器人赢了，你也赢了。: -)

假定原则:

第一个屏幕必须是非常简单的低开销HTML，带有一个易于识别的按钮(游戏邦注:无论是机器人还是玩家)，以明确表示“我想要我的垃圾”。因为我们假设了最坏的情况-你有来自机器人和非机器人组合的DOS攻击，所有人都首先点击网站(就可识别性而言)。所以让我们尽快把这些从缓存，良性回声机器人等中分发出去。

(注:就追求者而言，这就是发生的事情;这对用户和Woot来说都是痛苦的，所以任何有助于吸收或缓解首次屏幕获取的内容都符合三方的利益。)

然后，对于非机器人来说，这个过程不需要比现在更糟糕，对于正版机器人来说，不需要额外的步骤(或痛苦)。(关于当前设计的背景说明:当前的wooters通常已经签约，或者可以在购买过程中签约。新买家需要在购买时进行注册。所以实际上已经注册和已经登录会更快。)

为了完成垃圾销售，需要导航一系列交易屏幕(比如5个正负，取决于具体情况)。获胜者是第一个完成全部导航的人。当前进程奖励那些最快完成整个5个屏幕序列的机器人(或其他人);但整个进程都偏向于快速响应(即机器人)。

毫无疑问，机器人将在第一个屏幕上占据优势;无论他们在这一点上取得了什么优势，他们都会在剩下的屏幕上保持下去，再加上身体在其他阶段提供的任何优势。

What if Woot were to intentionally decouple the queuing process after the first screen, and feed every session from that point into a sequence of fixed-minimum-time steps? The second screen wouldn't even be presented until 30 seconds had passed; after it was submitted, same for the following screens. I bet wooters would have no problem if they were told that, after the first screen, they would wait in a queue (which is already true) that would spread the load over time in a way that should take no longer than before, be more robust, and help weed out the bots. At this point you can throw in some of the bot speedbumps listed above (subtle variations in DOM objects, etc.) Just the benefit from the perception that Woot is a little more in control of things would help.

If a much higher proportion of the BOC initial hits could segue into a bot-unfriendlier non-time-critical process on their first hit (or close to it), rather than retrying, then real people who get past that point would have more confidence. For sure it would be less hostile than the current situation. It might cut down on the background-noise-ambient-bot-rate that's going on all the time even under normal Woot-Off circumstances. And the bots would lay off the main page and sit in the queue with each other (and everyone else) where they have no advantage.

Hmmm... The concept "apartment-threaded" comes to mind. I wonder if the pattern is approximately useful? A useful core concept here is being able, after the first screen, to track accumulated total time in queue and be able to adjust to standard. As a bot-mitigation strategy, you would have a little bit of flexibility to maybe fudge the very earliest sessions by maybe 5-10 seconds; doing so would probably be undetectable, but would result in a richer non-bot purchase mix. I'm sure you have statistics to help evaluate stuff like this after the fact. Just for fun, you could (at least for one wootoff) put together your own bot that combines the best features you've seen, and then hand it out to everyone the day before. Then at least everyone would be equally armed. (Then duck ... incoming ...)

I think that sandboxing certain IPs is worth looking into. Once an IP has gone over a threshold, when they hit your site, redirect them to a webserver that has a multi-second delay before serving out a file. I've written Linux servers that can handle open 50K connections with hardly any CPU, so it wouldn't be too hard to slow down a very large number of bots. All the server would need to do is hold the connection open for N seconds before acting as a proxy to your regular site. This would still let regular users use the site even if they were really aggressive, just at a slightly degraded experience.

您可以使用这里描述的memcached，以较低的成本跟踪每个IP的命中数。

从没想过我会推荐闪光灯，但是闪光灯呢?不管是不是交易时间，让服务器发送异步加密内容到flash文件信号。只要响应是相同大小的交易或没有交易，机器人就不能分辨它是哪一个。

在更一般的层面上，您需要关注人类和浏览器拥有的资源，而脚本机器人没有，并利用对人类/浏览器来说容易而对机器人来说很难的东西。验证码显然是一个简单的尝试，但不适合你的网站，因为你说。Flash将淘汰大量的机器人，只留下驱动真正浏览器的(较慢的)机器人。解决方案可能比验证码简单得多，如果它只需要用户点击正确的位置。

利用人类的大规模并行图像处理能力!

根据您想要进入的复杂程度，您可以采取一些解决方案。

这些都是基于IP跟踪，在僵尸网络和云计算下有些崩溃，但应该能挫败绝大多数的僵尸。乔·兰登拥有大量机器人的可能性远远低于他只是运行一个从某处下载的Woot机器人来获取他的垃圾的可能性。

普通的节流

At a very basic, crude level, you could throttle requests per IP per time period. Do some analysis and determine that a legitimate user will access the site no more than X times per hour. Cap requests per IP per hour at that number, and bots will have to drastically reduce their polling frequency, or they'll lock themselves out for the next 58 minutes and be completely blind. That doesn't address the bot problem by itself, but it does reduce load, and increases the chance that legitimate users will have a shot at the item.

自适应调节

An variant on that solution might be to implement a load balancing queue, where the number of requests that one has made recently counts against your position in the queue. That is, if you keep slamming the site, your requests become lower priority. In a high-traffic situation like the bag of crap sales, this would give legitimate users an advantage over the bots in that they would have a higher connection priority, and would be getting pages back more quickly, while the bots continue to wait and wait until traffic dies down enough that their number comes up.

废料验证码

Third, while you don't want to bother with captchas, a captcha at the very end of the process, right before the transaction is completed, may not be a bad idea. At that point, people have committed to the sale, and are likely to go through with it even with the mild added annoyance. It prevents bots from completing the sale, which means that at a minimum all they can do is hammer your site to try to alert a human about the sale as quickly as possible. That doesn't solve the problem, but it does mean that the humans have a far, far better chance of obtaining sales than the bots do currently. It's not a solution, but it's an improvement.

以上的组合

实施基本的、慷慨的限制来阻止最滥用的机器人，同时考虑到单个公司IP背后的多个合法用户的潜力。截止数字将非常高——你引用了bot攻击你的网站10次/秒，即216万次/小时，这显然远远高于任何合法的使用量，即使是最大的公司网络或共享ip。

实现负载平衡队列，这样如果占用的服务器连接和带宽超过自己的份额，就会受到惩罚。这将惩罚共享公司池中的人，但不会阻止他们使用站点，而且他们的违规行为应该远没有您的装瓶者那么可怕，因此他们的惩罚应该不那么严重。

最后，如果您超过了每小时请求的某个阈值(这个阈值可能远远低于“自动断开连接”的截止值)，那么就要求用户使用验证码进行验证。

这样，合法使用网站的用户每小时只有84个请求，即使他们非常兴奋，也不会注意到网站速度变慢了。然而，乔·波特发现自己陷入了两难境地。他可以:

Blow out his request quota with his current behavior and not be able to access the site at all, or Request just enough to not blow the request quota, which gives him realtime information at lower traffic levels, but causes him to have massive delays between requests during high-traffic times, which severely compromises his ability to complete a sale before inventory is exhausted, or Request more than the average user and end up getting stuck behind a captcha, or Request no more than the average user, and thus have no advantage over the average user.

只有滥用的用户才会受到服务降级或复杂性增加的影响。合法用户不会注意到任何变化，除了他们更容易购买他们的垃圾包。

齿顶高

以远低于注册用户的速率限制未注册用户的请求。这样，机器人所有者就必须通过一个经过身份验证的帐户来运行机器人，以通过应该是相对严格的节流率。

然后，有创造力的装瓶者将注册多个用户id，并使用这些id来实现他们想要的查询率;您可以通过将给定时间段内来自同一IP的任何ID视为相同的ID，并接受共享节流来解决这个问题。

这使得装瓶商别无选择，只能运行一个机器人网络，每个IP一个机器人，每个机器人注册一个Woot账户。不幸的是，这实际上无法与大量未关联的合法用户区分开来。

您可以将此策略与上述一种或多种策略结合使用，目的是为没有滥用使用模式的注册用户提供最佳服务，同时根据他们的状态(匿名或已注册)以及由流量指标决定的滥用程度逐步惩罚其他用户，包括注册用户和未注册用户。

我只是想知道有没有简单的解决办法。

我假设表明垃圾销售的消息是通过文本发布的，这就是刮刮器寻找的信息。

如果你用图片来代替广告呢?这样做可能会带来一些设计问题，但它们可以被克服，并可能成为一些巧妙创意的动力。

问题# 1 必须有一些设计空间专门用于图像。(想耍点花招吗?通过这个插槽旋转一个本地广告。当然，图像的名称需要是静态的，以避免给刮刀的气味。这是一个永远不用担心广告盲目性的位置……)

问题# 2 RSS。我不确定是否每个人都可以在他们的提要阅读器中查看图像。如果有足够多的用户可以这样做，那么您可以开始发送包含图像的每日提要更新。你可以在大多数日子里发送任何你想要的杂七杂四的东西，然后根据需要将其切换为你的垃圾销售警报。

我不知道……他们会不会只是编程让他们的机器人在每次feed项目出去的时候都攻击你的网站?

其他问题吗?可能很多。也许这将有助于头脑风暴。

当心 布莱恩