帶寬限制結合監視及同步使用效果好。

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，配置帶寬限制，并采取主動方法來確保自身人類用戶獲得高性能且不間斷的數字體驗。