本文全面的介紹了爬蟲的原理、技術(shù)現(xiàn)狀、以及目前仍面臨的問題。如果你沒接觸過爬蟲，本文很適合你，如果你是一名資深的蟲師，那么文末的彩蛋你可能感興趣。

成都創(chuàng)新互聯(lián)公司-專業(yè)網(wǎng)站定制、快速模板網(wǎng)站建設(shè)、高性價(jià)比定安網(wǎng)站開發(fā)、企業(yè)建站全套包干低至880元,成熟完善的模板庫(kù),直接使用。一站式定安網(wǎng)站制作公司更省心,省錢,快速模板網(wǎng)站建設(shè)找我們，業(yè)務(wù)覆蓋定安地區(qū)。費(fèi)用合理售后完善，十載實(shí)體公司更值得信賴。

一. 需求

萬維網(wǎng)上有著無數(shù)的網(wǎng)頁(yè)，包含著海量的信息，無孔不入、森羅萬象。但很多時(shí)候，無論出于數(shù)據(jù)分析或產(chǎn)品需求，我們需要從某些網(wǎng)站，提取出我們感興趣、有價(jià)值的內(nèi)容，但是縱然是進(jìn)化到21世紀(jì)的人類，依然只有兩只手，一雙眼，不可能去每一個(gè)網(wǎng)頁(yè)去點(diǎn)去看，然后再?gòu)?fù)制粘貼。所以我們需要一種能自動(dòng)獲取網(wǎng)頁(yè)內(nèi)容并可以按照指定規(guī)則提取相應(yīng)內(nèi)容的程序，這就是爬蟲。

二. 原理

傳統(tǒng)爬蟲從一個(gè)或若干初始網(wǎng)頁(yè)的URL開始，獲得初始網(wǎng)頁(yè)上的URL，在抓取網(wǎng)頁(yè)的過程中，不斷從當(dāng)前頁(yè)面上抽取新的URL放入隊(duì)列,直到滿足系統(tǒng)的一定停止條件。聚焦爬蟲的工作流程較為復(fù)雜，需要根據(jù)一定的網(wǎng)頁(yè)分析算法過濾與主題無關(guān)的鏈接，保留有用的鏈接并將其放入等待抓取的URL隊(duì)列。然后，它將根據(jù)一定的搜索策略從隊(duì)列中選擇下一步要抓取的網(wǎng)頁(yè)URL，并重復(fù)上述過程，直到達(dá)到系統(tǒng)的某一條件時(shí)停止。另外，所有被爬蟲抓取的網(wǎng)頁(yè)將會(huì)被系統(tǒng)存貯，進(jìn)行一定的分析、過濾，并建立索引，以便之后的查詢和檢索；所以一個(gè)完整的爬蟲一般會(huì)包含如下三個(gè)模塊：   

1. 網(wǎng)絡(luò)請(qǐng)求模塊

2. 爬取流程控制模塊

3. 內(nèi)容分析提取模塊

三. 網(wǎng)絡(luò)請(qǐng)求

我們常說爬蟲其實(shí)就是一堆的http(s)請(qǐng)求，找到待爬取的鏈接，然后發(fā)送一個(gè)請(qǐng)求包，得到一個(gè)返回包，當(dāng)然，也有HTTP長(zhǎng)連接(keep-alive)或h6中基于stream的websocket協(xié)議，這里暫不考慮，所以核心的幾個(gè)要素就是：

1. url

2. 請(qǐng)求header、body

3. 響應(yīng)herder、內(nèi)容

四. URL

爬蟲開始運(yùn)行時(shí)需要一個(gè)初始url，然后會(huì)根據(jù)爬取到的html文章，解析里面的鏈接，然后繼續(xù)爬取，這就像一棵多叉樹，從根節(jié)點(diǎn)開始，每走一步，就會(huì)產(chǎn)生新的節(jié)點(diǎn)。為了使爬蟲能夠結(jié)束，一般都會(huì)指定一個(gè)爬取深度(Depth)。

五. Http請(qǐng)求

http請(qǐng)求信息由請(qǐng)求方法(method)、請(qǐng)求頭(headers)、請(qǐng)求正文(body)三部分組成。由于method一般是header中的第一行，也可以說請(qǐng)求頭中包含請(qǐng)求方法，下面是chrome訪問請(qǐng)求頭的一部分：

 GET / HTTP/1.1
 Connection:Keep-Alive
 Host:gsw.iguoxue.org
 User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.95 Safari/537.36
 Accept-Encoding:gzip, deflate, sdch, br

本文不會(huì)解釋各個(gè)字段的意思，詳細(xì)的解釋請(qǐng)移步w3c Http Header Field Definitions . 對(duì)于爬蟲需要注意的是請(qǐng)求方法是post時(shí)，需要將請(qǐng)求的參數(shù)先進(jìn)行urlencode后再發(fā)送，后臺(tái)收到請(qǐng)求信息后可能會(huì)做一些校驗(yàn)，這可能會(huì)影響到爬取，相關(guān)的header字段如下：

1. Basic Auth

這是一種古老的、不安全的用戶驗(yàn)證方式，一般會(huì)有用戶授權(quán)的限制，會(huì)在headers的Autheration字段里要求加入用戶名密碼(明文)，如果驗(yàn)證失敗則請(qǐng)求就會(huì)失敗，現(xiàn)在這種認(rèn)證方式正在被淘汰。

2. Referer

鏈接的來源，通常在訪問鏈接時(shí)，都要帶上Referer字段，服務(wù)器會(huì)進(jìn)行來源驗(yàn)證，后臺(tái)通常會(huì)用此字段作為防盜鏈的依據(jù)。

3. User-Agent

后臺(tái)通常會(huì)通過此字段判斷用戶設(shè)備類型、系統(tǒng)以及瀏覽器的型號(hào)版本。有些編程語言包里網(wǎng)絡(luò)請(qǐng)求會(huì)自定義User-Agent，可以被辨別出來，爬蟲中可以設(shè)置為瀏覽器的ua.

4. Cookie

一般在用戶登錄或者某些操作后，服務(wù)端會(huì)在返回包中包含Cookie信息要求瀏覽器設(shè)置Cookie，沒有Cookie會(huì)很容易被辨別出來是偽造請(qǐng)求；

也有本地通過JS，根據(jù)服務(wù)端返回的某個(gè)信息進(jìn)行處理生成的加密信息，設(shè)置在Cookie里面；

5. JavaScript加密操作

在進(jìn)行敏感數(shù)據(jù)傳輸時(shí)，一般都會(huì)通過javascript進(jìn)行加密，例如qq空間就會(huì)對(duì)用戶登陸密碼進(jìn)行RSA加密后再發(fā)送給服務(wù)器，因此，爬蟲在模擬登陸時(shí)需要自己去請(qǐng)求公鑰，然后加密。

6. 自定義字段

因?yàn)閔ttp的headers可以自定義地段，所以第三方可能會(huì)加入了一些自定義的字段名稱或者字段值，這也是需要注意的。

六. 流程控制

所謂爬取流程，就是按照什么樣的規(guī)則順序去爬。在爬取任務(wù)不大的情況下，爬取的流程控制不會(huì)太麻煩，很多爬取框架都已經(jīng)幫你做了如scrapy，只需要自己實(shí)現(xiàn)解析的代碼。但在爬取一些大型網(wǎng)站時(shí)，例如全網(wǎng)抓取京東的評(píng)論，微博所有人的信息，關(guān)注關(guān)系等等，這種上十億到百億次設(shè)置千億次的請(qǐng)求必須考慮效率，否則一天只有86400秒，那么一秒鐘要抓100次，一天也才8640w次請(qǐng)求，也需要100多天才能到達(dá)十億級(jí)別的請(qǐng)求量。涉及到大規(guī)模的抓取，一定要有良好的爬蟲設(shè)計(jì)，一般很多開源的爬蟲框架也都是有限制的，因?yàn)橹虚g涉及到很多其他的問題，例如數(shù)據(jù)結(jié)構(gòu)，重復(fù)抓取過濾的問題，當(dāng)然最重要的是要把帶寬利用滿，所以分布式抓取很重要，這時(shí)流程控制就會(huì)很重要，分布式最重要的就是多臺(tái)機(jī)器不同線程的調(diào)度和配合，通常會(huì)共享一個(gè)url隊(duì)列，然后各個(gè)線程通過消息通信，如果想要抓的越多越快，那么對(duì)中間的消息系統(tǒng)的吞吐量要求也越高?，F(xiàn)在也有一些開源的分布式爬取框架如scrapy-redis就是一個(gè)重寫了scrapy的調(diào)度模塊、隊(duì)列、管道的包，redis數(shù)據(jù)庫(kù)是用來在分布式中做請(qǐng)求隊(duì)列共享，scrapyd是用來部署scrapy的,scrapyd-api用來啟動(dòng)獲取數(shù)據(jù)。

七. 內(nèi)容分析提取

請(qǐng)求headers的Accept-Encoding字段表示瀏覽器告訴服務(wù)器自己支持的壓縮算法（目前最多的是gzip），如果服務(wù)器開啟了壓縮，返回時(shí)會(huì)對(duì)響應(yīng)體進(jìn)行壓縮，爬蟲需要自己解壓；

過去我們常需要獲取的內(nèi)容主要來源于網(wǎng)頁(yè)html文檔本身，也就是說，我們決定進(jìn)行抓取的時(shí)候，都是html中包含的內(nèi)容，但是隨著這幾年web技術(shù)飛速的發(fā)展，動(dòng)態(tài)網(wǎng)頁(yè)越來越多，尤其是移動(dòng)端，大量的SPA應(yīng)用，這些網(wǎng)站中大量的使用了ajax技術(shù)。我們?cè)跒g覽器中看到的網(wǎng)頁(yè)已不全是html文檔說包含的，很多都是通過javascript動(dòng)態(tài)生成的，一般來說，我們最終眼里看到的網(wǎng)頁(yè)包括以下三種：

Html文檔本身包含內(nèi)容

這種情況是最容易解決的，一般來講基本上是靜態(tài)網(wǎng)頁(yè)已經(jīng)寫死的內(nèi)容，或者動(dòng)態(tài)網(wǎng)頁(yè)，采用模板渲染，瀏覽器獲取到HTML的時(shí)候已經(jīng)是包含所有的關(guān)鍵信息，所以直接在網(wǎng)頁(yè)上看到的內(nèi)容都可以通過特定的HTML標(biāo)簽得到。這種情況解析也是很簡(jiǎn)單的，一般的方法有一下幾種：

1. CSS選擇器

2. XPATH（這個(gè)值得學(xué)習(xí)一下）

3. 正則表達(dá)式或普通字符串查找

4. JavaScript代碼加載內(nèi)容

一般來說有兩種情況：一種情況是在請(qǐng)求到html文檔時(shí)，網(wǎng)頁(yè)的數(shù)據(jù)在js代碼中，而并非在html標(biāo)簽中，之所以我們看到的網(wǎng)頁(yè)是正常的，那是因?yàn)椋鋵?shí)是由于執(zhí)行js代碼動(dòng)態(tài)添加到標(biāo)簽里面的，所以這個(gè)時(shí)候內(nèi)容在js代碼里面的，而js的執(zhí)行是在瀏覽器端的操作，所以用程序去請(qǐng)求網(wǎng)頁(yè)地址的時(shí)候，得到的response是網(wǎng)頁(yè)代碼和js的代碼，所以自己在瀏覽器端能看到內(nèi)容，解析時(shí)由于js未執(zhí)行，肯定找到指定HTML標(biāo)簽下內(nèi)容肯定為空，如百度的主頁(yè)就是這種，這個(gè)時(shí)候的處理辦法，一般來講主要是要找到包含內(nèi)容的js代碼串，然后通過正則表達(dá)式獲得相應(yīng)的內(nèi)容，而不是解析HTML標(biāo)簽。另一種情況是在和用戶交互時(shí)，JavaScript可能會(huì)動(dòng)態(tài)生成一些dom，如點(diǎn)擊某個(gè)按鈕彈了一個(gè)對(duì)話框等；對(duì)于這種情況，一般這些內(nèi)容都是一些用戶提示相關(guān)的內(nèi)容，沒什么價(jià)值，如果確實(shí)需要，可以分析一下js執(zhí)行邏輯，但這樣的情況很少。

Ajax／Fetch異步請(qǐng)求

這種情況是現(xiàn)在很常見的，尤其是在內(nèi)容以分頁(yè)形式顯示在網(wǎng)頁(yè)上，并且頁(yè)面無刷新，或者是對(duì)網(wǎng)頁(yè)進(jìn)行某個(gè)交互操作后，得到內(nèi)容。對(duì)于這種頁(yè)面，分析的時(shí)候我們要跟蹤所有的請(qǐng)求，觀察數(shù)據(jù)到底是在哪一步加載進(jìn)來的。然后當(dāng)我們找到核心的異步請(qǐng)求的時(shí)候，就只需抓取這個(gè)異步請(qǐng)求就可以了，如果原始網(wǎng)頁(yè)沒有任何有用信息，也沒必要去抓取原始網(wǎng)頁(yè)了。

八. 爬蟲技術(shù)的現(xiàn)狀

1. 語言

理論上來說，任何支持網(wǎng)絡(luò)通信的語言都是可以寫爬蟲的，爬蟲本身雖然語言關(guān)系不大，但是，總有相對(duì)順手、簡(jiǎn)單的。目前來說，大多數(shù)爬蟲是用后臺(tái)腳本類語言寫的，其中python無疑是用的最多最廣的，并且頁(yè)誕生了很多優(yōu)秀的庫(kù)和框架，如scrapy、BeautifulSoup 、pyquery、Mechanize等。但是一般來說，搜索引擎的爬蟲對(duì)爬蟲的效率要求更高，會(huì)選用c++、java、go(適合高并發(fā))，我在大學(xué)時(shí)代就用c++實(shí)現(xiàn)了一個(gè)多線程的框架，但是發(fā)現(xiàn)和python實(shí)現(xiàn)的爬蟲效率提升并不明顯，原因是，對(duì)于簡(jiǎn)單爬蟲，瓶頸在于數(shù)據(jù)分析及提取，而網(wǎng)絡(luò)效率和語言關(guān)系并不大。值得一提的是，在近幾年node發(fā)展非?？?， 使得javascript遍地開花，有些人也開始嘗試用node做爬蟲，但是，這其實(shí)和其它后臺(tái)腳本語言沒什么區(qū)別，也不如 python簡(jiǎn)單， 因?yàn)槟阋琅f不能在node 里發(fā)起ajax請(qǐng)求，不能執(zhí)行原網(wǎng)頁(yè)的dom。因?yàn)閚ode的javascript 執(zhí)行環(huán)境和瀏覽器的執(zhí)行環(huán)境并不相同。那么，難道就真的不能像在瀏覽器中一樣用js寫爬蟲，用jquery提取內(nèi)容嗎？想法很大膽，我們暫且擱置。

2. 運(yùn)行環(huán)境

爬蟲本身不區(qū)分到底是運(yùn)行在windows還是Linux，又或是OSX，但從業(yè)務(wù)角度講，我們把運(yùn)行在服務(wù)端(后臺(tái))的，稱之為后臺(tái)爬蟲。而現(xiàn)在，幾乎所有的爬蟲都是后臺(tái)爬蟲。

3. 后臺(tái)爬蟲的三大問題

問題一：交互問題

有些網(wǎng)頁(yè)往往需要和用戶進(jìn)行一些交互，進(jìn)而才能走到下一步，比如輸入一個(gè)驗(yàn)證碼，拖動(dòng)一個(gè)滑塊，選幾個(gè)漢字。網(wǎng)站之所以這么做，很多時(shí)候都是為了驗(yàn)證訪問者到底是人還是機(jī)器。而爬蟲程序遇到這種情況很難處理，傳統(tǒng)的簡(jiǎn)單圖片驗(yàn)證碼可以通過圖形處理算法讀出內(nèi)容，但是隨著各種各樣，花樣百出，人神共憤的、變態(tài)的驗(yàn)證碼越來越多（尤其是買火車票時(shí)，分分鐘都想爆粗口），這個(gè)問題就越來越嚴(yán)重。

問題二：Javascript 解析問題

如前文所述，javascript可以動(dòng)態(tài)生成dom。目前大多數(shù)網(wǎng)頁(yè)屬于動(dòng)態(tài)網(wǎng)頁(yè)（內(nèi)容由javascript動(dòng)態(tài)填充），尤其是在移動(dòng)端，SPA/PWA應(yīng)用越來越流行，網(wǎng)頁(yè)中大多數(shù)有用的數(shù)據(jù)都是通過ajax/fetch動(dòng)態(tài)獲取后然后再由js填充到網(wǎng)頁(yè)dom樹中，單純的html靜態(tài)頁(yè)面中有用的數(shù)據(jù)很少。目前主要應(yīng)對(duì)的方案就是對(duì)于js ajax/fetch請(qǐng)求直接請(qǐng)求ajax/fetch的url ，但是還有一些ajax的請(qǐng)求參數(shù)會(huì)依賴一段javascript動(dòng)態(tài)生成，比如一個(gè)請(qǐng)求簽名，再比如用戶登陸時(shí)對(duì)密碼的加密等等，如果一昧的去用后臺(tái)腳本去干javascript本來做的事，這就要清楚的理解原網(wǎng)頁(yè)代碼邏輯，而這不僅非常麻煩，而且會(huì)使你的爬取代碼異常龐大臃腫，但是，更致命的是，有些javascript可以做的事爬蟲程序是很難甚至是不能模仿的，比如有些網(wǎng)站使用拖動(dòng)滑塊到某個(gè)位置的驗(yàn)證碼機(jī)制，這就很難再爬蟲中去模仿。其實(shí)，總結(jié)一些，這些弊端歸根結(jié)底，是因?yàn)榕老x程序并非是瀏覽器，沒有javascript解析引擎所致。針對(duì)這個(gè)問題，目前主要的應(yīng)對(duì)策略就是在爬蟲中引入Javascript 引擎，如PhantomJS，但是又有著明顯的弊端，如服務(wù)器同時(shí)有多個(gè)爬取任務(wù)時(shí)，資源占用太大。還有就是，這些 無窗口的javascript引擎很多時(shí)候使用起來并不能像在瀏覽器環(huán)境中一樣，頁(yè)面內(nèi)部發(fā)生跳轉(zhuǎn)時(shí)，會(huì)導(dǎo)致流程很難控制。

問題三：IP限制

這是目前對(duì)后臺(tái)爬蟲中最致命的。網(wǎng)站的防火墻會(huì)對(duì)某個(gè)固定ip在某段時(shí)間內(nèi)請(qǐng)求的次數(shù)做限制，如果沒有超過上線則正常返回?cái)?shù)據(jù)，超過了，則拒絕請(qǐng)求，如qq 郵箱。值得說明的是，ip限制有時(shí)并非是專門為了針對(duì)爬蟲的，而大多數(shù)時(shí)候是出于網(wǎng)站安全原因針對(duì)DOS攻擊的防御措施。后臺(tái)爬取時(shí)機(jī)器和ip有限，很容易達(dá)到上線而導(dǎo)致請(qǐng)求被拒絕。目前主要的應(yīng)對(duì)方案是使用代理，這樣一來ip的數(shù)量就會(huì)多一些，但代理ip依然有限，對(duì)于這個(gè)問題，根本不可能徹底解決。

以上就是本文的全部?jī)?nèi)容，希望本文的內(nèi)容對(duì)大家的學(xué)習(xí)或者工作能帶來一定的幫助，同時(shí)也希望多多支持創(chuàng)新互聯(lián)！