诡异爬虫

# 令人毛骨悚然的爬虫 来源：https://people.kernel.org/monsieuricon/creepy-crawlies 你可能听过我之前抱怨“AI爬虫”，但现在我确实有一些硬数据可以展示它们的影响。简而言之，其恶劣程度已造成持续的“背景辐射”式系统负载，永久占用了一部分计算能力来生成仅适用于单一目的的输出——为训练模型提供数据。 **简而言之**：我们用于为爬虫渲染提交（commits）的CPU周期，比用于所有其他合法访问（包括git克隆）的总和还要多。在任何时刻，横跨5个地理分布节点，都有14个CPU核心专门用于将git提交渲染为HTML。 CPU背景辐射 ## 为何git.kernel.org对爬虫“充满吸引力” Linux开发在开放环境中进行——从你可以克隆的git仓库，到你可以实时跟踪的讨论存档。对于大型语言模型而言，这是学习数据的宝库，因为所有这些内容不仅唾手可可得，而且容易过滤以确保获得纯净的、未经AI污染的内容。用LLM自身产生的内容来训练它，等同于让其患上数字朊病毒病。因此，当数据源能保证不含LLM内容时，比如整个内核提交历史，它作为训练数据来源就价值连城。 ## 最愚蠢的方式 我们让几乎所有东西都可以被克隆，因为——嘿——我们不可能永远存在，所以，来吧，克隆这些仓库。还有，克隆这些存档。保留一份副本，这样我们就不是唯一拥有全部数据的人了。真的，只需要一个“git clone”命令——你就能得到整个历史。 例如，你知道你可以克隆整个LKML（Linux内核邮件列表），然后随心所欲地使用它吗？这下面全都是git仓库。 那么，你会认为，一个自称“人工智能”的东西，应该会用最高效的方式来利用我们的数据进行训练，对吧？克隆仓库，遍历每个提交。搞定。 但不，事实上我们选择了最愚蠢的方式——通过逐个提交将一切渲染为HTML，然后再去解析它。 最愚蠢的方式 在撰写本文时，linux.git大约有148万次提交。哦，对了，git.kernel.org上大约有它的922个分支（fork）——但别担心，后端实际上非常高效，因为每个分支中的对象大部分是相同的。 当然，除非你是个爬虫。那样的话，你就有，哦，数十亿个有效URL可以抓取，结果只为得到相同148万次提交的922个副本——而这正是爬虫们正在做的事情。 但等等，不仅仅是提交本身。你还可以请求补丁（patch）、纯文本渲染、任意提交之间的差异（diff）——cgit很乐意提供这些。这在过去互联网属于人类或遵守robots.txt的爬虫时是很完美的，但现在则*糟糕透顶*，因为我们仅为linux.git的一个分支就能生成1.2*万亿亿*个有效URL。 linux.git有多少有效URL？ ## 屏蔽它们 最初，这是解决方案——查看日志，找出哪些IP显然是爬虫机器人，然后用fail2ban封锁它们。起初这很容易，因为机器人通过它们的用户代理（user-agent）很好心地表明了自己的身份。然后，它们变聪明了，开始伪装成普通的浏览器。 于是，我们开始按IP封锁——毕竟，很容易判断出一个试图抓取8年前已废弃的linux分支中每一个可能提交的IP，*不可能*是某个独自在Windows上使用Chrome、只是疯狂点击屏幕上出现的每个链接的用户。 机器人接着开始扩展到整个子网，但这仍然没什么大不了的，因为显然来自Google Compute的IP只是*伪装*成Firefox用户。封锁整个ASN（自治系统号）是合理的，即使这偶尔会误伤到试图自动检查提交中链接的合法实例。 ## 接下来是……你的电视？ 然后……事情变得真正、*极其*糟糕了。突然间，爬虫来自数百万个随机的住宅或移动IP，全部伪装成现代浏览器。这样一个IP会发出4-5个请求，然后就再也没在日志中出现过。封锁它们毫无意义，因为当你弄清楚它们是机器人时，它们早已结束了对你的访问。你只是徒劳地膨胀了防火墙规则集，添加了永远不会再次出现的IP。 它们像蝗虫群一样蜂拥而至，猛烈而迅速地攻击，直到系统崩溃，然后转向下一个目标，等你恢复后，它们又卷土重来。清洗，重复。 它们现在仍然在这么做——欢迎来到“代理SDK变现”的奇妙世界。这是个大生意，而*你的电视*很可能就在参与其中 (https://spur.us/blog/smart-tv-apps-residential-proxy-sdk)。 ## 让它们付出代价 大约一年前，当这问题首次出现时，我们天真地以为有什么办法能让它停止。只需让机器人执行一项任务，这项任务会颠倒整个事情的经济性，让它们浪费一些计算周期在一次性计算上。比如，计算某个字符串，当与它们自己的IP和我们提供的一个密钥组合后，能生成一个前导零为4个的sha256哈希值。 换句话说，我们在所有东西前面放上了Anubis (https://anubis.techaro.lol/)。 Anubis 挑战难度图表 它立即变得极其有效——机器人直接放弃了。有那么几个月，真是幸福时光：机器人被阻拦在外围，放弃了，转向更容易的目标；用户虽然*有点恼火*但容忍了它，而且Anubis堆栈很容易部署到各处。 几个月后，机器人回来了，能够解决难度为4的挑战。没关系，我们说，把难度提高到5。 合法用户现在更加烦恼了。在移动设备上解决难度5的问题需要几秒钟，手机在进行数字运算时会变得异常发热。然而，这很有效，为我们买来了几个月的安宁。 然后……机器人开始能解决难度5的挑战了。 ## 我们目前的状况 git.kernel.org 请求剖析 如今，git.kernel.org每天大约收到600万个请求，要求查看随机提交。其中，66%仍然被Anubis挑战立即拦截，但33%现在能解决数学问题并成功访问主站——因为显然，我们提供的内容值得它们花费大量计算周期来解决Anubis挑战。 无法确切区分这些请求中哪些是机器人，哪些是真实人类——但可能性是，如果它请求的是某个随机旧分支中的旧提交，那它*很可能*不是在做实际工作的真正开发者。 在一系列乐观的假设下，合法请求仅占git.kernel.org流量的约2%——其他所有都是爬虫。 ## 情况有多糟？ 请求数 vs. 数据量 就目前而言，我们还没有完全不堪重负——如果你访问git.kernel.org，它*很可能*仍然响应迅速。通常让我们宕机的不是爬虫机器人，而是设计不佳的CI系统，它们试图做一些愚蠢的事情，比如同时从20个不同的节点对stable.git进行浅克隆。（浅克隆很糟糕。如果你打算做这种费事的操作，请搭建自己的镜像。） 然而，你应该知道，在横跨5个地理分布节点的总共90个核心中，有14-16个核心持续不断地只为爬虫渲染提交。平均而言，这占用了我们总容量的20%——只不过蜂群是波浪式来袭，实际曲线远比一条20%的平线要波动剧烈得多。 ## 这把我们置于何地？ 尚不确定。也许AI泡沫破裂，我们突然发现外面试图训练其模型的实体大幅减少。或者，也许它们学聪明了，不再以最愚蠢的方式消费我们的数据。 至于我们正在做的，我们正在关闭一些功能，以减少可被抓取的URL数量，并对运行成本高昂的操作设置门槛。预计会失去一些功能，尤其是在匿名访问我们的资源时。相信我，我们也和你一样讨厌这样做，但此刻这是必要的。 最糟糕的是，这个问题没有简单的解决方案。提供定制“AI”模型的公司每天仍在涌现，它们都渴望训练数据。应用开发者仍在寻找盈利途径，因此会继续将你的家用电器变成攻击载体。 话虽如此，我们承诺仍会向所有请求者提供我们的全部数据下载。只是你可能需要经历更多步骤才能获取它。 抱歉。（加拿大人必说的场面话。）