NGINX机器人程序流量缓解 减少不想要的Web流量

带宽限制结合监视及同步使用效果好。

NGINX 产品管理总监 Liam Crilly 写道，对网站或应用这样的联网数字体验而言，响应性和扩展性就是一切。但即便身处计算资源可按需实时扩展的云弹性时代，当人类点击可被自动化机器人程序代为执行的时候，也很难确保计算资源的高性能了。

互联网时代，机器人程序不算什么新鲜事物。最早的机器人程序于 1988 年左右出现在互联网中继聊天 (IRC) 频道中，数年间便因搜索引擎用其索引网站而成为该互联网操作的主力工具。

1995 年，AOL 使用 WebCrawler，此后，1996 年，谷歌创建了 Googlebot （正式名称为 BackRub）。但早期机器人程序却未必总是出于盈利的目的。1999 年，木马程序 Sub7 和蠕虫程序 Pretty Park 就被释放到了 IRC 中，秘密感染接入特定 IRC 频道的计算机，通过该信道监听指令。

随着机器人程序代码愈趋复杂，其应用也越来越邪恶。有时候机器人程序会被嵌入软件中或作为独立应用（比如 GTbot）安装，黑客开始连接各个机器人程序组建 “僵尸网络”，针对特定网络资源发起协同攻击，以批量虚假请求洪水致瘫目标网络资源。2007 年，别名 “Storm” 的大型僵尸网络感染了约 5,000 万台计算机，在黑客操纵下进行股价欺诈和身份盗窃等一系列犯罪行为。另外，机器人程序和僵尸网络还有一项最令人痛恨的自动化攻击行为——垃圾邮件。2009 年，名为 “Cutwail” 的僵尸网络被用于每天发送多达 740 亿封电子邮件。

但归根结底，机器人程序本身并无善恶之分，坏人手里就是作恶工具，好人手里就是效率提升工具。它们不过是可以自动化重复性任务的聪明程序而已。是好是坏只看你怎么使用。如果是为搜索引擎爬取网站，它们就是十分趁手的工具。你能想象纯靠人力挨个访问网站，并将所有网页索引至可提供搜索服务的数据库中吗？或者，脱开搜索引擎上网？想想都觉得不可能。那么，如果机器人程序本意不想为害，但却仍造成了伤害，会是什么样子呢？比如说，从网页刮取数据。机器人程序并非意图搞瘫网站，但又确实在消耗服务器资源，而且程度达到了严重影响对人类用户的响应度和服务性能的地步。当网站或应用可以通过 AWS 等云提供商自动增加资源实现弹性扩展，失控机器人程序刮取网页的行为就有可能造成灾难性的资金影响了。

互联网服务提供商、内容交付网络和 IT 部门有一系列动作可以限制机器人程序的行为。很多情况下，网络运营商试图检测机器人程序流量并阻止之，比如对机器人程序的资源请求回复 400 响应。但很多机器人程序是无法被这种方法遏制的，它们常会实时切换 IP 地址以规避此类网络封锁。简言之，面对机器人程序，“抵抗是徒劳的”。它们总会找到通往所需资源的路径，影响终端用户的体验。

尽管没什么万能的方法可以挫败机器人程序流量，但带宽限制这种独特的方法还是可以有所贡献的。网络运营商对机器人程序实施速率限制时（也就是对来自特定 IP 的请求数量设上限），机器人程序会通过别的路径获取到自己想要的资源。速率限制很容易被机器人程序检测出来。但面对更难以检测的带宽限制，机器人程序可以采用的通道就相当窄了，无论它们发出多少请求。这种情况下，只要检测到机器人程序流量，攻击 IP 就会被发配“受罚席”，无论它们发出多少请求，都只能收到非常慢的响应。大英图书馆就是 NGINX 用于管理机器人程序流量的一个样例。该图书馆每天收到 1,100 万浏览器请求，每小时处理高达 7,000 个搜索请求。在网络爬虫和其他机器人程序流量持续上升，已升至超出网站总请求量 10% 占比的情况下，大英图书馆知道自己必须拥有一套应对此类流量的解决方案。NGINX 为他们提供了缓解该问题的一套方法，可以降低机器人程序流量对人类网站访问者访问体验的影响。

但这还不是机器人程序流量控制问题的全貌。尽管带宽限制是个有力工具，其功效要与其他两种方法配合使用才能得到充分发挥。带宽限制只有与监视及同步联动，才可以提供层次化的解决方案。监视功能可以使用户通过 API 终端获取 “受罚席” 直观视图，看清有多少请求和 IP 地址被隔离。不用再从令人眼花的日志中费力查找。

但真正在机器人程序对抗战中发挥巨大功用的，是数据同步。NGINX 隔离出来的机器人程序流量在所有 NGINX 安装实例间共享，打造全球反僵尸网络战线，是一种主动式而非响应式的机器人程序流量缓解方法。这就让 NGINX 的服务不仅仅是负载平衡器、反向代理、API 网关和强大而全面的互联网服务平台，还是针对日益严峻的机器人程序流量问题的独特解决方案。与其急于解决无法根除的问题，DevOps 和网络运营团队不如部署 NGINX，配置带宽限制，并采取主动方法来确保自身人类用户获得高性能且不间断的数字体验。