爬蟲基礎-http請求的基礎知識

百度百科上這麼介紹爬蟲：

網絡爬蟲（又被稱為網頁

蜘蛛 ，網絡機器人，在 FOAF 社群中間，更經常的稱為網頁追逐者），是一種按照一定的規則，自動地抓取 網際網路

資訊的程式或者腳本。

在開發爬蟲時常用的工具：chrome浏覽器，fiddler工具，postman插件。

有關fiddler知識的位址：

http://kb.cnblogs.com/page/130367/ 下面普及最基礎的知識：Http請求。（下面知識來源于： http://www.runoob.com/http/http-intro.html

）

定義：

HTTP協定是Hyper Text Transfer Protocol（超文本傳輸協定）的縮寫,是用于從網際網路（WWW:World Wide Web ）伺服器傳輸超文本到本地浏覽器的傳送協定。TTP是一個基于TCP/IP通信協定來傳遞資料（HTML 檔案, 圖檔檔案, 查詢結果等）。

工作原理：

HTTP協定工作于用戶端-服務端架構為上。浏覽器作為HTTP用戶端通過URL向HTTP服務端即WEB伺服器發送所有請求。

Web伺服器有：Apache伺服器，IIS伺服器（Internet Information Services）等。

Web伺服器根據接收到的請求後，向用戶端發送響應資訊。HTTP預設端口号為80，但是你也可以改為8080或者其他端口。

HTTP三點注意事項：

• HTTP是無連接配接：無連接配接的含義是限制每次連接配接隻處理一個請求。伺服器處理完客戶的請求，并收到客戶的應答後，即斷開連接配接。采用這種方式可以節省傳輸時間。
• HTTP是媒體獨立的：這意味着，隻要用戶端和伺服器知道如何處理的資料内容，任何類型的資料都可以通過HTTP發送。用戶端以及伺服器指定使用适合的MIME-type内容類型。
• HTTP是無狀态：HTTP協定是無狀态協定。無狀态是指協定對于事務處理沒有記憶能力。缺少狀态意味着如果後續處理需要前面的資訊，則它必須重傳，這樣可能導緻每次連接配接傳送的資料量增大。另一方面，在伺服器不需要先前資訊時它的應答就較快。

HTTP 消息結構：

HTTP是基于用戶端/服務端（C/S）的架構模型，通過一個可靠的連結來交換資訊，是一個無狀态的請求/響應協定。

一個HTTP"用戶端"是一個應用程式（Web浏覽器或其他任何用戶端），通過連接配接到伺服器達到向伺服器發送一個或多個HTTP的請求的目的。

一個HTTP"伺服器"同樣也是一個應用程式（通常是一個Web服務，如Apache Web伺服器或IIS伺服器等），通過接收用戶端的請求并向用戶端發送HTTP響應資料。

HTTP使用統一資源辨別符（Uniform Resource Identifiers, URI）來傳輸資料和建立連接配接。

一旦建立連接配接後，資料消息就通過類似Internet郵件所使用的格式[RFC5322]和多用途Internet郵件擴充（MIME）[RFC2045]來傳送。

請求消息的結構圖解：

用戶端發送一個HTTP請求到伺服器的請求消息包括以下格式：請求行（request line）、請求頭部（header）、空行和請求資料四個部分組成，下圖給出了請求封包的一般格式。

http請求頭詳解：（參考：

https://kb.cnblogs.com/page/92320/

請求頭	請求頭屬性
Cache-Control	指定請求應遵循的緩存機制，其中緩存指令：no-cache、no-store、max-age、 max-stale、min-fresh、only-if-cached。 no-cache：表示請求的消息不可以緩存 no-store：在請求消息中，表示請求和響應的消息均不可以緩存，為了防止重要的消息被無意間洩露 max-age：表示客戶機接收相應消息的最大時間（最大生存期） max-stale：表示客戶機可以接受逾時的消息，如果指定該值，表示可以接受逾時之後指定值之内的消息 min-fresh：表示客戶機可以接受目前時間加上指定值的時間之内的消息 only-if-cached：表示客戶機隻接受被緩存的内容
Date	表示消息發送的時間，時間的描述格式由rfc822定義。例如，Date:Mon,31Dec200104:25:57GMT。Date描述的時間表示世界标準時，換算成本地時間，需要知道使用者所在的時區。
Pragma	反正頁面被緩存，在http1.1版本中，與Cache-Control:no-cache，作用相同，在http1.0中沒有實作Cache-Control.Pragma隻有一個用法：Pragma:no-cache
Host	請求報頭域主要用于指定被請求資源的Internet主機和端口号，它通常從HTTP URL中提取出來的。如果不是預設的80端口，會指定端口。如果不指定host，會報400錯誤
Referer	為伺服器提供上下文資訊，告訴伺服器，我這個連結是從什麼地方轉過來的。
Range	隻請求實體的一部分，伺服器可以忽略此請求。 頭500個位元組：bytes=0-499。第二個500位元組：bytes=500-999。最後500個位元組：bytes=-500。500位元組以後的範圍：bytes=500-。第一個和最後一個位元組：bytes=0-0,-1。同時指定幾個範圍：bytes=500-600,601-999
User-Agent	表示包含發送請求的使用者資訊。如果是浏覽器發送的話，基本就是浏覽器的資訊
Accept	表示用戶端能夠接受的内容類型，例：text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 如果想知道更多的MIME類型，去這個網站： http://www.w3school.com.cn/media/media_mimeref.asp
Accept-Charset	表示浏覽器可以接受的字元編碼集。在國内最常用的就是utf8,gbk。想了解更多： https://zh.wikipedia.org/wiki/%E5%AD%97%E7%AC%A6%E7%BC%96%E7%A0%81
Accept-Encoding	指定浏覽器可以支援的web伺服器傳回内容壓縮編碼類型。常用的：compress, gzip
Accept-Language	指定浏覽器可以接受的語言。常用的 en,zh
Accept-Ranges	可以請求網頁實體的一個或者多個子範圍字段。例：Accept-Ranges: bytes
Authorization	http授權的授權證書
Connection	是否保持持久連接配接。close：表示不保持持久連接配接，keep-alive：保持持久連接配接。（HTTP 1.1預設進行持久連接配接）
Cookie	存儲的一些有關該客戶機的資訊，發送http請求時，會把該域名下的所有cookie，一起發送給伺服器。
Content-Length	表示請求内容的長度
Content-Type	請求實體的MIME類型。如果想知道更多的MIME類型，去這個網站：
Expect	請求的特定的伺服器類型，不是太明白，有懂得可以幫我解釋一下
From	送出請求的使用者的Email
If-Match	隻有請求内容與實體相比對才有效
If-Modified-Since	如果請求的部分在指定時間之後被修改則請求成功，未被修改則傳回304代碼
If-None-Match	如果内容未改變傳回304代碼，參數為伺服器先前發送的Etag，與伺服器回應的Etag比較判斷是否改變
If-Range	如果實體未改變，伺服器發送用戶端丢失的部分，否則發送整個實體。參數也為Etag
If-Unmodified-Since	隻在實體在指定時間之後未被修改才請求成功
Max-Forwards	限制資訊通過代理和網關傳送的時間
Proxy-Authorization	連接配接到代理的授權證書
TE	用戶端願意接受的傳輸編碼，并通知伺服器接受接受尾加頭資訊
Upgrade	向伺服器指定某種傳輸協定以便伺服器進行轉換（如果支援）
Via	通知中間網關或代理伺服器位址，通信協定
Warning	關于消息實體的警告資訊

http回應頭詳解：

Cache- Control
Date	原始伺服器消息發出的時間，時間的描述格式由rfc822定義。例如，Date:Mon,31Dec200104:25:57GMT。Date描述的時間表示世界标準時，換算成本地時間，需要知道使用者所在的時區。
Expires	響應過期的日期和時間
Pragma	不允許頁面被緩存，在http1.1版本中，與Cache-Control:no-cache，作用相同，在http1.0中沒有實作Cache-Control.Pragma隻有一個用法：Pragma:no-cache
User-Agent
Age	從原始伺服器到代理緩存形成的估算時間（以秒計，非負）
Allow	對某網絡資源的有效的請求行為，不允許則傳回405,請求行為：Get,Post,Head等，下面會重點介紹
Content-Encoding	web伺服器支援的傳回内容壓縮編碼類型
Content-Language	響應體的語言
Content-Location	請求資源可替代的備用的另一位址
Content-MD5	傳回資源的MD5校驗值
Content-Range	在整個傳回體中本部分的位元組位置
	響應體内容的長度
	傳回内容的MIME類型。如果想知道更多的MIME類型，去這個網站：
ETag	請求變量的實體标簽的目前值
Last-Modified	請求資源的最後修改時間
Location	用來重定向接收方到非請求URL的位置來完成請求或辨別新的資源
Proxy-Authenticate	它指出認證方案和可應用到代理的該URL上的參數
refresh	應用于重定向或一個新的資源被創造，在5秒之後重定向（由網景提出，被大部分浏覽器支援）
Retry-After	如果實體暫時不可取，通知用戶端在指定時間之後再次嘗試
Server	web伺服器軟體名稱
Set-Cookie	設定Http Cookie
Trailer	指出頭域在分塊傳輸編碼的尾部存在
Transfer-Encoding	檔案傳輸編碼
Vary	告訴下遊代理是使用緩存響應還是從原始伺服器請求
WWW-Authenticate	表明用戶端請求實體應該使用的授權方案

關于請求頭與回應頭，更多的可以通路W3C官網：

https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html

http請求方法：

（轉自：

http://www.runoob.com/http/http-methods.html

HTTP1.0定義了三種請求方法： GET, POST 和 HEAD方法。

HTTP1.1新增了五種請求方法：OPTIONS, PUT, DELETE, TRACE 和 CONNECT 方法。

請求方法	描述
GET	請求指定的頁面資訊，并傳回實體主體。
HEAD	類似于get請求，隻不過傳回的響應中沒有具體的内容，用于擷取報頭
POST	向指定資源送出資料進行處理請求（例如送出表單或者上傳檔案）。資料被包含在請求體中。POST請求可能會導緻新的資源的建立和/或已有資源的修改。
PUT	從用戶端向伺服器傳送的資料取代指定的文檔的内容。
DELETE	請求伺服器删除指定的頁面。
CONNECT	HTTP/1.1協定中預留給能夠将連接配接改為管道方式的代理伺服器。
OPTIONS	允許用戶端檢視伺服器的性能。
TRACE	回顯伺服器收到的請求，主要用于測試或診斷。

http狀态碼：

（轉自：http://www.runoob.com/http/http-status-codes.html）

分類	分類描述
1**	資訊，伺服器收到請求，需要請求者繼續執行操作
2**	成功，操作被成功接收并處理
3**	重定向，需要進一步的操作以完成請求
4**	用戶端錯誤，請求包含文法錯誤或無法完成請求
5**	伺服器錯誤，伺服器在處理請求的過程中發生了錯誤