爬蟲(1) – 爬蟲基礎入門理論篇

1.學習前置【必看】

近年來由於抓取數據而引起的糾紛越來越多,有的鋃鐺入獄,有的被處罰金,本人爬蟲筆記學習提醒大家:爬蟲有風險,採集需謹慎,寫程式碼不能違法,寫程式碼背後也有法律風險

1.1爬蟲注意點

1.1.1遵守Robots協議

Robots協議,也稱為爬蟲協議、機器人協議等,全稱是「網路爬蟲排除標準」(Robots Exclusion Protocol),網站通過Robots協議告訴爬蟲哪些頁面可以抓取,哪些頁面不能抓取

如何查看網站的rebots協議?

(1)打開瀏覽器,在地址欄中輸入//網站域名/robots.txt即可,以查詢百度的robots協議為例;Disallow後邊的目錄是禁止所有搜索引擎搜索的

(2)或者藉助相關網站進行查看,如站長工具等,瀏覽器打開//s.tool.chinaz.com/robots,輸入網站地址,點擊查詢即可

1.1.2.不過度採集數據

過度數據採集會對目標站點產生非常大的壓力,可導致目標站點伺服器癱瘓、不能訪問等,相當於網路攻擊。學習過程中抓取數據不可貪多,滿足學習需求即可,損害他人權益的事不能做

1.1.3.不要採集隱私數據

有選擇的採集數據,別人不讓看的數據不要爬,私人數據不要爬,如手機號、身份證號、住址、個人財產等不要抓取,受法律保護的特定類型的數據或資訊不能抓取

1.1.4.網站有聲明」禁止爬蟲採集或轉載商業化」

當採集的站點有聲明,禁止爬蟲採集或轉載商業化,請繞行,不讓爬的數據不要爬

1.1.5.不得將抓取數據用於商業化使用

惡意利用爬蟲技術抓取數據,進行不正當競爭,甚至牟取不法利益,會觸犯法律,數據採集不得傷害他人利益

 

1.2.爬蟲與爬蟲工程師

爬蟲(又被稱為網頁蜘蛛,網路機器人),是一種按照一定的規則,自動的抓取萬維網資訊的程式或者腳本,是搜索引擎的重要組成;爬蟲可以用於以下場景:搜索引擎、數據分析、人工智慧、薅羊毛、搶車票等

目前市面主流的爬蟲產品有:神箭手、八爪魚、造數、后羿採集器等

爬蟲工程師簡單點理解就是數據的搬運工

爬蟲工程師技術儲備

  • python編程基礎
  • linux系統管理基礎
  • http協議
  • 資料庫增刪改查基礎

爬蟲技術怎麼學

  • 首先要學會基礎的Python語法知識
  • 學習Python爬蟲常用到的幾個重要內置庫Requests,用於請求網頁
  • 學習正則表達式re、Xpath(lxml)等網頁解析工具
  • 了解爬蟲的一些反爬機制,header、robot、代理IP、驗證碼等
  • 了解爬蟲與資料庫的結合,如何將爬取的數據進行存儲
  • 學習應用python的多執行緒、多進程進行爬取,提高爬蟲效率
  • 學習爬蟲的框架scrapy

 

2.網路基礎

2.1.網路協議

2.1.1什麼是協議?

協議可以理解為「規則」,是數據傳輸和數據的解釋規則,下圖是簡單圖解

2.1.2.OSI七層參考模型

  1. 物理層:可以理解為我們的網線,進行比特流的傳輸
  2. 數據鏈路層:可以理解為我們電腦的網卡,網卡的驅動可以提供介質訪問、鏈路管理等
  3. 網路層:網卡可以設置ip地址,進行網路定址和路由選擇
  4. 傳輸層:可以想像成電腦裡面的應用,建立主機端到端連接
  5. 會話層:建立、維護和管理會話
  6. 表示層:處理數據格式、數據加密等
  7. 應用層:提供應用程式間通訊

示例:以小明和小紅利用qq軟體發消息來再次講解下osi7層模型

小明在qq軟體裡面給小紅髮了一個「hello」

數據封裝

  • 小明_應用層:對小明發送的hello數據,加上應用層的報頭:應用層的數據協議單元
  • 小明_表示層:並不關心上一層的數據格式,把應用層整體的數據進行一個封裝,加上表示層的數據頭
  • 小明_會話層:對上一層數據加上會話層報頭並進行封裝
  • 小明_傳輸層:對上一層數據加上傳輸層報頭並進行封裝
  • 小明_網路層:對上一層數據加上網路層報頭並進行封裝
  • 小明_數據鏈路層:對上一層數據加上數據鏈路層報頭並進行封裝;同時還要對網路層的數據加上數據鏈路層報尾,形成最終的傳輸數據
  • 小明_物理層:發送給交換機

交換機:發送給路由器

路由器:發送給小紅的物理層

數據解封裝

  • 小紅_物理層:攔截小明的傳輸的數據,遞交給數據鏈路層
  • 小紅_數據鏈路層:丟掉小明數據的數據幀的頭部,進行數據校驗,數據沒有問題是給小紅的並且數據是完整的,將數據遞交給網路層
  • 小紅_網路層:同數據鏈路層,進行解封裝,並傳遞給上一層
  • 小紅_傳輸層:同數據鏈路層,進行解封裝,並傳遞給上一層
  • 小紅_會話層:同數據鏈路層,進行解封裝,並傳遞給上一層
  • 小紅_表示層:同數據鏈路層,進行解封裝,並傳遞給上一層
  • 小紅_應用層:同數據鏈路層,進行解封裝,小紅看到「hello」

2.1.3.TCP/IP模型

TCP/IP協議棧,TCP/IP協議繼承ISO模型網上有的說是四層有的說是五層,四層的是將物理層沒算進去,到底記哪一個,這個不衝突,都可以。

圖示tcp/ip相比較iso少了表示層、會話層

TCP/IP各層實現的協議

  • 應用層:
    • HTTP:超文本傳輸協議,基於TCP,使用80號埠,是用於www伺服器傳輸超文本到本地瀏覽器的傳輸協議
    • SMTP:簡單郵件傳輸協議,基於TCP,使用25號埠,是一組用於由源地址到目的地址傳送郵件的規則,用來控制信件的發送、中轉;比如QQ郵箱,用的就是這個協議
    • FTP:文件傳輸協議,基於TCP,一般上傳下載用FTP服務,數據埠20號,控制埠21
    • TELNET:遠程登錄協議,基於TCP,使用23號埠,是Internet遠程登錄服務的標準協議和主要方式。為用戶提供了在本地電腦上完成遠程主機工作的能力。在終端使用者的電腦上上使用telnet程式連接到伺服器。使用明碼傳送,保密性差、簡單方便
    • DNS:域名解析,基於UDP,使用53號埠,提供域名到IP地址之間的轉換
    • SSH:安全外殼協議,基於TCP,使用22號埠,為建立在應用層和傳輸層基礎上的安全協議。SSH是目前較可靠,專為遠程登錄會話和其他網路服務提供安全性的協議
  • 傳輸層:
    • TCP:傳輸控制協議。一種面向連接的、可靠的、基於位元組流的傳輸層協議
    • UDP:用戶數據報協議。一種面向無連接的通訊協議,不可靠的、基於報文的傳輸層通訊協議
    • SCTP:流量傳輸控制協議。一種面向連接的流傳輸協議;可以看成TCP的升級版
    • MPTCP:多路徑傳輸控制協議。TCP的多路徑版本。SCTP雖然在首發兩端有多條路徑,但實際只是使用一條路徑傳輸,當該條路徑出現故障時,不需要斷開連接,而是轉移到其他路徑。MPTCP真正意義上實現了多路徑並行傳輸,在連接建立階段,建立多條路徑,然後使用多條路徑同時傳輸數據
  •  網路層:
    • IP:Internet協議。通過路由選擇將下一條IP封裝後交給介面層。IP數據報是無連接服務
    • ICMP:Internet控制報文協議。是網路層的補充。用於在P主機、路由器之間傳遞控制消息,檢測網路通不通、主機是否可達、路由是否可用等網路本身的消息;cmd窗口ping地址就是用的這個協議
    • ARP:地址解析協議。通過目標設備的IP地址,查詢目標設備的MAC地址,以保證通訊的順利進行;常見於交換機路由器
    • RARP:反向地址解析協議

 

2.2.HTTP協議詳解

2.2.1.HTTP

HTTP協議,又稱之為超文本傳輸協議,是互聯網上應用最為廣泛的一種網路協議,它是基於TCP的應用層協議;

是客戶端和服務端進行通訊的一種規則,它的模式非常簡單,就是客戶端發起請求,服務端響應請求。

2.2.2.版本分布

  • HTTP最早於1991年發布,是0.9版,不過目前該版本已不再用
  • HTTP/1.0,於1996年5月發布,引入了多種功能,至今仍在使用當中
  • HTTP/1.1,於1997年1月發布,持久連接被默認採用,是目前最流行的版本
  • HTTP/2,於2015年5月發布,引入了伺服器推送等多種功能,是目前最新的版本

2.2.3.HTTP請求

  • 請求行:包含請求方法、請求地址和HTTP協議版本
  • 消息報頭:包含一系列的鍵值對
  • 請求正文(可選):注意和消息報頭之間有一個空行

2.2.4.HTTP請求方法

  • GET:從伺服器獲取指定(請求地址)的資源的資訊,它通常只用於讀取數據,就像資料庫查詢一樣,不會對資源進行修改
  • POST:向指定資源提交數據(比如提交表單,上傳文件),請求伺服器進行處理。數據被包含在請求正文中,這個請求可能會創建新的資源或更新現有的資源
  • PUT:通過指定資源的唯一標識(在伺服器上的具體存放位置),請求伺服器創建或更新資源
  • DELETE:請求伺服器刪除指定資源
  • HEAD:與GET方法類似,從伺服器獲取資源資訊,和GET方法不同的是,HEAD不含有呈現數據,僅僅是HTTP頭資訊。HEAD的好處在於,使用這個方法可以在不必傳輸全部內容的情況下,就可以獲得資源的元資訊(或元數據)
  • OPTIONS:該方法可使伺服器傳回資源所支援的所有HTTP請求方法;簡單理解就是查看伺服器支援哪些HTTP請求方法

2.2.5.HTTP響應

  • 狀態行:包含HTTP協議版本、狀態碼和狀態描述,以空格分隔
  • 響應頭:即消息報頭,包含一系列的鍵值對
  • 響應正文:返回內容,注意和響應頭之間有一個空行

 

2.2.6.HTTP響應狀態碼

  • 1XX 消息:請求已被服務接收,繼續處理
  • 2XX 成功:請求已成功被伺服器接收、理解、並接受
    • 200:OK
    • 201:Created 已創建
    • 202:Accepted 接收
    • 203:Non-Authoritative Information 非認證資訊
    • 204:No Content 無內容
  • 3XX 重定向:需要後續操作才能完成這一請求
    • 301:Moved Permanently 請求永久重定向
    • 302:Moved Temorarily 請求臨時重定向
    • 304:Not Modified 文件未修改,可以直接使用快取的文件
    • 305:Use Proxy 使用代理
  • 4XX 請求錯誤:請求含有此法錯誤或者無法被執行
    • 400:Bad Request 由於客戶端請求有語法錯誤,不能被伺服器所理解
    • 401:Unauthorized 請求未經授權。這個狀態程式碼必須和WWW-Authenticate報頭域一起使用
    • 403:Forbidden 伺服器收到請求,但是拒絕提供服務。伺服器通常會在響應正文中給出不提供服務的原因
    • 404:Not Found 請求的資源不存在,例如,輸入錯誤的URL
  • 5XX 伺服器錯誤:伺服器在處理某個正確請求時發生錯誤
    • 500:Internal Server Error 伺服器發生不可預期的錯誤,導致無法完成客戶端的請求
    • 503:Service Unavailable 伺服器當前不能夠處理客戶端的請求,在一段時間之後,伺服器肯能會恢復正常
    • 504:Gateway Time-out 網關超時

 

2.3.解析HTTP數據流的傳輸過程

 

以一個經典面試題作為縮影進行講解:

請簡述:從客戶端打開瀏覽器到伺服器返回網頁,中間的過程

 

2.3.1.宏觀解析

1)在一個客戶端上,打開瀏覽器,在瀏覽器的地址欄中,輸入www.baidu.com,訪問百度

2)在你敲入網址並按下回車之後,將會發生以下的事情:瀏覽器先嘗試從Host文件中獲取//www.baidu.com/對應的IP地址,如果能獲取到則直接使用hosts文件的解析結果;host文件在本地的C:\Windows\System32\drivers\etc目錄下

3)如果Host文件中找不到,就會使用DNS協議來獲取IP。在DNS協議中,PC會向你本地DNS求助,請求DNS伺服器之後,得到百度的IP

4)接下來瀏覽器會請求獲得的Ip地址對應的Web伺服器,Web伺服器接收到客戶的請求並響應處理,將客戶請求的內容返回給客戶端瀏覽器

5)如果伺服器正常則給你回個「OK」,狀態碼為200並將你要的數據傳給你。你收到伺服器的回復,是HTML形式的文本。瀏覽器必須能夠理解文本的內容,並快速的渲染到螢幕上,渲染出來後,你就能看到百度的首頁了

 

2.3.2.微觀解析

1)域名解析:同宏觀解析,通過本地host文件查找;找不到,PC請求本地DNS幫忙;最後得到域名的IP

2)建立連接:

TCP三次握手:雙向連接確認過程

  • step-1 監聽:首先client客戶端和server服務端都處於LISTEN監聽狀態
  • step-2 第一次握手(客戶端)
    • 客戶端告訴服務端我要訪問你,完成第一次握手;
    • 詳解為:客戶端會發送一個TCP的SYN,並且標誌位為1的這樣一個數據包;同時指明客戶端要連接伺服器的埠;發送完畢後,客戶端進入SYN_SYNSEND的狀態;並完成第一次握手
  • step-3 第二次握手(服務端)
    • 服務端告訴客戶端我收到了你的SYN數據包,你的內容為SYN=1,並且返回一個ACK=1的數據包,和客戶端的SYN=1一併打包發給客戶端;
    • 同時服務端由LISTEN狀態變成SYN_RCVD狀態;完成第二次握手
  • step-4 客戶端發送ACK給服務端
    • 客戶端再次訪問服務端,並發送ACK=1確認數據包,跟服務端確認是否一致
    • 發送完畢後客戶端進入ESTABLISHED狀態
  • step-5 第三次握手(服務端):
    • 服務端收到客戶端發過來的ACK=1數據包,確認無誤後,同樣進入ESTABLISHED狀態
    • 完成第三次握手

3)發送HTTP請求:同宏觀解析,客戶端發送get或post請求;伺服器正常給你返回200,OK,以及返回你要的html文本;客戶端對服務端給的heml文本進行解析、渲染、展示

4)斷開連接:

TCP四次揮手:雙向斷開確認

  • step-1 第一次揮手(客戶端)
    • 客戶端告訴服務端請求我已經發送完畢了,我想要跟你斷開連接了,沒有數據可以發送了,但是呢服務端你還能向我發送數據,我還能接收數據;
    • 詳解為:客戶端會發送一個TCP的FIN,並且標誌位為1的這樣一個數據包;告訴服務端我已經沒有數據可以發送了,但是我還能接收數據;發送完畢後,客戶端進入FIN_WAIT_1的狀態;並完成第一次揮手
  • step-2 第二次揮手(服務端)
    • 服務端確認了客戶端的FIN數據包,並回一個ACK=1的數據包,表明我接收到了客戶端關閉連接的請求,但是我這邊還沒有準備好關閉整個連接;
    • 同時服務端由進入CLOSE_WAIT狀態;完成第二次握手
  • step-3 客戶端接收ACK等待服務端關閉連接
    • 客戶端接收到服務端發過來的ACK=1數據包,客戶端狀態變更為FIN_WAIT_2狀態;並等待服務端關閉連接
  • step-4 第三次揮手(服務端)
    • 服務端向客戶端發送一個FIN=1的數據包,表明我可以關閉連接了,響應數據已經都發完了。
    • 服務端狀態變更為LAST_ACK;等待客戶端發送ACK確認包
  • step-5 第四次揮手(客戶端)
    • 客戶端收到服務端可以關閉的FIN數據包後,發送ACK=1包給服務端;告訴服務端,我這邊沒有問題,你關閉連接吧
    • 客戶端狀態變更為TIME_WAIT
  • step-6 服務端關閉連接
    • 服務端接收到客戶端發送的ACK=1確認包後,關閉連接;服務端狀態變更為CLOSED