帶寬限制結(jié)合監(jiān)視及同步使用效果好。

NGINX 產(chǎn)品管理總監(jiān) Liam Crilly 寫道，對網(wǎng)站或應(yīng)用這樣的聯(lián)網(wǎng)數(shù)字體驗而言，響應(yīng)性和擴(kuò)展性就是一切。但即便身處計算資源可按需實時擴(kuò)展的云彈性時代，當(dāng)人類點擊可被自動化機(jī)器人程序代為執(zhí)行的時候，也很難確保計算資源的高性能了。

互聯(lián)網(wǎng)時代，機(jī)器人程序不算什么新鮮事物。最早的機(jī)器人程序于 1988 年左右出現(xiàn)在互聯(lián)網(wǎng)中繼聊天 （IRC） 頻道中，數(shù)年間便因搜索引擎用其索引網(wǎng)站而成為該互聯(lián)網(wǎng)操作的主力工具。

1995 年，AOL 使用 WebCrawler，此后，1996 年，谷歌創(chuàng)建了 Googlebot （正式名稱為 BackRub）。但早期機(jī)器人程序卻未必總是出于盈利的目的。1999 年，木馬程序 Sub7 和蠕蟲程序 Pretty Park 就被釋放到了 IRC 中，秘密感染接入特定 IRC 頻道的計算機(jī)，通過該信道監(jiān)聽指令。

隨著機(jī)器人程序代碼愈趨復(fù)雜，其應(yīng)用也越來越邪惡。有時候機(jī)器人程序會被嵌入軟件中或作為獨立應(yīng)用（比如 GTbot）安裝，黑客開始連接各個機(jī)器人程序組建 “僵尸網(wǎng)絡(luò)”，針對特定網(wǎng)絡(luò)資源發(fā)起協(xié)同攻擊，以批量虛假請求洪水致癱目標(biāo)網(wǎng)絡(luò)資源。2007 年，別名 “Storm” 的大型僵尸網(wǎng)絡(luò)感染了約 5，000 萬臺計算機(jī)，在黑客操縱下進(jìn)行股價欺詐和身份盜竊等一系列犯罪行為。另外，機(jī)器人程序和僵尸網(wǎng)絡(luò)還有一項最令人痛恨的自動化攻擊行為——垃圾郵件。2009 年，名為 “Cutwail” 的僵尸網(wǎng)絡(luò)被用于每天發(fā)送多達(dá) 740 億封電子郵件。

但歸根結(jié)底，機(jī)器人程序本身并無善惡之分，壞人手里就是作惡工具，好人手里就是效率提升工具。它們不過是可以自動化重復(fù)性任務(wù)的聰明程序而已。是好是壞只看你怎么使用。如果是為搜索引擎爬取網(wǎng)站，它們就是十分趁手的工具。你能想象純靠人力挨個訪問網(wǎng)站，并將所有網(wǎng)頁索引至可提供搜索服務(wù)的數(shù)據(jù)庫中嗎？或者，脫開搜索引擎上網(wǎng)？想想都覺得不可能。那么，如果機(jī)器人程序本意不想為害，但卻仍造成了傷害，會是什么樣子呢？比如說，從網(wǎng)頁刮取數(shù)據(jù)。機(jī)器人程序并非意圖搞癱網(wǎng)站，但又確實在消耗服務(wù)器資源，而且程度達(dá)到了嚴(yán)重影響對人類用戶的響應(yīng)度和服務(wù)性能的地步。當(dāng)網(wǎng)站或應(yīng)用可以通過 AWS 等云提供商自動增加資源實現(xiàn)彈性擴(kuò)展，失控機(jī)器人程序刮取網(wǎng)頁的行為就有可能造成災(zāi)難性的資金影響了。

互聯(lián)網(wǎng)服務(wù)提供商、內(nèi)容交付網(wǎng)絡(luò)和 IT 部門有一系列動作可以限制機(jī)器人程序的行為。很多情況下，網(wǎng)絡(luò)運營商試圖檢測機(jī)器人程序流量并阻止之，比如對機(jī)器人程序的資源請求回復(fù) 400 響應(yīng)。但很多機(jī)器人程序是無法被這種方法遏制的，它們常會實時切換 IP 地址以規(guī)避此類網(wǎng)絡(luò)封鎖。簡言之，面對機(jī)器人程序，“抵抗是徒勞的”。它們總會找到通往所需資源的路徑，影響終端用戶的體驗。

盡管沒什么萬能的方法可以挫敗機(jī)器人程序流量，但帶寬限制這種獨特的方法還是可以有所貢獻(xiàn)的。網(wǎng)絡(luò)運營商對機(jī)器人程序?qū)嵤┧俾氏拗茣r（也就是對來自特定 IP 的請求數(shù)量設(shè)上限），機(jī)器人程序會通過別的路徑獲取到自己想要的資源。速率限制很容易被機(jī)器人程序檢測出來。但面對更難以檢測的帶寬限制，機(jī)器人程序可以采用的通道就相當(dāng)窄了，無論它們發(fā)出多少請求。這種情況下，只要檢測到機(jī)器人程序流量，攻擊 IP 就會被發(fā)配“受罰席”，無論它們發(fā)出多少請求，都只能收到非常慢的響應(yīng)。大英圖書館就是 NGINX 用于管理機(jī)器人程序流量的一個樣例。該圖書館每天收到 1，100 萬瀏覽器請求，每小時處理高達(dá) 7，000 個搜索請求。在網(wǎng)絡(luò)爬蟲和其他機(jī)器人程序流量持續(xù)上升，已升至超出網(wǎng)站總請求量 10% 占比的情況下，大英圖書館知道自己必須擁有一套應(yīng)對此類流量的解決方案。NGINX 為他們提供了緩解該問題的一套方法，可以降低機(jī)器人程序流量對人類網(wǎng)站訪問者訪問體驗的影響。

但這還不是機(jī)器人程序流量控制問題的全貌。盡管帶寬限制是個有力工具，其功效要與其他兩種方法配合使用才能得到充分發(fā)揮。帶寬限制只有與監(jiān)視及同步聯(lián)動，才可以提供層次化的解決方案。監(jiān)視功能可以使用戶通過 API 終端獲取 “受罰席” 直觀視圖，看清有多少請求和 IP 地址被隔離。不用再從令人眼花的日志中費力查找。

但真正在機(jī)器人程序?qū)箲?zhàn)中發(fā)揮巨大功用的，是數(shù)據(jù)同步。NGINX 隔離出來的機(jī)器人程序流量在所有 NGINX 安裝實例間共享，打造全球反僵尸網(wǎng)絡(luò)戰(zhàn)線，是一種主動式而非響應(yīng)式的機(jī)器人程序流量緩解方法。這就讓 NGINX 的服務(wù)不僅僅是負(fù)載平衡器、反向代理、API 網(wǎng)關(guān)和強(qiáng)大而全面的互聯(lián)網(wǎng)服務(wù)平臺，還是針對日益嚴(yán)峻的機(jī)器人程序流量問題的獨特解決方案。與其急于解決無法根除的問題，DevOps 和網(wǎng)絡(luò)運營團(tuán)隊不如部署 NGINX，配置帶寬限制，并采取主動方法來確保自身人類用戶獲得高性能且不間斷的數(shù)字體驗。