學習爬蟲前你需要知道這些
I. 什麼是爬蟲？
爬蟲的概念
爬蟲是模仿用戶在網頁的操作，以完成一些數據量較大的訪問或爬取工作。小則爬取圖片、視頻，大則爬取圖片庫，甚至爬取整個網站
更加專業和全面的定義是：僞裝成**客戶端（Client）的網絡爬蟲與服務端（Server）**進行數據交互。
請求與響應
在用戶訪問網站時，會通過瀏覽器發出請求，然後再獲取響應信息，進而得到一個完整的網頁界面，基本原理如下圖：
-
**請求（Request）：**包含了請求信息的HTTP報文，由客戶端發送給服務端
-
**響應（Response）😗*包含了響應信息的HTTP報文，由服務端發送給客戶端
舉個🌰
以下是用戶訪問百度時客戶端和服務器作出的操作:
- 用戶訪問網址www.baidu.com, 客戶端(即瀏覽器)會構造請求併發送給百度服務器
- 服務器接收到請求後, 分析出請求的目的:
獲取百度首頁頁面, 接着構造響應並返回給客戶端 - 客戶端接收到響應, 對其中的數據資源進行加載和渲染, 將結果(即百度首頁)呈現給用戶
參考理論
II. robots協議
在爬取某個網站時要儘量遵循該協議，查看協議的方法，例如百度：https://www.baidu.com/robots.txt
在這個文件中聲明該網站中不想被蜘蛛訪問的部分，這樣，該網站的部分或全部內容就可以不被搜索引擎訪問和收錄了，或者可以通過robots.txt指定使搜索引擎只收錄指定的內容
III. HTTP和HTTPS
HTTP協議
HTTP是Hyper Text Transfer Protocol（超文本傳輸協議）的縮寫，是用於從萬維網（WWW:World Wide Web ）服務器傳輸超文本到本地瀏覽器的傳送協議。
HTTP是基於TCP/IP通信協議來傳遞數據（HTML 文件, 圖片文件, 查詢結果等）
通過TCP/IP通信協議來在Client和Server之間建座橋，HTTP請求和響應就在這座橋上傳遞.，請求和響應中包含着相關信息
HTTP請求流程
一次http請求的基本流程是:
- 客戶端向服務端發起一次請求(request)
- 服務器在接收到以後返回給客戶端一個響應(response)
所以一次完整的http請求包含請求和響應兩部分。
HTTP服務器默認監聽80端口
HTTPS協議
HTTPS（全稱：Hyper Text Transfer Protocol over Secure Socket Layer 或 Hypertext Transfer Protocol Secure，超文本傳輸安全協議），是以安全爲目標的HTTP通道，簡單講是HTTP的安全版
http協議是基於TCP/IP通信協議的，而https是在http協議的基礎之上，再加了一層SSL/TLS協議，數據在傳輸過程中是加密的。
HTTPS協議的默認端口是443
HTTP和HTTPS的區別
https://blog.csdn.net/xiaoming100001/article/details/81109617
簡單來說, HTTP和HTTPS的區別主要有兩點:
- HTTP默認端口是80,而HTTPS默認端口是443
- HTTP是明文傳輸, HTTPS是採用SSL/TLS加密傳輸, 會比較安全
HTTP協議的特點
HTTP三個特點：
- HTTP是無連接：無連接的含義是限制每次連接只處理一個請求。服務器處理完客戶的請求，並收到客戶的應答後，即斷開連接。採用這種方式可以節省傳輸時間。
- HTTP是媒體獨立的：這意味着，只要客戶端和服務器知道如何處理的數據內容，任何類型的數據都可以通過HTTP發送。客戶端以及服務器指定使用適合的MIME-type內容類型。
- HTTP是無狀態：HTTP協議是無狀態協議。無狀態是指協議對於事務處理沒有記憶能力。缺少狀態意味着如果後續處理需要前面的信息，則它必須重傳，這樣可能導致每次連接傳送的數據量增大。另一方面，在服務器不需要先前信息時它的應答就較快。
IIII. URL
發送http請求時，通過url對網絡資源進行定位。
URL（Uniform Resource Locator），中文叫統一資源定位符。是用來標識某一處資源的地址。也即是我們常說的網址。以下面這個URL爲例，介紹下普通URL的各部分組成：
V. 請求
HTTP請求報文
客戶端發送一個HTTP Request到服務器的請求消息包括以下部分：請求行，請求頭，空行和請求數據。
http報文的結構，請參考http://www.runoob.com/http/http-messages.html
\n是換行，英文是New line。\r是回車，英文是Carriage return
HTTP請求方法
GET
該方法主要是用來獲取數據，一般不涉及修改服務器中的數據，比如查看圖片或者網站頁面
get方法攜帶的參數會直接展示在url中
POST
該方法相對GET方法要安全一點，用來提交相關數據到服務器，比如提交用戶登錄數據修改用戶密碼，修改相關信息等操作
post方法攜帶的參數是通過後端提交的,不會展示在url中
更多請求方法:
友情鏈接：http://www.runoob.com/http/http-methods.html
HTTP請求頭
友情鏈接：https://www.cnblogs.com/printN/p/6534529.html
HTTP請求正文
請求正文通常是使用POST方法進行發送的數據，GET方法是沒有請求正文的。
請求正文跟上面的消息報頭由一個空行隔開。
VI. 響應
HTTP響應報文
HTTP響應也由四個部分組成，分別是：狀態行、消息報頭、空行和響應正文。參考響應報文格式
需要注意的是響應報頭中的Content-length是以字節單位計算的
HTTP響應狀態碼
當客戶端向服務端發起一次請求後，服務端在返回的響應頭中會包含一個HTTP狀態碼。
HTTP的狀態碼是由三位數字來表示的，由第一位數字來表示狀態碼的類型，一般來說有五種類型：
| 分類 | 描述 |
|---|---|
| 1** | 信息，服務器收到請求，需要請求者據徐執行操作 |
| 2** | 成功，操作被成功接收並處理 |
| 3** | 重定向，需要進一步的操作以完成請求 |
| 4** | 客戶端錯誤，請求包含語法錯誤或無法完成請求 |
| 5** | 服務器錯誤，服務器在處理請求的過程中發生了錯誤 |
更多響應碼信息請參考http://www.runoob.com/http/http-status-codes.html
HTTP響應報頭
請參考:http://www.runoob.com/http/http-header-fields.html
VII. Cookie
http cookie 詳情：https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Cookies
HTTP是無狀態的，協議本身不涉及保存訪問記錄, 也就是請求和響應過程中不保存相關記錄信息, 這樣的特性會造成兩個現狀:
- 基於HTTP實現的應用在數據交互時, 交互速度比較快
- 由於不記錄信息, 服務器無法區分訪問自己的客戶端.
舉個例子: A是客戶端, B是服務端, 進行兩次交互.
第一次交互:
A: 嗨, 我叫張三, 你叫什麼名字呢?
B: 你好, 我的名字是李四.
第二次交互:
A: 考考你, 你知道我的名字麼?我剛說過哦.
B: 我怎麼會知道你的名字呢!我們才第一次見面.
可見服務端是無法區分同一個用戶的連續請求，同樣就更不能區分多個用戶的多個請求.
由於網站或其他應用在工作中存在需要區分用戶信息的業務, 所以就需要去解決HTTP無狀態的問題, 但是應該用什麼樣的方式解決呢?
既然HTTP報文能包含數據, 那爲什麼不讓服務器在響應中添加點東西, 比如特徵, 特殊值. 那麼客戶端收到響應後就把這些特殊值保存下來, 在下次請求的時候帶上這些值發送給服務器, 這樣服務器就知道客戶端是誰了.
再舉個例子: 人物有前面的A和B以及嫌疑人X
第一次交互:
A: 你好, 我想辦張銀行卡, 我先存100萬元, 我的名字是張三, 賬號和密碼設置爲…
B: 張三女士, 這是你的銀行卡(set-cookie), 存款和賬號密碼都設置好了, 賬號和密碼就印在銀行卡上, 你記得好好保管哦.
第二次交互:
A: 你好, 我想取1萬, 這是我的銀行卡.
B: 好的, 銀行卡上面的印的賬號和密碼是正確的, 錢都取出來了哦.插曲: A的銀行卡被X偷了.
第三次交互:
X: 你好, 我要把錢取完. 我是李四.
B: 好的,銀行卡上面的印的賬號和密碼是正確的, 錢都取出來了哦
小結:
用戶的個人信息一般會放在Cookie中(這些信息可以是賬號和密碼, 也可以是其他東西), 用來在訪問特定頁面時(如訪問個人中心頁面)包含在請求中, 發給服務器驗證.但是Cookie若被駭客盜用, 那麼駭客也能去訪問用戶的個人中心頁面, 就像上面的第三次交互.
VIII. Session
Session翻譯爲會話, 其含義與字面含義差不多, 指有始有終的一系列動作/消息，比如打電話時從拿起電話撥號到掛斷電話這中間的一系列過程可以稱之爲一個session。 其作用也是用來讓服務器區分客戶端信息.
那麼問題來了, 爲什麼Cookie已經解決的問題, 會讓Session再解決一次呢?
顯然科學家或工程師們不會幹這樣明顯且重複的事, Cookie和Session是不同的.
Session雖然作用和Cookie類似, 但是Session只是一個ID號或者說是一個標記.
通過前面的故事, 我們得知Cookie是不夠安全的, 用戶的信息如賬戶和密碼是直接放在客戶端(如瀏覽器)的, 若用戶的執行了一些危險操作, 那麼就會造成信息泄漏等安全問題.
Session爲了解決這個問題, 服務器會將用戶的信息放在服務器上, 然後生成與用戶信息匹對的SessionID號, 並通過響應發送給用戶, 客戶端會保存該信息, 在客戶端中該信息一般是一堆加密後的字符.
舉個例子: E爲客戶端, F爲服務器.
第一次交互:
E: 你好游泳館館長, 我叫Gollum, 這是我的衣服, 麻煩放你這裏了.
F: 好的大帥哥, 你的東西都放我這了, 這是一個id卡, 你運動完了用id卡來取衣服就行了, 但是注意出游泳館id卡會失效哦.