1. 程式人生 > >爬蟲,反爬蟲和反反爬蟲

爬蟲,反爬蟲和反反爬蟲

轉自:https://blog.csdn.net/yixuandong9010/article/details/75861233

隨之大資料的火熱,網路上各種網頁抓取/爬蟲工具蜂擁而來,因而,網頁資料成了大家競爭掠奪的資源,但網站運營者卻要開始保護自己的資料資源,以避免被競爭對手獲取到自己的資料,防止更大的商業損失。下面總結一下反爬蟲策略及其應對方法。 一、什麼是爬蟲和反爬蟲

一張圖說明一切:

爬蟲和反爬蟲作為相生相剋的死對頭,無論爬蟲多厲害,都是能被複雜的反爬蟲機制發現,同樣的,無論反爬蟲機制多麼縝密,都是能被高階的網路爬蟲所攻破,勝負的關鍵就看雙方的資源投入多少了。為了更好地理解爬蟲和反爬蟲機制,下面有一些定義:

爬蟲:使用任何技術手段,批量獲取網站資訊的一種方式。關鍵在於批量。

反爬蟲:使用任何技術手段,阻止別人批量獲取自己網站資訊的一種方式。關鍵也在於批量。

誤傷:在反爬蟲的過程中,錯誤的將普通使用者識別為爬蟲。誤傷率高的反爬蟲策略,效果再好也不能用。

攔截:成功地阻止爬蟲訪問。這裡會有攔截率的概念。通常來說,攔截率越高的反爬蟲策略,誤傷的可能性就越高。因此需要做個權衡。

所以,我們可以知道,爬蟲有一個最基本的特徵就是批量,而反爬蟲機制也是根據這個特徵來做判斷的,但反爬蟲還是一個權衡利弊的選擇,既要較低的誤傷率,又要較高的攔截率,這也是它的漏洞。關於網站為什麼以及如何制定反爬蟲策略,可以看攜程酒店技術部總結的關於反爬蟲的心得體會。

二、反爬蟲方法及其應對

一般網站從三個方面反爬蟲:請求網站訪問時的請求頭Headers,使用者行為,目標網站的目錄和資料載入方式。前兩個方面可以說是反爬蟲策略中最為常見的,而第三個則是應用ajax(非同步載入)的方式載入頁面目錄或者內容,增大爬蟲在對目標網站形成訪問之後獲取資料的難度。
但是僅僅檢驗一下請求頭或者做幾個ip限制顯然無法達到網站運營者對anti-spam的要求,所以更進一步的反制措施也不少。最主要的大概有:Cookie限制,驗證碼反爬蟲,以及Noscript。

2.1 通過Headers反爬蟲
從使用者請求的Headers反爬蟲是最常見的反爬蟲策略。由於正常使用者訪問網站時是通過瀏覽器訪問的,所以目標網站通常會在收到請求時校驗Headers中的User-Agent欄位,如果不是攜帶正常的User-Agent資訊的請求便無法通過請求。還有一部分網站為了防盜鏈,還會校驗請求Headers中的Referer欄位。 如果遇到了這類反爬蟲機制,可以直接在自己寫的爬蟲中新增Headers,將瀏覽器的User-Agent複製到爬蟲的Headers中;另外通過對請求的抓包分析,將Referer值修改為目標網站域名,就能很好的繞過。
2.2 基於使用者行為反爬蟲
還有一些網站會通過使用者的行為來檢測網站的訪問者是否是爬蟲,例如同一IP短時間內多次訪問同一頁面,或者同一賬戶短時間內多次進行相同操作。 大多數網站都是前一種情況,對於這種情況有兩種策略:
1)使用代理ip。例如可以專門寫一個在網上抓取可用代理ip的指令碼,然後將抓取到的代理ip維護到代理池中供爬蟲使用,當然,實際上抓取的ip不論是免費的還是付費的,通常的使用效果都極為一般,如果需要抓取高價值資料的話也可以考慮購買寬頻adsl撥號的VPS,如果ip被目標網站被封掉,重新撥號即可。
2)降低請求頻率。例如每個一個時間段請求一次或者請求若干次之後sleep一段時間。由於網站獲取到的ip是一個區域網的ip,該ip被區域內的所有人共享,因此這個間隔時間並不需要特別長
對於第二種情況,可以在每次請求後隨機間隔幾秒再進行下一次請求。對於有邏輯漏洞的網站,可以通過請求幾次,退出登入,重新登入,繼續請求來繞過同一賬號短時間內不能多次進行相同請求的限制,如果能有多個賬戶,切換使用,效果更佳。
2.3 動態頁面的反爬蟲
上述的幾種情況大多都是出現在靜態頁面,但是對於動態網頁,我們需要爬取的資料是通過ajax請求得到,或者通過JavaScript生成的。首先用Firebug或者HttpFox對網路請求進行分析。如果能夠找到ajax請求,也能分析出具體的引數和響應的具體含義,我們就能採用上面的方法,直接利用requests或者urllib2模擬ajax請求,對響應的json進行分析得到需要的資料。
能夠直接模擬ajax請求獲取資料固然是極好的,但是有些網站把ajax請求的所有引數全部加密了。我們根本沒辦法構造自己所需要的資料的請求。還有一些嚴防死守的網站,除了加密ajax引數,它還把一些基本的功能都封裝了,全部都是在呼叫自己的介面,而介面引數都是加密的。
遇到這樣的網站,我們就不能用上面的方法了,通過selenium+phantomJS框架,呼叫瀏覽器核心,並利用phantomJS執行js來模擬人為操作以及觸發頁面中的js指令碼。從填寫表單到點選按鈕再到滾動頁面,全部都可以模擬,不考慮具體的請求和響應過程,只是完完整整的把人瀏覽頁面獲取資料的過程模擬一遍。用這套框架幾乎能繞過大多數的反爬蟲,因為它不是在偽裝成瀏覽器來獲取資料(上述的通過新增
Headers一定程度上就是為了偽裝成瀏覽器),它本身就是瀏覽器,phantomJS就是一個沒有介面的瀏覽器,只是操控這個瀏覽器的不是人。
2.4 Cookie限制
和Headers校驗的反爬蟲機制類似,當用戶向目標網站傳送請求時,會再請求資料中攜帶Cookie,網站通過校驗請求資訊是否存在Cookie,以及校驗Cookie的值來判定發起訪問請求的到底是真實的使用者還是爬蟲,第一次開啟網頁會生成一個隨機cookie,如果再次開啟網頁這個Cookie不存在,那麼再次設定,第三次開啟仍然不存在,這就非常有可能是爬蟲在工作了。
而Cookie校驗和Headers的區別在於,使用者傳送的Headers的內容形式是固定的可以被輕易偽造的,Cookie則不然。原因是由於,我們在分析瀏覽器請求網站訪問的過程中所分析得到的Cookie往往都是經過相關的js等過程已經改變了domain的Cookie,假如直接手動修改爬蟲攜帶的Cookie去訪問對應的網頁,由於攜帶的Cookie已經是訪問之後的domain而不是訪問之前的domain,所以是無法成功模擬整個流程的,這種情況必然導致爬蟲訪問頁面失敗。 分析Cookie,可能會攜帶大量的隨機雜湊字串,或者不同時間戳組合的字串,並且會根據每次訪問更新domain的值。對這種限制,首先要在對目標網站抓包分析時,必須先清空瀏覽器的Cookie,然後在初次訪問時,觀察瀏覽器在完成訪問的過程中的請求細節(通常會在這一過程中發生若干次301/302轉跳,每次轉跳網站返回不同的Cookie給瀏覽器然後在最後一次轉跳中請求成功)。在抓包完成對請求細節的分析之後,再在爬蟲上模擬這一轉跳過程,然後擷取Cookie作為爬蟲自身攜帶的Cookie,這樣就能夠繞過Cookie的限制完成對目標網站的訪問了。
2.5 驗證碼限制
這是一個相當古老但卻不失有效性的反爬蟲策略。更早的時候,這種驗證碼可以通過OCR技術進行簡單的影象識別破解,但是現在來說,驗證碼的干擾線,噪點已經多到肉眼都無法輕易識別的地步。所以目前而言,由於OCR技術發展不力,驗證碼技術反而成為了許多網站最有效的手段之一。
驗證碼除了識別難題之外,還有另外一個值得注意的問題。現在有許多網站都在使用第三方驗證碼服務。當用戶開啟目標網站的登入頁面時,登入頁面顯示的驗證碼是從第三方(比如阿里雲)提供的連結載入的,這時候我們在模擬登入的時候,需要多一步從網頁提供的第三方連結抓取驗證碼的步驟,而這一步常常暗含著陷阱。以阿里雲提供的驗證碼服務為例,登入頁面的原始碼會顯示阿里雲提供的第三方連結,但是當匹配出這個連結進行驗證碼抓取的時候我們會發現驗證碼是無效的。當仔細分析抓包的請求資料之後,發現正常瀏覽器在請求驗證碼時,會多帶一個ts引數,而這個引數是由當前時間戳產生的,但是並不是完全的時間戳,而是時間戳四捨五入保留九位數字之後的字串,對待這種第三方服務只能是細心加運氣,三分天註定七分不信命來猜一發了。還有另外一種特殊的第三方驗證碼,所謂的拖動驗證,只能說,網際網路創業有三種模式2b,2c,2vc。