我已经接受了一个答案，但遗憾的是，我相信我们陷入了最初的最坏情况： CAPTCHA 每个人都在购买废话
。简短说明：缓存/网络农场无法跟踪点击，任何解决方法（发送非缓存网络信标、写入统一表等）都会比机器人更慢地降低网站速度。可能有来自 Cisco
或类似公司的一些昂贵的硬件可以在高水平上提供帮助，但如果每个人都可以进行 CAPTCHA
验证，则很难证明其成本是合理的。稍后我将尝试更完整的解释，并为将来的搜索者清理它（尽管欢迎其他人尝试，因为它是社区 wiki）。

情况

这是关于 woot.com 上的垃圾袋销售。我是 Woot Workshop 的总裁，它是 Woot
的子公司，负责设计、撰写产品描述、播客、博客文章并主持论坛。我使用
CSS/HTML，对其他技术几乎不熟悉。我与开发人员密切合作，并讨论了这里的所有答案（以及我们拥有的许多其他想法）。

可用性是我工作的重要组成部分，而让网站变得令人兴奋和有趣是剩下的大部分内容。这就是下面三个目标的来源。CAPTCHA
损害了可用性，机器人从我们的垃圾销售中窃取了乐趣和兴奋。

机器人会在第二次屏幕抓取（和/或扫描我们的 RSS）中猛烈抨击我们的首页数十次，以进行 Random Crap
销售。当他们看到这一点时，它会触发程序的第二阶段登录，点击我想要一个，填写表格，然后购买垃圾。

评估

lc：在使用此方法的 stackoverflow
和其他站点上，它们几乎总是与经过身份验证（登录）的用户打交道，因为正在尝试的任务需要这样做。

在 Woot 上，匿名（未登录）用户可以查看我们的主页。换句话说，slamming bot 可以是未经身份验证的（并且除了通过 IP
地址之外基本上是不可跟踪的）。

所以我们回到扫描IP，a）在这个云网络和垃圾邮件僵尸时代相当无用，b）考虑到来自一个IP地址的企业数量，它捕获了太多无辜者（更不用说问题了）非静态 IP
ISP 和试图跟踪这一点的潜在性能损失）。

哦，让人们打电话给我们将是最糟糕的情况。我们可以让他们给你打电话吗？

BradC：Ned Batchelder
的方法看起来很酷，但它们的设计非常牢固，可以击败为网站网络构建的机器人。我们的问题是机器人是专门为击败我们的网站而构建的。其中一些方法可能会在短时间内起作用，直到脚本编写者改进他们的机器人以忽略蜜罐，屏幕抓取附近的标签名称而不是表单
ID，并使用支持 javascript 的浏览器控件。

听

lc 再次：“当然，除非炒作是你营销计划的一部分。”
是的，绝对是。物品出现时的惊喜，以及如果你设法得到一件的兴奋，可能与你最终得到的废话一样重要或更重要。任何消除先到先得的行为都会损害“赢得”垃圾的快感。

听

novatrust：首先，我欢迎我们的新机器人霸主。实际上，我们确实提供 RSSfeeds 以允许 3rd
方应用程序扫描我们的站点以获取产品信息，但不会在主站点 HTML 之前。如果我的解释是正确的，那么您的解决方案确实通过完全牺牲目标 1 来帮助目标
2（性能问题），并且只是放弃机器人将购买大部分废话的事实。我对你的回答投了赞成票，因为你最后一段的悲观主义对我来说是准确的。这里似乎没有灵丹妙药。

其余的响应通常依赖于 IP 跟踪，这似乎既无用（僵尸网络/僵尸/云网络）又有害（捕获许多来自相同 IP 目的地的无辜者）。

还有其他方法/想法吗？我的开发人员一直在说“让我们做 CAPTCHA”，但我希望对于所有想要我们的废话的实际人类来说，有更少的侵入性方法。

原始问题

假设您正在销售具有很高感知价值的廉价商品，而您的数量非常有限。没有人确切知道您何时会出售此商品。超过 100 万人定期来看看你在卖什么。

您最终会遇到脚本编写者和机器人试图以编程方式 [a] 找出您何时出售所述物品，并 [b] 确保他们是第一批购买它的人。这很糟糕有两个原因：

1. 您的网站遭到非人类的猛烈抨击，使所有人的一切都变慢了。
2. 脚本编写者最终“赢得”了产品，导致常客感到受骗。

一个看似显而易见的解决方案是在下订单之前为您的用户创建一些跳线，但这至少存在三个问题：

• 用户体验对人类来说很糟糕，因为他们必须破译验证码、挑选猫或解决数学问题。
• 如果感知到的好处足够高，并且人群足够多，那么一些群体就会找到解决任何调整的方法，从而导致军备竞赛。（更简单的调整尤其如此；隐藏的“评论”表单、​​重新排列表单元素、错误标记它们、隐藏的“陷阱”文本都将工作一次，然后需要进行更改以对抗针对此特定表单.)
• 即使脚本编写者无法“解决”您的调整，它也不会阻止他们猛击您的首页，然后发出警报让脚本编写者手动填写订单。鉴于他们从解决 [a] 中获得了优势，他们可能仍然会赢得 [b]，因为他们将是第一个到达订单页面的人。此外，1. 仍然会发生，导致服务器错误和每个人的性能下降。

另一种解决方案是监视 IP 访问频率过高，阻止它们进入防火墙，或者以其他方式阻止它们排序。这可以解决 2. 并防止 [b] 但扫描 IP
对性能的影响是巨大的，并且可能会导致像 1. 这样的问题，而不是脚本编写者自己造成的问题。此外，云网络和垃圾邮件僵尸的可能性使 IP 检查毫无用处。

第三个想法，强制加载订单表格一段时间（比如半秒）可能会减慢快速订单的进度，但同样，脚本编写者仍然是第一个进入的人，只要速度不损害实际用户。

目标

1. 将项目出售给非脚本人员。
2. 保持网站以不被机器人减慢的速度运行。
3. 不要让“普通”用户完成任何任务来证明他们是人类。