Python3網絡爬蟲實戰---1五、爬蟲基礎：HTTP基本原理

上一篇文章： Python3網絡爬蟲實戰---1四、部署相關庫的安裝：Scrapyrt、Gerapy
下一篇文章： Python3網絡爬蟲實戰---1六、Web網頁基礎

在寫爬蟲以前，仍是須要了解一些爬蟲的基礎知識，如 HTTP 原理、網頁的基礎知識、爬蟲的基本原理、Cookies 基本原理等。

那麼本章內容就對一些在作爬蟲以前所須要的基礎知識作一些簡單的總結。

HTTP基本原理

在本節咱們會詳細瞭解 HTTP 的基本原理，瞭解在瀏覽器中敲入一個 URL 到獲取網頁內容發生了一個怎樣的過程，瞭解了這些內容，有助於去進一步瞭解爬蟲的基本原理。

1. URI、URL

在瞭解 HTTP 以前咱們先了解一下 URI 和 URL。咱們常常會聽到 URI 和 URL 兩個術語，URI 全稱爲 Uniform Resource Identifier，即統一資源標誌符，URL 全稱爲 Universal Resource Locator，即統一資源定位符。
舉例來講，https://github.com/favicon.ico，這是 GitHub 的網站圖標連接，它是一個 URL，也是一個 URI，即有這樣的一個圖標資源，咱們用 URL/URI 來惟一指定了它的訪問方式，這其中包括了訪問協議 https、訪問路徑/即根目錄，資源名稱 favicon.ico，經過這樣的一個連接咱們即可以從互聯網上找到這個資源，這就是 URL/URI。
URL 是 URI 的子集，也就是說每一個 URL 都是 URI，但不是每一個 URI 都是 URL。那麼怎樣的 URI 不是 URL 呢？URI 還包括一個子類叫作 URN，它的全稱爲 Universal Resource Name，即統一資源名稱。URN 只命名資源而不指定如何定位資源，如 urn:isbn:0451450523，它指定了一本書的 ISBN，能夠惟一標識這一本書，可是沒有指定到哪裏定位這本書，這就是 URN，URL、URN、URI 的關係能夠用圖 2-1 表示以下：

圖 2-1 URL、URN、URI 關係圖
可是在目前的互聯網，URN 的使用很是少，因此幾乎全部的 URI 都是 URL，因此通常的網頁連接咱們能夠稱之爲 URL，也能夠稱之爲 URI，我我的習慣稱之爲 URL。

2. 超文本

接下來咱們再瞭解一個概念，超文本。超文本英文名稱叫作 Hypertext，咱們在瀏覽器裏面看到的網頁就是超文本解析而成的，其網頁源代碼是一系列 HTML 代碼，裏面包含了一系列標籤，如 img 顯示圖片，p 指定顯示段落等，瀏覽器解析這些標籤後便造成了咱們日常看到的網頁，而這網頁的源代碼 HTML 就能夠稱做超文本。
例如咱們在 Chrome 瀏覽器裏面打開任意一個頁面，如淘寶首頁，右鍵點擊檢查，或按下快捷鍵 F12 便可打開瀏覽器的開發者工具，這時咱們在 Elements 選項卡便可看到當前網頁的源代碼，這些源代碼都是超文本，如圖 2-2 所示：

圖 2-2 源代碼

3. HTTP、HTTPS

咱們在前面瞭解了 URI 和 URL，例如淘寶的首頁：https://www.taobao.com/，在 URL 的開頭會有 http 或 https，這個就是訪問資源須要的協議類型，有時咱們還會看到 ftp、sftp、smb 開頭的 URL，那麼這裏的 ftp、sftp、smb 都是指的協議類型。在爬蟲中，咱們抓取的頁面一般就是 http 或 https 協議的，咱們在這裏首先來了解一下這兩個協議的含義。
HTTP 的全稱是 Hyper Text Transfer Protocol，中文名叫作超文本傳輸協議，HTTP 協議是用於從網絡傳輸超文本數據到本地瀏覽器的傳送協議，它能保證傳送高效而準確地傳送超文本文檔。HTTP 由萬維網協會（World Wide Web Consortium）和 Internet 工做小組IETF（Internet Engineering Task Force）共同合做制定的規範，目前普遍使用的是 HTTP 1.1 版本。
HTTPS 的全稱是 Hyper Text Transfer Protocol over Secure Socket Layer，是以安全爲目標的 HTTP 通道，簡單講是 HTTP 的安全版，即 HTTP 下加入 SSL 層，簡稱爲 HTTPS。
HTTPS 的安全基礎是 SSL，所以經過它傳輸的內容都是通過 SSL 加密的，它的主要做用能夠分爲兩種：

• 是創建一個信息安全通道，來保證數據傳輸的安全。
• 確認網站的真實性，凡是使用了 https 的網站，均可以經過點擊瀏覽器地址欄的鎖頭標誌來查看網站認證以後的真實信息，也能夠經過 CA 機構頒發的安全簽章來查詢。

如今愈來愈多的網站和 APP 都已經向 HTTPS 方向發展。例如：

• 蘋果公司強制全部 iOS App 在 2017 年 1 月 1 日 前所有改成使用 HTTPS 加密，不然 APP 就沒法在應用商店上架。谷歌從 2017 年 1 月推出的 Chrome 56 開始，對未進行 HTTPS 加密的網址連接亮出風險提示，即在地址欄的顯著位置提醒用戶「此網頁不安全」。
• 騰訊微信小程序的官方需求文檔要求後臺使用 HTTPS 請求進行網絡通訊，不知足條件的域名和協議沒法請求。

而某些網站雖然使用了 HTTPS 協議仍是會被瀏覽器提示不安全，例如咱們在 Chrome 瀏覽器裏面打開 12306，連接爲：https://www.12306.cn/，這時瀏覽器就會提示「您的鏈接不是私密鏈接」這樣的話，如圖 2-3 所示：

圖 2-3 12306 頁面
這是由於 12306 的 CA 證書是中國鐵道部本身頒發給本身的，而這個證書是不被官方機構承認的，因此這裏證書驗證就不會經過而提示這樣的話，可是實際上它的數據傳輸依然是通過 SSL 加密的。咱們若是要爬取這樣的站點就須要設置忽略證書的選項，不然會提示 SSL 連接錯誤，在後文會進行詳細說明。

4. HTTP請求過程

咱們在瀏覽器中輸入一個 URL，回車以後便會在瀏覽器中觀察到頁面內容，實際上這個過程是瀏覽器向網站所在的服務器發送了一個 Request，即請求，網站服務器接收到這個 Request 以後進行處理和解析，而後返回對應的一個 Response，即響應，而後傳回給瀏覽器，Response裏面就包含了頁面的源代碼等內容，瀏覽器再對其進行解析便將網頁呈現了出來，模型如圖 2-4 所示：

圖 2-4 模型圖
此處客戶端即表明咱們本身的 PC 或手機瀏覽器，服務器即要訪問的網站所在的服務器。
爲了更直觀地地說明這個的過程，咱們在這裏用 Chrome 瀏覽器的開發者模式下的 Network 監聽組件來作下演示，它能夠顯示訪問當前請求網頁時發生的全部網絡請求和響應。
打開 Chrome 瀏覽器，右鍵點擊檢查，或按下快捷鍵 F12 便可打開瀏覽器的開發者工具，咱們在這裏訪問百度：http://www.baidu.com/，輸入該 URL，敲擊回車訪問這個頁面，觀察一下在這個過程當中發生了怎樣的網絡請求，這時咱們能夠看到在 Network 頁面的下方出現了一個個的條目，那麼這一個條目就表明一次發送 Request 和接收 Response 的過程，如圖 2-5 所示：

圖 2-5 Network 面板
咱們觀察第一個網絡請求，即 www.baidu.com，如圖 2-6 所示：

圖 2-6 網絡請求記錄
這一個條目的各列分別表明：

• 第一列 Name，即 Request 的名稱。通常會用URL的最後一部份內容當作名稱。
• 第二列 Status，即 Response 的狀態碼。這裏顯示爲 200，表明 Response 是正常的，經過狀態碼咱們能夠判斷髮送了 Request 以後是否獲得了正常的 Response。
• 第三列 Type，即 Request 請求的文檔類型。這裏爲 document，表明咱們此次請求的是一個 HTML 文檔，內容就是一些 HTML 代碼。
• 第四列 Initiator，即請求源。用來標記 Request 是由哪一個對象或進程發起的。
• 第五列 Size，即從服務器下載的文件和請求的資源大小。若是是從緩存中取得的資源則該列會顯示 from cache。
• 第六列 Time，即發起 Request 到獲取到 Response 所用的總時間。
• 第七列 Timeline，即網絡請求的可視化瀑布流。咱們點擊這個條目便可看到其更詳細的信息，如圖 2-7 所示：

圖 2-7 詳細信息
首先是 General 部分，Request URL 爲 Request 的 URL，Request Method 爲請求的方法，Status Code 爲響應狀態碼，Remote Address 爲遠程服務器的地址和端口，Referrer Policy 爲 Referrer 判別策略。
再繼續往下看能夠看到有一個 Response Headers 和一個 Request Headers，這分別表明響應頭和請求頭，請求頭裏面帶有許多請求信息，例如瀏覽器標識、Cookies、Host 等信息，這是 Request 的一部分，服務器會根據請求頭內的信息判斷請求是否合法，進而做出對應的響應，返回 Response，那麼在圖中看到的 Response Headers 就是 Response 的一部分，例如其中包含了服務器的類型、文檔類型、日期等信息，瀏覽器接受到 Response 後，會解析響應內容，進而呈現網頁內容。
下面咱們分別來介紹一下請求 Request 和響應 Response 都包含了哪些內容，在這裏進行對其組成進行總結：

5. Request

Request，即請求，由客戶端向服務端發出。能夠將 Request 劃分爲四部份內容：Request Method、Request URL、Request Headers、Request Body，即請求方式、請求連接、請求頭、請求體。

Request Method

請求方式，請求方式常見的有兩種類型，GET 和 POST。
咱們在瀏覽器中直接輸入一個 URL 並回車，這便發起了一個 GET 請求，請求的參數會直接包含到 URL 裏，例如百度搜索 Python，這就是一個 GET 請求，連接爲：https://www.baidu.com/s?wd=Py...，URL 中包含了請求的參數信息，這裏參數 wd 就是要搜尋的關鍵字。POST 請求大多爲表單提交發起，如一個登陸表單，輸入用戶名密碼，點擊登陸按鈕，這一般會發起一個 POST 請求，其數據一般以 Form Data 即表單的形式傳輸，不會體如今 URL 中。

GET 和 POST 請求方法有以下區別：

• GET 方式請求中參數是包含在 URL 裏面的，數據能夠在 URL 中看到，而 POST 請求的 URL 不會包含這些數據，數據都是經過表單的形式傳輸，會包含在 Request Body 中。
• GET 方式請求提交的數據最多隻有 1024 字節，而 POST 方式沒有限制。

因此通常來講，網站登陸驗證的時候，須要提交用戶名密碼，這裏包含了敏感信息，使用GET方式請求的話密碼就會暴露在URL裏面，形成密碼泄露，因此這裏最好以POST方式發送。文件的上傳時，因爲文件內容比較大，也會選用POST方式。
咱們日常遇到的絕大部分請求都是 GET 或 POST 請求，另外還有一些請求方式，如 HEAD、PUT、DELETE、OPTIONS、CONNECT、TRACE，咱們簡單將其總結以下：

本表參考：http://www.runoob.com/http/ht...。

Request URL

顧名思義，就是請求的網址，即統一資源定位符，用 URL 能夠惟一肯定咱們想請求的資源。

Request Headers

請求頭，用來講明服務器要使用的附加信息，比較重要的信息有 Cookie、Referer、User-Agent 等，下面將一些經常使用的頭信息說明以下：

• Accept，請求報頭域，用於指定客戶端可接受哪些類型的信息。
• Accept-Language，指定客戶端可接受的語言類型。
• Accept-Encoding，指定客戶端可接受的內容編碼。
• Host，用於指定請求資源的主機 IP 和端口號，其內容爲請求 URL 的原始服務器或網關的位置。從 HTTP 1.1 版本開始，Request 必須包含此內容。
• Cookie，也經常使用複數形式 Cookies，是網站爲了辨別用戶進行 Session 跟蹤而儲存在用戶本地的數據。Cookies 的主要功能就是維持當前訪問會話，例如咱們輸入用戶名密碼登陸了某個網站，登陸成功以後服務器會用 Session 保存咱們的登陸狀態信息，後面咱們每次刷新或請求該站點的其餘頁面時會發現都是保持着登陸狀態的，在這裏就是 Cookies 的功勞，Cookies 裏有信息標識了咱們所對應的服務器的 Session 會話，每次瀏覽器在請求該站點的頁面時都會在請求頭中加上 Cookies 並將其發送給服務器，服務器經過 Cookies 識別出是咱們本身，而且查出當前狀態是登陸的狀態，因此返回的結果就是登陸以後才能看到的網頁內容。
• Referer，此內容用來標識這個請求是從哪一個頁面發過來的，服務器能夠拿到這一信息並作相應的處理，如作來源統計、作防盜鏈處理等。
• User-Agent，簡稱 UA，它是一個特殊字符串頭，使得服務器可以識別客戶使用的操做系統及版本、瀏覽器及版本等信息。在作爬蟲時加上此信息能夠假裝爲瀏覽器，若是不加極可能會被識別出爲爬蟲。
• Content-Type，即 Internet Media Type，互聯網媒體類型，也叫作 MIME 類型，在 HTTP 協議消息頭中，使用它來表示具體請求中的媒體類型信息。例如 text/html 表明 HTML 格式，image/gif 表明 GIF 圖片，application/json 表明 Json 類型，更多對應關係能夠查看此對照表：http://tool.oschina.net/commons。

所以，Request Headers 是 Request 等重要組成部分，在寫爬蟲的時候大部分狀況都須要設定 Request Headers。

Request Body

即請求體，通常承載的內容是 POST 請求中的 Form Data，即表單數據，而對於 GET 請求 Request Body 則爲空。
例如在這裏我登陸 GitHub 時捕獲到的 Request 和 Response 如圖 2-8 所示：

圖 2-8 詳細信息
在登陸以前咱們填寫了用戶名和密碼信息，提交時就這些內容就會以 Form Data 的形式提交給服務器，此時注意 Request Headers 中指定了 Content-Type 爲 application/x-www-form-urlencoded，只有設置 Content-Type 爲 application/x-www-form-urlencoded 纔會以 Form Data 形式提交，另外咱們也能夠將 Content-Type 設置爲 application/json 來提交 Json 數據，或者設置爲 multipart/form-data 來上傳文件。
下面列出了 Content-Type 和 POST 提交數據方式的關係：

Content-Type	提交數據方式
application/x-www-form-urlencoded	Form表單提交
multipart/form-data	表單文件上傳提交
application/json	序列化Json 數據提交
text/xml	XML數據提交

在爬蟲中若是咱們要構造 POST 請求須要注意這幾種 Content-Type，瞭解各類請求庫的各個參數設置時使用的是哪一種 Content-Type，否則可能會致使 POST 提交後得不到正常的 Response。
以上即是對 Request 各部份內容的解釋。

6. Response

Response，即響應，由服務端返回給客戶端。Response 能夠劃分爲三部分，Response Status Code、Response Headers、Response Body。

Response Status Code

響應狀態碼，此狀態碼錶示了服務器的響應狀態，如 200 則表明服務器正常響應，404 則表明頁面未找到，500 則表明服務器內部發生錯誤。在爬蟲中，咱們能夠根據狀態碼來判斷服務器響應狀態，如判斷狀態碼爲 200，則證實成功返回數據，再進行進一步的處理，不然直接忽略。
下面用表格列出了常見的錯誤代碼及錯誤緣由：

狀態碼	說明	詳情
100	繼續	請求者應當繼續提出請求。服務器已收到請求的一部分，正在等待其他部分。
101	切換協議	請求者已要求服務器切換協議，服務器已確認並準備切換。
200	成功	服務器已成功處理了請求。
201	已建立	請求成功而且服務器建立了新的資源。
202	已接受	服務器已接受請求，但還沒有處理。
203	非受權信息	服務器已成功處理了請求，但返回的信息可能來自另外一來源。
204	無內容	服務器成功處理了請求，但沒有返回任何內容。
205	重置內容	服務器成功處理了請求，內容被重置。
206	部份內容	服務器成功處理了部分請求。
300	多種選擇	針對請求，服務器可執行多種操做。
301	永久移動	請求的網頁已永久移動到新位置，即永久重定向。
302	臨時移動	請求的網頁暫時跳轉到其餘頁面，即暫時重定向。
303	查看其餘位置	若是原來的請求是 POST，重定向目標文檔應該經過 GET 提取。
304	未修改	這次請求返回的網頁未修改，繼續使用上次的資源。
305	使用代理	請求者應該使用代理訪問該網頁。
307	臨時重定向	請求的資源臨時從其餘位置響應。
400	錯誤請求	服務器沒法解析該請求。
401	未受權	請求沒有進行身份驗證或驗證未經過。
403	禁止訪問	服務器拒絕此請求。
404	未找到	服務器找不到請求的網頁。
405	方法禁用	服務器禁用了請求中指定的方法。
406	不接受	沒法使用請求的內容響應請求的網頁。
407	須要代理受權	請求者須要使用代理受權。
408	請求超時	服務器請求超時。
409	衝突	服務器在完成請求時發生衝突。
410	已刪除	請求的資源已永久刪除。
411	須要有效長度	服務器不接受不含有效內容長度標頭字段的請求。
412	未知足前提條件	服務器未知足請求者在請求中設置的其中一個前提條件。
413	請求實體過大	請求實體過大，超出服務器的處理能力。
414	請求 URI 過長	請求網址過長，服務器沒法處理。
415	不支持類型	請求的格式不受請求頁面的支持。
416	請求範圍不符	頁面沒法提供請求的範圍。
417	未知足指望值	服務器未知足指望請求標頭字段的要求。
500	服務器內部錯誤	服務器遇到錯誤，沒法完成請求。
501	未實現	服務器不具有完成請求的功能。
502	錯誤網關	服務器做爲網關或代理，從上游服務器收到無效響應。
503	服務不可用	服務器目前沒法使用。
504	網關超時	服務器做爲網關或代理，可是沒有及時從上游服務器收到請求。
505	HTTP 版本不支持	服務器不支持請求中所用的 HTTP 協議版本。

Response Headers

響應頭，其中包含了服務器對請求的應答信息，如 Content-Type、Server、Set-Cookie 等，下面將一些經常使用的頭信息說明以下：
Date，標識 Response 產生的時間。Last-Modified，指定資源的最後修改時間。Content-Encoding，指定 Response 內容的編碼。Server，包含了服務器的信息，名稱，版本號等。Content-Type，文檔類型，指定了返回的數據類型是什麼，如text/html 則表明返回 HTML 文檔，application/x-javascript 則表明返回 JavaScript 文件，image/jpeg 則表明返回了圖片。Set-Cookie，設置Cookie，Response Headers 中的 Set-Cookie即告訴瀏覽器須要將此內容放在 Cookies 中，下次請求攜帶 Cookies 請求。Expires，指定 Response 的過時時間，使用它能夠控制代理服務器或瀏覽器將內容更新到緩存中，若是再次訪問時，直接從緩存中加載，下降服務器負載，縮短加載時間。Resposne Body
即響應體，最重要的當屬響應體內容了，響應的正文數據都是在響應體中，如請求一個網頁，它的響應體就是網頁的 HTML 代碼，請求一張圖片，它的響應體就是圖片的二進制數據。因此最主要的數據都包含在響應體中了，咱們作爬蟲請求網頁後要解析的內容就是解析響應體，如圖 2-9 所示：

圖 2-9 響應體內容
咱們在瀏覽器開發者工具中點擊 Preview，就能夠看到網頁的源代碼，這也就是響應體內容，是解析的目標。
咱們在作爬蟲時主要解析的內容就是 Resposne Body，經過 Resposne Body 咱們能夠獲得網頁的源代碼、Json 數據等等，而後從中作相應內容的提取。
以上即是 Response 的組成部分。

7. 結語

本節咱們瞭解了 HTTP 的基本原理，經過如上描述，咱們應該對訪問網頁背後的請求和響應過程有了大致的認識，本節涉及到的知識點須要好好掌握，在後面分析網頁請求的時候會常常用到。

上一篇文章： Python3網絡爬蟲實戰---1四、部署相關庫的安裝：Scrapyrt、Gerapy
下一篇文章： Python3網絡爬蟲實戰---1六、Web網頁基礎