由於搜索引擎網站的流行，網絡爬行動物已經成了很普及網絡技術，除開專門做搜索的Google，Yahoo，微軟，百度之外，幾乎每個大型門戶網站都有自個兒的搜索引擎網站，大體積小叫得出來姓名得就幾十種，還有各種不知名的幾千幾萬種，對於一個內部實質意義型驅動的網站來說，遭受網絡爬行動物的敬辭是必然性的。
一點智能的搜索引擎網站爬行動物的爬取頻率比較合理，對網站資源耗費比較少，不過眾多糟糕的網絡爬行動物，對網頁爬取有經驗很差，常常並發幾十上百個煩請循環重復抓取，這種爬行動物對中小規模網站往往是摧毀性打壓，尤其是一點匱缺爬行動物編著經驗的程序開發人員開具來的爬行動物毀傷力極強。以前有一次我在JavaEye的日記裡邊發覺一個User-Agent是Java的爬行動物一天之內爬取了將近100萬次動態煩請。這是一個用JDK標准類庫編著的簡單爬取網頁手續，因為JavaEye網站內裡鏈接構成了曲折環繞造成手續陷於了死循環。對於JavaEye這種一百萬PV級別的網站來說，這種爬行動物導致的過訪壓力會很大，會造成網站過訪速度不迅速，甚至於沒有辦法過訪。
這個之外，相當數目的的網頁爬行動物目標是盜取目的網站的內部實質意義。比喻說JavaEye網站就以前被兩個競爭對手網站爬取論壇帖子，而後在自個兒的論壇裡邊用機器人發帖，因為這個這種爬行動物不止只影響網站過訪速度，並且進犯了網站的版權。
對於一個原創內部實質意義浩博，URL結構合理便於爬取的網站來說，簡直就是各種爬行動物的盤中大餐，眾多網站的過訪流量構成之中，爬行動物帶來的流量要遠遠超過真實用戶過訪流量，甚至於爬行動物流量要凌駕真實流量一個數目級。像JavaEye網站固然設置了相當嚴明的反爬行動物策略，不過網站處置的動態煩請數目還是是真實用戶過訪流量的2倍。可以肯定的說，當今互聯網的網絡流量至少有2/3的流量爬行動物帶來的。因為這個反爬行動物是一個值當網站長時期考求和解決的問題。
一、手工辨別和不接受爬行動物的過訪
有相當多的爬行動物對網站會導致十分高的負載，因為這個辨別爬行動物的出處IP是很容易的事物。最簡單的方法就是用netstat查緝80端口的連署：
netstat -nt grep youhostip:80 awk ‘{print $5}’ awk -F: ‘{print $1}’ sort uniq -c sort -r -n
這行shell可以依照80端口連署數目對出處IP施行排序，這麼可以直觀的判斷出來網頁爬行動物。普通來說爬行動物的並發連署十分高。
假如運用lighttpd做Web Server，那末就更簡單了。lighttpd的mod_status供給了十分直觀的並發連署的信息，涵蓋每個連署的出處IP，過訪的URL，連署狀況和連署時間等信息，只要查緝那一些處於handle-request狀況的高並發IP就可以很快確認爬行動物的出處IP了。
不接受爬行動物煩請既可以經過內核防火牆來不接受，也可以在web server不接受，比喻說用iptables不接受：
iptables -A INPUT -i eth0 -j DROP -p tcp –dport 80 -s 84.80.46.0/24
直接封鎖爬行動物存在的地方的C網段地址。這是由於普通爬行動物都是運行在托管機房裡邊，有可能在一個C段裡邊的多臺服務器上頭都有爬行動物，而這個C段沒可能是用戶寬帶上網，封鎖C段可以非常大程度上解決問題。
有點人提出一種腦殘的觀點，說我要辦罪這些個爬行動物。我專門在網頁裡邊預設動態循環鏈接頁面，讓爬行動物掉進陷坑，死循環爬不出來，實際上根本不待設置陷坑，弱智爬行動物對正常網頁自個兒就爬不出來，這麼做畫蛇添足不說，並且會讓真正的搜索引擎網站減低你的網頁名次。並且運行一個爬行動物根本不需要耗啥子機器資源，相反，真正珍貴的是你的服務器CPU資源和服務器帶寬，簡單的不接受掉爬行動物的煩請是反爬行動物最管用的策略。二、經過辨別爬行動物的User-Agent信息來不接受爬行動物
有眾多爬行動物並不會以頎長的並發seo連署爬取，普通不由得易顯露自個兒;有點爬行動物的出處IP散布很廣，很難簡單的經過封鎖IP段地址來解決問題;額外還有眾多五花八門的小爬行動物，他們在試驗Google之外創新的搜索形式，每個爬行動物每日爬取幾萬的網頁，幾十個爬行動物加起來每日就能耗費掉上一百萬動態煩請的資源，因為每個小爬行動物單獨的爬取量都很低，所以你很難把它從每日海量的過訪IP地址之中把它正確的挖出來。
這種事情狀況下我們可以經過爬行動物的User-Agent信息來辨別。每個爬行動物在爬取網頁的時刻，會聲明自個兒的User-Agent信息，因為這個我們就可以經過記錄和剖析User-Agent信息來開鑿和封鎖爬行動物。我們需求記錄每個煩請的User-Agent信息，對於Rails來說我們可以簡單的在app/controllers/application.rb裡邊添加一個整個的局面：胸懷～的before_filter，來記錄每個煩請的User-Agent信息：
logger.info HTTP_USER_AGENT #{request.env[HTTP_USER_AGENT]}
而後計數每日的production.log，取出User-Agent信息，找出過訪量最大的那一些User-Agent。要注意的是我們只關心注視那一些爬行動物的User-Agent信息，而不是真正瀏覽器User-Agent，所以還要排洗雪瀏覽器User-Agent，要做到這一點兒僅只需求一行shell：
grep HTTP_USER_AGENT production.log grep -v -E ‘MSIEFirefoxChromeOperaSafariGecko’ sort uniq -c sort -r -n head -n 100 > bot.log
計數最後結果大致相似這麼：
57335 HTTP_USER_AGENT Baiduspider+(+)
42610 HTTP_USER_AGENT Mediapartners-Google
19131 HTTP_USER_AGENT msnbot/2.0b (+ )
}
運用這種形式來封鎖爬行動物固然簡單不過十分管用，除開封鎖特別指定的爬行動物，還可以封鎖常用的編程語講和HTTP類庫的User-Agent信息，這麼就可以防止眾多沒有意義的程序開發人員用來練手的爬行動物手續對網站的擾亂。
還有一種比較常見的事情狀況，就是某個搜索引擎網站的爬行動物對網站爬取頻率過高，不過搜索引擎網站給網站帶來了眾多流量，我們並不期望簡單的封鎖爬行動物，僅只是期望減低爬行動物的煩請頻率，減緩爬行動物對網站導致的負載，那末我們可以這麼做：
$HTTP[user-agent] =~ Baiduspider+ {
connection.delay-seconds = 10
}
對百度的爬行動物煩請延緩10秒鍾再施行處置，這麼就可以管用減低爬行動物對網站的負載了。
三、經過網站流量計數系統和日記剖析來辨別爬行動物
有點爬行動物喜歡改正User-Agent信息來假裝自個兒，把自個兒假裝成一個真實瀏覽器的User-Agent信息，讓你沒有辦法管用的辨別。這種事情狀況下我們可以經過網站流量系統記錄的真實用戶過訪IP來施行辨別。
主流的網站流量計數系統不外兩種成功實現策略：一種策略是在網頁裡邊鑲嵌一段js，這段js會向特別指定的計數服務器送出煩請的形式記錄過訪量;另一種策略是直接剖析服務器日記，來計數網站過訪量。有理想的事情狀況下，鑲嵌js的形式計數的網站流量應當高於剖析服務器日記，這是由於用戶瀏覽器會有緩存，不盡然每每真實用戶過訪都會被觸動引發服務器的處置。但實際事情狀況是，剖析服務器日記獲得的網站過訪量遠遠高於鑲嵌js形式，極度事情狀況下，甚至於要凌駕10倍以上。
如今眾多網站喜歡認為合適而使用awstats來剖析服務器日記，來計算網站的過訪量，不過當它們一朝認為合適而使用Google Analytics來計數網站流量的時刻，卻發覺GA計數的流量遠遠低於awstats，為何GA和awstats計數會有偌大差別呢?罪魁元凶就是把自個兒假裝成瀏覽器的網絡爬行動物。這種事情狀況下awstats沒有辦法管用的辨別了，所以awstats的計數數值會虛高。
實際上作為一個網站來說，假如期望理解自個兒的網站真實過訪量，期望非常准確理解網站每個頻帶的過訪量和過訪用戶，應當用頁面裡邊鑲嵌js的形式來研發自個兒的網站流量計數系統。自個兒做一個網站流量計數系統是件很簡單的事物，寫段服務器手續響應客戶段js的煩請，剖析和辨別煩請而後寫日記的同時做後臺的異步計數就擺平了。
經過流量計數系統獲得的用戶IP基本是真實的用戶過訪，由於普通事情狀況下爬行動物是沒有辦法執行網頁裡邊的js代碼斷片的。所以我們可以拿流量計數系統記錄的IP和服務器手續日記記錄的IP地址施行比較，假如服務器日記裡邊某個IP發起了數量多的煩請，在流量計數系統裡邊卻根本找不到，還是縱然找獲得，可過訪量卻只有非常少幾個，那末沒有疑問就是一個網絡爬行動物。
剖析服務器日記計數過訪最多的IP地址段一行shell就可以了：
grep Processing production.log awk ‘{print $4}’ awk -F’.’ ‘{print $1.$2.$3.0}’ sort uniq -c sort -r -n head -n 200 > stat_ip.log
而後把計數最後結果和流量計數系統記錄的IP地址施行相比較，擯除真實用戶過訪IP，再擯除我們期望准許通過的網頁爬行動物，比喻Google，百度，微軟msn爬行動物等等。最終的剖析最後結果就就獲得了爬行動物的IP地址了。以下代碼段是個簡單的成功實現表示意思：
whitelist = []
IO.foreach(#{RAILS_ROOT}/lib/whitelist.txt) { line whitelist << line.split[0].strip if line }
realiplist = []
IO.foreach(#{RAILS_ROOT}/log/visit_ip.log) { line realiplist << line.strip if line }
iplist = []
IO.foreach(#{RAILS_ROOT}/log/stat_ip.log) do line
ip = line.split[1].strip
iplist << ip if line.split[0].to_i > 3000 && !whitelist.include?(ip) && !realiplist.include?(ip)
end
Report.deliver_crawler(iplist)
剖析服務器日記裡邊煩請回數超過3000次的IP地址段，擯除白單子地址和真實過訪IP地址，最終獲得的就是爬行動物IP了，而後可以送出郵件通告管理員施行相應的處置。
四、網站的實時反爬行動物防火牆成功實現策略
通不為己甚析日記的形式來辨別網頁爬行動物不是一個實時的反爬行動物策略。假如一個爬行動物非要針對你的網站施行費盡心機的爬取，那末他有可能會認為合適而使用散布式爬取策略，比喻說尋覓幾百上千個海外的攝理服務器發瘋的爬取你的網站，因此造成網站沒有辦法過訪，那末你再剖析日記是沒可能趁早解決問題的。所以務必采取實時反爬行動物策略，要能夠動態的實時辨別和封鎖爬行動物的過訪。
要自個兒編著一個這麼的實時反爬行動物系統實際上也很簡單。比喻說我們可以用memcached來做過訪統計器，記錄每個IP的過訪頻度，在單位時間之內，假如過訪頻率超過一個閥值，我們就覺得這個IP很有可能有問題，那末我們就可以回返一個證驗碼頁面，要求用戶填寫證驗碼。若是爬行動物的話，當然沒可能填寫證驗碼，所以就被拒掉了，這麼很簡單就解決了爬行動物問題。
用memcache記錄每個IP過訪統計，單位時間內超過閥值就讓用戶填寫證驗碼，用Rails編著的舉出例子代碼如下所述：
ip_counter = Rails.cache.increment(request.remote_ip)
if !ip_counter
Rails.cache.write(request.remote_ip, 1, :expires_in => 30.minutes)
elsif ip_counter > 2000
render :template => ‘test’, :status => 401 and return false
end
這段手續只是最簡單的舉出例子，實際的代碼成功實現我們還會添加眾多判斷，比喻說我們有可能要擯除白單子IP地址段，要准許特別指定的User-Agent經過，要針對登錄用戶和非登錄用戶，針對有無referer地址采取不一樣的閥值和統計加速器等等。
這個之外假如散布式爬行動物爬取頻率過高的話，超過期限就准許爬行動物再次過訪仍然會對服務器導致非常大的壓力，因為這個我們可以添加一條策略：針對要求用戶填寫證驗碼的IP地址，假如該IP地址瞬息間內不止的煩請，則判斷為爬行動物，參加黑單子，後續煩請所有不接受掉。為此，舉出例子代碼可以改進一下子：
before_filter :ip_firewall, :except => :test
def ip_firewall
render :file => #{RAILS_ROOT}/public/403.html, :status => 403 if BlackList.include?(ip_sec)
end
我們可以定義一個整個的局面：胸懷～的過淋器，對全部煩請施行過淋，顯露出來在黑單子的IP地址一例不接受。對非黑單子的IP地址再施行統計和計數：
ip_counter = Rails.cache.increment(request.remote_ip)
if !ip_counter
Rails.cache.write(request.remote_ip, 1, :expires_in => 30.minutes)
elsif ip_counter > 2000
crawler_counter = Rails.cache.increment(crawler/#{request.remote_ip})
if !crawler_counter
Rails.cache.write(crawler/#{request.remote_ip}, 1, :expires_in => 10.minutes)
elsif crawler_counter > 50
BlackList.add(ip_sec)
render :file => #{RAILS_ROOT}/public/403.html, :status => 403 and return false
end
render :template => ‘test’, :status => 401 and return false
end
假如某個IP地址單位時間內過訪頻率超過閥值，再增加一個統計器，跟蹤他會不會馬上填寫證驗碼，假如他不填寫證驗碼，在瞬息間內仍然高頻率過訪，就把這個IP地址段參加黑單子，錯非用戶填寫證驗碼拿獲，否則全部煩請所有不接受。這麼我們就可以經過在手續裡邊保護黑單子的形式來動態的跟蹤爬行動物的事情狀況，甚至於我們可以自個兒寫個後臺來手工管理黑單子列表，理解網站爬行動物的事情狀況。
這個策略已經比較智能了，不過還不夠好!我們還可以接著改進：
1、用網站流量計數系統來改進實時反爬行動物系統
還想的起來嗎?網站流量計數系統記錄的IP地址是真實用戶過訪IP，所以我們在網站流量計數系統裡邊也去操作memcached，不過這次不是增加統計值，而是減損統計值。在網站流量計數系統裡邊每收繳到一個IP煩請，就相應的cache.decrement(key)。所以對於真實用戶的IP來說，它的統計值老是加1而後就減1，沒可能頎長。這麼我們就可以大大減低判斷爬行動物的閥值，可以更加迅速正確的辨別和不接受掉爬行動物。
2、用時間窗戶來改進實時反爬行動物系統
爬行動物爬取網頁的頻率都是比較固定的，不像人去過訪網頁，半中腰的間隔時間比較無規則，所以我們可以給每個IP地址樹立一個時間窗戶，記錄IP地址近來12次過訪時間，每記錄一次就滑動一次窗戶，比較近來過訪時間和現時時間，假如間隔時間很長判斷不是爬行動物，掃除淨盡時間窗戶，假如間隔不久，就回顧計算指定時間段的過訪頻率，假如過訪頻率超過閥值，就轉向證驗碼頁面讓用戶填寫證驗碼。
最後這個實時反爬行動物系統就相當完備了，它可以很快的辨別況且半自動封鎖爬行動物的過訪，盡力照顧網站的正常過訪。然而有點爬行動物有可能相當詭計多端，它或許融會貫通過數量多的爬行動物測試來試著探索出來你的過訪閥值，以低於閥值的爬取速度抓取你的網頁，因為這個我們還需求匡助第3種方法，用日記來做後期的剖析和辨別，就算爬行動物爬的再慢，它總計一天的爬取量也會超過你的閥值被你日記剖析手續辨別出來。
總之我們綜合使用上頭的四種反爬行動物策略，可以非常大程度上緩解爬行動物對網站導致的負面影響，保障網站的正常過訪。