解讀爬蟲中HTTP的祕密（基礎篇）

時間 2019-11-16

原文原文鏈接

做者：xiaoyuhtml

微信公衆號：Python數據科學web

知乎：zhuanlan.zhihu.com/pypcfx算法

在學習爬蟲的過程當中，相信你們對HTTP這個詞已經不陌生了，它好像從未離開過咱們的視線。被迫所需，咱們每次都要使用開發者工具去查看請求頭，響應頭，以及頭中的各個字段，使用別人封裝好的模塊填入信息，敲幾行代碼就解決了。面對簡單的爬取任務，咱們也許根本不用管它是什麼，但可能等咱們真正遇到問題的時候，卻無從下手。瀏覽器

認識並深入理解HTTP對於爬蟲的實現過程是很是有幫助的。爲了更好的讓你們理解爬蟲中的HTTP，博主將分爲兩篇對HTTP進行講述，<基礎篇> 和 <高階篇>。本篇爲基礎篇，將從如下幾個部分進行闡述。緩存

什麼是HTTP
一個完整的HTTP請求過程
HTTP請求報文

什麼是HTTP？

<HTTP的介紹>

引自百度百科的權威回答：安全

超文本傳輸協議（HTTP，HyperText Transfer Protocol) 是互聯網上應用最爲普遍的一種網絡協議。全部WWW文件都必須遵照這個標準。設計HTTP最初的目的是爲了提供一種發佈和接收HTML頁面的方法。 1960年美國人TedNelson構思了一種經過計算機處理文本信息的方法，並稱之爲超文本（hypertext）,這成爲了HTTP超文本傳輸協議標準架構的發展根基。TedNelson組織協調萬維網協會（World Wide Web Consortium）和互聯網工程工做小組（InternetEngineering Task Force ）共同合做研究，最終發佈了一系列的RFC，其中著名的RFC 2616定義了HTTP 1.1。服務器

HTTP協議是用於從WWW服務器傳輸超文本到本地瀏覽器的傳輸協議。它可使瀏覽器更加高效，使網絡傳輸減小。它不只保證計算機正確快速地傳輸超文本文檔，還肯定傳輸文檔中的哪一部分，以及哪部份內容首先顯示(如文本先於圖形)等。微信

<HTTP的模型>

HTTP採用了瀏覽器/服務器這種請求/響應模型，瀏覽器永遠是HTTP請求的發起者，服務器爲響應者。網絡

這樣在瀏覽器客戶端沒有發起請求的狀況下，服務器是不能主動推送消息給客戶端的。架構

<HTTP的定位>

HTTP是一個應用層協議，是咱們想從服務器端獲取信息的最直觀的請求。好比，在爬蟲中使用的<urllib模塊>，<requests模塊>等都是封裝了HTTP協議，做爲一個HTTP客戶端實現了博文，圖片，視頻等信息源的下載。

可是HTTP也不是直接就能夠用的，它的請求是創建在一些底層協議的基礎上完成的。如TCP/IP協議棧中，HTTP須要TCP的三次握手鍊接成功後才能向服務器發起請求。固然，若是是HTTPS的話，還須要TSL和SSL安全層。

一個完整的HTTP請求過程

既然HTTP協議須要創建在其它底層協議基礎上，咱們來看看一個完整的HTTP請求是什麼樣的。

當咱們點擊一個連接或者輸入一個連接的時候，整個HTTP的請求過程就開始了，而後通過如下步驟獲得最後的信息，咱們這裏簡單介紹一下前四個步驟，旨在瞭解HTTP。

域名解析：首先會搜索各類本地DNS緩存，若是沒有就會向DNS服務器（互聯網提供商）發起域名解析，以獲取IP地址。
創建TCP鏈接：當獲取IP後，將建立套接字socket鏈接，也就是TCP的3次握手鏈接，默認端口號80。
HTTP請求：一旦TCP鏈接成功後，瀏覽器/爬蟲就能夠向服務器發起HTTP請求報文了，報文內容包含請求行、請求頭部、請求主體。
服務器響應：服務器響應，並返回一個HTTP響應包（若是成功會返回狀態碼200）和請求的HTML代碼。上面的步驟<3>和<4>能夠簡單的示意以下，更方便你們理解。其中，請求和響應都包含特定格式的信息，具體咱們接下來會繼續解讀。

響應HTTP請求會返回響應狀態碼，根據狀態碼能夠知道返回信息的狀態。狀態碼規定以下：

1xx: 信息響應類，表示接收到請求而且繼續處理
100——必須繼續發出請求
101——要求服務器根據請求轉換HTTP協議版本
2xx: 處理成功響應類，表示動做被成功接收、理解和接受 200——交易成功
201——提示知道新文件的URL
202——接受和處理、但處理未完成
203——返回信息不肯定或不完整
204——請求收到，但返回信息爲空
205——服務器完成了請求，用戶代理必須復位當前已經瀏覽過的文件
206——服務器已經完成了部分用戶的GET請求
3xx: 重定向響應類，爲了完成指定的動做，必須接受進一步處理
300——請求的資源可在多處獲得
301——刪除請求數據
302——在其餘地址發現了請求數據
303——建議客戶訪問其餘URL或訪問方式
304——客戶端已經執行了GET，但文件未變化
305——請求的資源必須從服務器指定的地址獲得
306——前一版本HTTP中使用的代碼，現行版本中再也不使用
307——申明請求的資源臨時性刪除
4xx: 客戶端錯誤，客戶請求包含語法錯誤或者是不能正確執行
400——錯誤請求，如語法錯誤
401——未受權
402——保留有效ChargeTo頭響應
403——禁止訪問
404——沒有發現文件、查詢或URl
405——在Request-Line字段定義的方法不容許
406——根據發送的Accept，請求資源不可訪問
407——用戶必須首先在代理服務器上獲得受權
408——客戶端沒有在指定的時間內完成請求
409——對當前資源狀態，請求不能完成
410——服務器再也不有此資源且無進一步地址
411——服務器拒絕用戶定義的Content-Length
412——一個或多個請求頭字段在當前請求中錯誤
413——請求的資源大於服務器容許的大小
414——請求的資源URL長於服務器容許的長度
415——請求資源不支持請求項目格式
416——請求中包含Range請求頭字段，在當前請求資源範圍內沒有range指示值，請求也不包含If-Range請求頭字段
417——服務器不知足請求Expect頭字段指定的指望值，若是是代理服務器，多是下一級服務器不能知足請求長。
5xx: 服務端錯誤，服務器不能正確執行一個正確的請求
500——內部服務器錯誤
501——未實現
502——網關錯誤

HTTP請求報文

相信你已經對HTTP的請求過程有了大體的瞭解了，下面咱們來詳細介紹HTTP請求的報文信息。報文內容包含請求行、請求頭部、請求主體。

下面咱們來看一下經過開發者工具請求www.baidu.com/網址截取下來的HTTP請求報文內容，對比一下上面的標準格式。

咱們發現請求報文的格式與上面基本一致，正式咱們想要的。那麼，接下來咱們將要逐個的介紹以上各個信息。

請求行

<GET>是HTTP的請求方式之一，HTTP/1.1協議中共定義了8種方法與服務器交互，有 GET、POST、HEAD、PUT、DELETE、OPTIONS、TRACE、CONNECT，其中比較經常使用的是**和**方法了。

HEAD: 從服務器獲得除了請求體與GET請求同樣的響應
GET：經過URL獲取查詢資源信息（爬蟲特定URL爬取）
POST：提交表單（爬蟲中的模擬登陸）
PUT：上傳文件（瀏覽器不支持）
DELETE：刪除
OPTIONS：返回服務器對特定資源支持的HTTP請求方法
TRACE：返回服務器收到的請求，用於測試或診斷 CONNECT：預留給管道鏈接方式的代理服務

GET請求方法後URL（這裏是/）和版本1.1，別忘了空格。

請求頭

HTTP的頭域包括通用頭、請求頭、響應頭和實體頭四部分。由於在爬蟲過程當中，咱們常常會提交headers請求頭信息用於假裝，因此咱們這裏對請求頭着重講解一下。

請求頭是請求報文特有的，它向服務器提交了一些額外的信息，例如經過Accept字段信息，咱們客戶端能夠告訴服務器咱們接受一些什麼類型的數據。而咱們其實能夠把這些字段信息就當成**<鍵值對>**對待。

下面咱們看看這些字段都表明了什麼意思？

`Accept`

內容：text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,/;q=0.8
含義：告訴瀏覽器咱們接受MIME的類型

`Accept-Encoding`

內容：gzip, deflate, br
含義：若是有這個字段，則表明客戶端支持壓縮將內容編碼，去掉後會支持任意編碼。
注意：爬蟲時通常不要把它加上，博主最開始就是不懂全都複製過來，結果由於這個就是很差使卡住好長時間。

`Accept-Lanague`

內容：zh-CN,zh;q=0.9
含義：告訴服務器可以接受的語言，沒有則表明任何語言

`Connection`

內容：keep-alive
含義：告訴服務器須要持久有效的鏈接狀態（HTTP1.1默認會進行持久鏈接）

`Host`

內容：www.baidu.com
含義：客戶端指定本身想訪問的web服務器域名/IP地址和端口號

`Cache-control`

內容：max-age=0 含義：(引自百度百科)

Cache-Control 是最重要的規則。這個字段用於指定全部緩存機制在整個請求/響應鏈中必須服從的指令。這些指令指定用於阻止緩存對請求或響應形成不利干擾的行爲。這些指令一般覆蓋默認緩存算法。緩存指令是單向的，即請求中存在一個指令並不意味着響應中將存在同一個指令。

網頁的緩存是由HTTP消息頭中的「Cache-control」來控制的，常見的取值有private、no-cache、max-age、must-revalidate等，默認爲private。

可是HTTP請求和響應的Cache-Control是不徹底同樣的。常見的請求Cache-Control取值有<no-cache>, <no-store>, <max-age>, <max-stale>, <min-fresh>, <only-if-cached>。

響應的Cache-Control取值有<public>, <private>, <no-cache>, <no- store>, <no-transform>, <must-revalidate>, <proxy-revalidate>, <max-age>。

咱們這裏主要介紹請求時的常見Cache-Control取值。

<1>max-age<=0 本例中使用max-age=0，表示每次請求會訪問服務器，經過Last-Modified來判斷文件是否被修改，若是被修改，返回狀態碼200並獲得最新文件，不然將返回304狀態碼並讀取緩存文件。

<2>max-age>0 表示會直接從瀏覽器提取緩存。

<3>no-cache 表示不會在瀏覽器緩存進行提取，而是強制的向服務器發出請求，這樣能夠保證客戶端可以收到最權威的迴應。

<4>no-store 全部內容都不會被緩存到緩存或Internet臨時文件中。