互聯網網站的反爬蟲策略淺析

仲介交易 SEO診斷 淘寶客 雲主機 技術大廳

因為搜尋引擎的流行，網路爬蟲已經成了很普及網路技術，除了專門做搜索的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資訊來拒絕爬蟲

有很多爬蟲並不會以很高的併發連接爬取，一般不容易暴露自己;有些爬蟲的來源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 'MSIE| Firefox| Chrome| Opera| Safari| Gecko' | sort | uniq -c | sort -r -n | head -n 100 > bot.log

統計結果類似這樣：

57335 HTTP_USER_AGENT Baiduspider+(+HTTP://www.baidu.com/search/spider.htm)

56639 HTTP_USER_AGENT Mozilla/5.0 (compatible; Googlebot/2.1; +HTTP://www.google.com/bot.html)

42610 HTTP_USER_AGENT Mediapartners-Google

19131 HTTP_USER_AGENT msnbot/2.0b (+HTTP://search.msn.com/msnbot.htm)

從日誌就可以直觀的看出每個爬蟲的請求次數。 要根據User-Agent資訊來封鎖爬蟲是件很容易的事情，ligHTTPd配置如下：

$HTTP["useragent"] =~ "qihoobot|^JAVA| Commons-HttpClient| Wget|^PHP| Ruby| Python" {

url.rewrite = ( "^/(.*)" => "/crawler.html" )

}

使用這種方式來封鎖爬蟲雖然簡單但是非常有效，除了封鎖特定的爬蟲，還可以封鎖常用的程式設計語言和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種辦法，用日誌來做後期的分析和識別，就算爬蟲爬的再慢， 它累計一天的爬取量也會超過你的閥值被你日誌分析程式識別出來。

總之我們綜合運用上面的四種反爬蟲策略，可以很大程度上緩解爬蟲對網站造成的負面影響，保證網站的正常訪問。