網絡爬蟲技術

一、爬蟲技術概述

 

網絡爬蟲（Web crawler），是一種按照必定的規則，自動地抓取萬維網信息的程序或者腳本，它們被普遍用於互聯網搜索引擎或其餘相似網站，能夠自動採集全部其可以訪問到的頁面內容，以獲取或更新這些網站的內容和檢索方式。從功能上來說，爬蟲通常分爲數據採集，處理，儲存三個部分。傳統爬蟲從一個或若干初始網頁的URL開始，得到初始網頁上的URL，在抓取網頁的過程當中，不斷從當前頁面上抽取新的URL放入隊列,直到知足系統的必定中止條件。聚焦爬蟲的工做流程較爲複雜，須要根據必定的網頁分析算法過濾與主題無關的連接，保留有用的連接並將其放入等待抓取的URL隊列。而後，它將根據必定的搜索策略從隊列中選擇下一步要抓取的網頁URL，並重覆上述過程，直到達到系統的某一條件時中止。另外，全部被爬蟲抓取的網頁將會被系統存貯，進行必定的分析、過濾，並創建索引，以便以後的查詢和檢索；對於聚焦爬蟲來講，這一過程所獲得的分析結果還可能對之後的抓取過程給出反饋和指導。

 

相對於通用網絡爬蟲，聚焦爬蟲還須要解決三個主要問題：

 

(1) 對抓取目標的描述或定義；

 

(2) 對網頁或數據的分析與過濾；

 

(3) 對URL的搜索策略。

 

 

  

二、爬蟲原理

 

2.1 網絡爬蟲原理

 

Web網絡爬蟲系統的功能是下載網頁數據，爲搜索引擎系統提供數據來源。不少大型的網絡搜索引擎系統都被稱爲基於 Web數據採集的搜索引擎系統，好比 Google、Baidu。因而可知Web 網絡爬蟲系統在搜索引擎中的重要性。網頁中除了包含供用戶閱讀的文字信息外，還包含一些超連接信息。Web網絡爬蟲系統正是經過網頁中的超鏈接信息不斷得到網絡上的其它網頁。正是由於這種採集過程像一個爬蟲或者蜘蛛在網絡上漫遊，因此它才被稱爲網絡爬蟲系統或者網絡蜘蛛系統，在英文中稱爲Spider或者Crawler。

 

 

 2.2 網絡爬蟲系統的工做原理

 

在網絡爬蟲的系統框架中，主過程由控制器，解析器，資源庫三部分組成。控制器的主要工做是負責給多線程中的各個爬蟲線程分配工做任務。解析器的主要工做是下載網頁，進行頁面的處理，主要是將一些JS腳本標籤、CSS代碼內容、空格字符、HTML標籤等內容處理掉，爬蟲的基本工做是由解析器完成。資源庫是用來存放下載到的網頁資源，通常都採用大型的數據庫存儲，如Oracle數據庫，並對其創建索引。

 

控制器

 

控制器是網絡爬蟲的中央控制器，它主要是負責根據系統傳過來的URL連接，分配一線程，而後啓動線程調用爬蟲爬取網頁的過程。

 

解析器

 

解析器是負責網絡爬蟲的主要部分，其負責的工做主要有：下載網頁的功能，對網頁的文本進行處理，如過濾功能，抽取特殊HTML標籤的功能，分析數據功能。

 

資源庫

 

主要是用來存儲網頁中下載下來的數據記錄的容器，並提供生成索引的目標源。中大型的數據庫產品有：Oracle、Sql Server等。

 

Web網絡爬蟲系統通常會選擇一些比較重要的、出度(網頁中鏈出超連接數)較大的網站的URL做爲種子URL集合。網絡爬蟲系統以這些種子集合做爲初始URL，開始數據的抓取。由於網頁中含有連接信息，經過已有網頁的 URL會獲得一些新的 URL，能夠把網頁之間的指向結構視爲一個森林，每一個種子URL對應的網頁是森林中的一棵樹的根節點。這樣，Web網絡爬蟲系統就能夠根據廣度優先算法或者深度優先算法遍歷全部的網頁。因爲深度優先搜索算法可能會使爬蟲系統陷入一個網站內部，不利於搜索比較靠近網站首頁的網頁信息，所以通常採用廣度優先搜索算法採集網頁。Web網絡爬蟲系統首先將種子URL放入下載隊列，而後簡單地從隊首取出一個URL下載其對應的網頁。獲得網頁的內容將其存儲後，再通過解析網頁中的連接信息能夠獲得一些新的URL，將這些URL加入下載隊列。而後再取出一個URL，對其對應的網頁進行下載，而後再解析，如此反覆進行，直到遍歷了整個網絡或者知足某種條件後纔會中止下來。

 

 

  

網絡爬蟲的基本工做流程以下：

 

1.首先選取一部分精心挑選的種子URL；

 

2.將這些URL放入待抓取URL隊列；

 

3.從待抓取URL隊列中取出待抓取在URL，解析DNS，而且獲得主機的ip，並將URL對應的網頁下載下來，存儲進已下載網頁庫中。此外，將這些URL放進已抓取URL隊列。

 

4.分析已抓取URL隊列中的URL，分析其中的其餘URL，而且將URL放入待抓取URL隊列，從而進入下一個循環。

 

 

 

 

  

 

  

2.3 抓取策略

 

在爬蟲系統中，待抓取URL隊列是很重要的一部分。待抓取URL隊列中的URL以什麼樣的順序排列也是一個很重要的問題，由於這涉及到先抓取那個頁面，後抓取哪一個頁面。而決定這些URL排列順序的方法，叫作抓取策略。下面重點介紹幾種常見的抓取策略：

 

2.3.1深度優先遍歷策略

 

深度優先遍歷策略是指網絡爬蟲會從起始頁開始，一個連接一個連接跟蹤下去，處理完這條線路以後再轉入下一個起始頁，繼續跟蹤連接。咱們如下面的圖爲例：

 

遍歷的路徑：A-F-G E-H-I B C D

 

 

  

2.3.2寬度優先遍歷策略

 

寬度優先遍歷策略的基本思路是，將新下載網頁中發現的連接直接插入待抓取URL隊列的末尾。也就是指網絡爬蟲會先抓取起始網頁中連接的全部網頁，而後再選擇其中的一個連接網頁，繼續抓取在此網頁中連接的全部網頁。仍是以上面的圖爲例：

 

遍歷路徑：A-B-C-D-E-F G H I

 

2.3.3反向連接數策略

 

反向連接數是指一個網頁被其餘網頁連接指向的數量。反向連接數表示的是一個網頁的內容受到其餘人的推薦的程度。所以，不少時候搜索引擎的抓取系統會使用這個指標來評價網頁的重要程度，從而決定不一樣網頁的抓取前後順序。

 

在真實的網絡環境中，因爲廣告連接、做弊連接的存在，反向連接數不能徹底等他我那個也的重要程度。所以，搜索引擎每每考慮一些可靠的反向連接數。

 

2.3.4Partial PageRank策略

 

Partial PageRank算法借鑑了PageRank算法的思想：對於已經下載的網頁，連同待抓取URL隊列中的URL，造成網頁集合，計算每一個頁面的PageRank值，計算完以後，將待抓取URL隊列中的URL按照PageRank值的大小排列，並按照該順序抓取頁面。

 

若是每次抓取一個頁面，就從新計算PageRank值，一種折中方案是：每抓取K個頁面後，從新計算一次PageRank值。可是這種狀況還會有一個問題：對於已經下載下來的頁面中分析出的連接，也就是咱們以前提到的未知網頁那一部分，暫時是沒有PageRank值的。爲了解決這個問題，會給這些頁面一個臨時的PageRank值：將這個網頁全部入鏈傳遞進來的PageRank值進行彙總，這樣就造成了該未知頁面的PageRank值，從而參與排序。下面舉例說明：

 

2.3.5OPIC策略策略

 

該算法實際上也是對頁面進行一個重要性打分。在算法開始前，給全部頁面一個相同的初始現金（cash）。當下載了某個頁面P以後，將P的現金分攤給全部從P中分析出的連接，而且將P的現金清空。對於待抓取URL隊列中的全部頁面按照現金數進行排序。

 

2.3.6大站優先策略

 

對於待抓取URL隊列中的全部網頁，根據所屬的網站進行分類。對於待下載頁面數多的網站，優先下載。這個策略也所以叫作大站優先策略。

 

三、爬蟲分類

 

開發網絡爬蟲應該選擇Nutch、Crawler4j、WebMagic、scrapy、WebCollector仍是其餘的？上面說的爬蟲，基本能夠分3類：

 

（1）分佈式爬蟲：Nutch

 

（2）JAVA爬蟲：Crawler4j、WebMagic、WebCollector

 

（3）非JAVA爬蟲：scrapy（基於Python語言開發）

 

3.1 分佈式爬蟲

 

爬蟲使用分佈式，主要是解決兩個問題：

 

1)海量URL管理

 

2)網速

 

如今比較流行的分佈式爬蟲，是Apache的Nutch。可是對於大多數用戶來講，Nutch是這幾類爬蟲裏，最很差的選擇，理由以下：

 

1)Nutch是爲搜索引擎設計的爬蟲，大多數用戶是須要一個作精準數據爬取（精抽取）的爬蟲。Nutch運行的一套流程裏，有三分之二是爲了搜索引擎而設計的。對精抽取沒有太大的意義。也就是說，用Nutch作數據抽取，會浪費不少的時間在沒必要要的計算上。並且若是你試圖經過對Nutch進行二次開發，來使得它適用於精抽取的業務，基本上就要破壞Nutch的框架，把Nutch改的面目全非，有修改Nutch的能力，真的不如本身從新寫一個分佈式爬蟲框架了。

 

2)Nutch依賴hadoop運行，hadoop自己會消耗不少的時間。若是集羣機器數量較少，爬取速度反而不如單機爬蟲快。

 

3)Nutch雖然有一套插件機制，並且做爲亮點宣傳。能夠看到一些開源的Nutch插件，提供精抽取的功能。可是開發過Nutch插件的人都知道，Nutch的插件系統有多蹩腳。利用反射的機制來加載和調用插件，使得程序的編寫和調試都變得異常困難，更別說在上面開發一套複雜的精抽取系統了。並且Nutch並無爲精抽取提供相應的插件掛載點。Nutch的插件有隻有五六個掛載點，而這五六個掛載點都是爲了搜索引擎服務的，並無爲精抽取提供掛載點。大多數Nutch的精抽取插件，都是掛載在「頁面解析」(parser)這個掛載點的，這個掛載點實際上是爲了解析連接（爲後續爬取提供URL），以及爲搜索引擎提供一些易抽取的網頁信息(網頁的meta信息、text文本)。

 

4)用Nutch進行爬蟲的二次開發，爬蟲的編寫和調試所需的時間，每每是單機爬蟲所需的十倍時間不止。瞭解Nutch源碼的學習成本很高，況且是要讓一個團隊的人都讀懂Nutch源碼。調試過程當中會出現除程序自己以外的各類問題(hadoop的問題、hbase的問題)。

 

5)不少人說Nutch2有gora，能夠持久化數據到avro文件、hbase、mysql等。不少人其實理解錯了，這裏說的持久化數據，是指將URL信息（URL管理所須要的數據）存放到avro、hbase、mysql。並非你要抽取的結構化數據。其實對大多數人來講，URL信息存在哪裏無所謂。

 

6)Nutch2的版本目前並不適合開發。官方如今穩定的Nutch版本是nutch2.2.1，可是這個版本綁定了gora-0.3。若是想用hbase配合nutch（大多數人用nutch2就是爲了用hbase)，只能使用0.90版本左右的hbase，相應的就要將hadoop版本降到hadoop 0.2左右。並且nutch2的官方教程比較有誤導做用，Nutch2的教程有兩個，分別是Nutch1.x和Nutch2.x，這個Nutch2.x官網上寫的是能夠支持到hbase 0.94。可是實際上，這個Nutch2.x的意思是Nutch2.3以前、Nutch2.2.1以後的一個版本，這個版本在官方的SVN中不斷更新。並且很是不穩定（一直在修改）。

 

因此，若是你不是要作搜索引擎，儘可能不要選擇Nutch做爲爬蟲。有些團隊就喜歡跟風，非要選擇Nutch來開發精抽取的爬蟲，實際上是衝着Nutch的名氣（Nutch做者是Doug Cutting），固然最後的結果每每是項目延期完成。

 

若是你是要作搜索引擎，Nutch1.x是一個很是好的選擇。Nutch1.x和solr或者es配合，就能夠構成一套很是強大的搜索引擎了。若是非要用Nutch2的話，建議等到Nutch2.3發佈再看。目前的Nutch2是一個很是不穩定的版本。

 

 

  

分佈式爬蟲平臺架構圖

 

3.2 JAVA爬蟲

 

這裏把JAVA爬蟲單獨分爲一類，是由於JAVA在網絡爬蟲這塊的生態圈是很是完善的。相關的資料也是最全的。這裏可能有爭議，我只是隨便談談。

 

其實開源網絡爬蟲（框架）的開發很是簡單，難問題和複雜的問題都被之前的人解決了（好比DOM樹解析和定位、字符集檢測、海量URL去重），能夠說是毫無技術含量。包括Nutch，其實Nutch的技術難點是開發hadoop，自己代碼很是簡單。網絡爬蟲從某種意義來講，相似遍歷本機的文件，查找文件中的信息。沒有任何難度可言。之因此選擇開源爬蟲框架，就是爲了省事。好比爬蟲的URL管理、線程池之類的模塊，誰都能作，可是要作穩定也是須要一段時間的調試和修改的。

對於爬蟲的功能來講。用戶比較關心的問題每每是：

 

1）爬蟲支持多線程麼、爬蟲能用代理麼、爬蟲會爬取重複數據麼、爬蟲能爬取JS生成的信息麼？

 

不支持多線程、不支持代理、不能過濾重複URL的，那都不叫開源爬蟲，那叫循環執行http請求。

 

能不能爬js生成的信息和爬蟲自己沒有太大關係。爬蟲主要是負責遍歷網站和下載頁面。爬js生成的信息和網頁信息抽取模塊有關，每每須要經過模擬瀏覽器(htmlunit,selenium)來完成。這些模擬瀏覽器，每每須要耗費不少的時間來處理一個頁面。因此一種策略就是，使用這些爬蟲來遍歷網站，遇到須要解析的頁面，就將網頁的相關信息提交給模擬瀏覽器，來完成JS生成信息的抽取。

 

2）爬蟲能夠爬取ajax信息麼？

 

網頁上有一些異步加載的數據，爬取這些數據有兩種方法：使用模擬瀏覽器（問題1中描述過了），或者分析ajax的http請求，本身生成ajax請求的url，獲取返回的數據。若是是本身生成ajax請求，使用開源爬蟲的意義在哪裏？實際上是要用開源爬蟲的線程池和URL管理功能（好比斷點爬取）。

 

若是我已經能夠生成我所須要的ajax請求（列表），如何用這些爬蟲來對這些請求進行爬取？

 

爬蟲每每都是設計成廣度遍歷或者深度遍歷的模式，去遍歷靜態或者動態頁面。爬取ajax信息屬於deep web（深網）的範疇，雖然大多數爬蟲都不直接支持。可是也能夠經過一些方法來完成。好比WebCollector使用廣度遍從來遍歷網站。爬蟲的第一輪爬取就是爬取種子集合(seeds)中的全部url。簡單來講，就是將生成的ajax請求做爲種子，放入爬蟲。用爬蟲對這些種子，進行深度爲1的廣度遍歷（默認就是廣度遍歷）。

 

3）爬蟲怎麼爬取要登錄的網站？

 

這些開源爬蟲都支持在爬取時指定cookies，模擬登錄主要是靠cookies。至於cookies怎麼獲取，不是爬蟲管的事情。你能夠手動獲取、用http請求模擬登錄或者用模擬瀏覽器自動登錄獲取cookie。

 

4）爬蟲怎麼抽取網頁的信息？

 

開源爬蟲通常都會集成網頁抽取工具。主要支持兩種規範：CSS SELECTOR和XPATH。至於哪一個好，這裏不評價。

 

5）爬蟲怎麼保存網頁的信息？

 

有一些爬蟲，自帶一個模塊負責持久化。好比webmagic，有一個模塊叫pipeline。經過簡單地配置，能夠將爬蟲抽取到的信息，持久化到文件、數據庫等。還有一些爬蟲，並無直接給用戶提供數據持久化的模塊。好比crawler4j和webcollector。讓用戶本身在網頁處理模塊中添加提交數據庫的操做。至於使用pipeline這種模塊好很差，就和操做數據庫使用ORM好很差這個問題相似，取決於你的業務。

 

6）爬蟲被網站封了怎麼辦？

 

爬蟲被網站封了，通常用多代理（隨機代理）就能夠解決。可是這些開源爬蟲通常沒有直接支持隨機代理的切換。因此用戶每每都須要本身將獲取的代理，放到一個全局數組中，本身寫一個代理隨機獲取（從數組中）的代碼。

 

7）網頁能夠調用爬蟲麼？

 

爬蟲的調用是在Web的服務端調用的，平時怎麼用就怎麼用，這些爬蟲均可以使用。

 

8）爬蟲速度怎麼樣？

 

單機開源爬蟲的速度，基本均可以講本機的網速用到極限。爬蟲的速度慢，每每是由於用戶把線程數開少了、網速慢，或者在數據持久化時，和數據庫的交互速度慢。而這些東西，每每都是用戶的機器和二次開發的代碼決定的。這些開源爬蟲的速度，都很能夠。

 

9）明明代碼寫對了，爬不到數據，是否是爬蟲有問題，換個爬蟲能解決麼？

 

若是代碼寫對了，又爬不到數據，換其餘爬蟲也是同樣爬不到。遇到這種狀況，要麼是網站把你封了，要麼是你爬的數據是javascript生成的。爬不到數據經過換爬蟲是不能解決的。

 

10）哪一個爬蟲能夠判斷網站是否爬完、那個爬蟲能夠根據主題進行爬取？

 

爬蟲沒法判斷網站是否爬完，只能儘量覆蓋。

 

至於根據主題爬取，爬蟲以後把內容爬下來才知道是什麼主題。因此通常都是整個爬下來，而後再去篩選內容。若是嫌爬的太泛，能夠經過限制URL正則等方式，來縮小一下範圍。

 

11）哪一個爬蟲的設計模式和構架比較好？

 

設計模式純屬扯淡。說軟件設計模式好的，都是軟件開發完，而後總結出幾個設計模式。設計模式對軟件開發沒有指導性做用。用設計模式來設計爬蟲，只會使得爬蟲的設計更加臃腫。

 

至於構架，開源爬蟲目前主要是細節的數據結構的設計，好比爬取線程池、任務隊列，這些你們都能控制好。爬蟲的業務太簡單，談不上什麼構架。

 

因此對於JAVA開源爬蟲，我以爲，隨便找一個用的順手的就能夠。若是業務複雜，拿哪一個爬蟲來，都是要通過複雜的二次開發，才能夠知足需求。

 

3.3 非JAVA爬蟲

 

在非JAVA語言編寫的爬蟲中，有不少優秀的爬蟲。這裏單獨提取出來做爲一類，並非針對爬蟲自己的質量進行討論，而是針對larbin、scrapy這類爬蟲，對開發成本的影響。

 

先說python爬蟲，python能夠用30行代碼，完成JAVA 50行代碼乾的任務。python寫代碼的確快，可是在調試代碼的階段，python代碼的調試每每會耗費遠遠多於編碼階段省下的時間。使用python開發，要保證程序的正確性和穩定性，就須要寫更多的測試模塊。固然若是爬取規模不大、爬取業務不復雜，使用scrapy這種爬蟲也是蠻不錯的，能夠輕鬆完成爬取任務。

 

 

  

上圖是Scrapy的架構圖，綠線是數據流向，首先從初始URL 開始，Scheduler 會將其交給 Downloader 進行下載，下載以後會交給 Spider 進行分析，須要保存的數據則會被送到Item Pipeline，那是對數據進行後期處理。另外，在數據流動的通道里還能夠安裝各類中間件，進行必要的處理。 所以在開發爬蟲的時候，最好也先規劃好各類模塊。個人作法是單獨規劃下載模塊，爬行模塊，調度模塊，數據存儲模塊。

 

對於C++爬蟲來講，學習成本會比較大。並且不能只計算一我的的學習成本，若是軟件須要團隊開發或者交接，那就是不少人的學習成本了。軟件的調試也不是那麼容易。

 

還有一些ruby、php的爬蟲，這裏很少評價。的確有一些很是小型的數據採集任務，用ruby或者php很方便。可是選擇這些語言的開源爬蟲，一方面要調研一下相關的生態圈，還有就是，這些開源爬蟲可能會出一些你搜不到的BUG（用的人少、資料也少）

 

四、反爬蟲技術

 

由於搜索引擎的流行，網絡爬蟲已經成了很普及網絡技術，除了專門作搜索的Google，Yahoo，微軟，百度之外，幾乎每一個大型門戶網站都有本身的搜索引擎，大大小小叫得出來名字得就幾十種，還有各類不知名的幾千幾萬種，對於一個內容型驅動的網站來講，受到網絡爬蟲的光顧是不可避免的。

 

一些智能的搜索引擎爬蟲的爬取頻率比較合理，對網站資源消耗比較少，可是不少糟糕的網絡爬蟲，對網頁爬取能力不好，常常併發幾十上百個請求循環重複抓取，這種爬蟲對中小型網站每每是毀滅性打擊，特別是一些缺少爬蟲編寫經驗的程序員寫出來的爬蟲破壞力極強，形成的網站訪問壓力會很是大，會致使網站訪問速度緩慢，甚至沒法訪問。

 

通常網站從三個方面反爬蟲：用戶請求的Headers，用戶行爲，網站目錄和數據加載方式。前兩種比較容易遇到，大多數網站都從這些角度來反爬蟲。第三種一些應用ajax的網站會採用，這樣增大了爬取的難度。

 

4.1 經過Headers反爬蟲

 

從用戶請求的Headers反爬蟲是最多見的反爬蟲策略。不少網站都會對Headers的User-Agent進行檢測，還有一部分網站會對Referer進行檢測（一些資源網站的防盜鏈就是檢測Referer）。若是遇到了這類反爬蟲機制，能夠直接在爬蟲中添加Headers，將瀏覽器的User-Agent複製到爬蟲的Headers中；或者將Referer值修改成目標網站域名[評論：每每容易被忽略，經過對請求的抓包分析，肯定referer，在程序中模擬訪問請求頭中添加]。對於檢測Headers的反爬蟲，在爬蟲中修改或者添加Headers就能很好的繞過。

 

4.2 基於用戶行爲反爬蟲

 

還有一部分網站是經過檢測用戶行爲，例如同一IP短期內屢次訪問同一頁面，或者同一帳戶短期內屢次進行相同操做。[這種防爬，須要有足夠多的ip來應對]

 

大多數網站都是前一種狀況，對於這種狀況，使用IP代理就能夠解決。能夠專門寫一個爬蟲，爬取網上公開的代理ip，檢測後所有保存起來。這樣的代理ip爬蟲常常會用到，最好本身準備一個。有了大量代理ip後能夠每請求幾回更換一個ip，這在requests或者urllib2中很容易作到，這樣就能很容易的繞過第一種反爬蟲。[評論：動態撥號也是一種解決方案]

 

對於第二種狀況，能夠在每次請求後隨機間隔幾秒再進行下一次請求。有些有邏輯漏洞的網站，能夠經過請求幾回，退出登陸，從新登陸，繼續請求來繞過同一帳號短期內不能屢次進行相同請求的限制。[評論：對於帳戶作防爬限制，通常難以應對，隨機幾秒請求也每每可能被封，若是能有多個帳戶，切換使用，效果更佳]

 

4.3動態頁面的反爬蟲

 

上述的幾種狀況大多都是出如今靜態頁面，還有一部分網站，咱們須要爬取的數據是經過ajax請求獲得，或者經過Java生成的。首先用Firebug或者HttpFox對網絡請求進行分析[評論：感受google的、IE的網絡請求分析使用也挺好]。若是可以找到ajax請求，也能分析出具體的參數和響應的具體含義，咱們就能採用上面的方法，直接利用requests或者urllib2模擬ajax請求，對響應的json進行分析獲得須要的數據。

 

可以直接模擬ajax請求獲取數據當然是極好的，可是有些網站把ajax請求的全部參數所有加密了。咱們根本沒辦法構造本身所須要的數據的請求。我這幾天爬的那個網站就是這樣，除了加密ajax參數，它還把一些基本的功能都封裝了，所有都是在調用本身的接口，而接口參數都是加密的。遇到這樣的網站，咱們就不能用上面的方法了，我用的是selenium+phantomJS框架，調用瀏覽器內核，並利用phantomJS執行js來模擬人爲操做以及觸發頁面中的js腳本。從填寫表單到點擊按鈕再到滾動頁面，所有均可以模擬，不考慮具體的請求和響應過程，只是完完整整的把人瀏覽頁面獲取數據的過程模擬一遍。[評論：支持phantomJS]

 

用這套框架幾乎能繞過大多數的反爬蟲，由於它不是在假裝成瀏覽器來獲取數據（上述的經過添加 Headers必定程度上就是爲了假裝成瀏覽器），它自己就是瀏覽器，phantomJS就是一個沒有界面的瀏覽器，只是操控這個瀏覽器的不是人。利用 selenium+phantomJS能幹不少事情，例如識別點觸式（12306）或者滑動式的驗證碼，對頁面表單進行暴力破解等等。它在自動化滲透中還 會大展身手，之後還會提到這個。