Python學習之路 （四）爬蟲（三）HTTP和HTTPS

標籤：發布   set   序號   處理   使用   傳輸層   簡體   排序   nic   

HTTP和HTTPS

HTTP協議（HyperText Transfer Protocol，超文字傳輸通訊協定 (HTTP)）：是一種發布和接收 HTML頁面的方法。

HTTPS（Hypertext Transfer Protocol over Secure Socket Layer）簡單講是HTTP的安全版，在HTTP下加入SSL層。

SSL（Secure Sockets Layer 安全套接層）主要用於Web的安全傳輸協議，在傳輸層對網路連接進行加密，保障在Internet上資料轉送的安全。

• HTTP的連接埠號碼為80，
• HTTPS的連接埠號碼為443

HTTP工作原理

網路爬蟲抓取過程可以理解為類比瀏覽器操作的過程。

瀏覽器的主要功能是向伺服器發出請求，在瀏覽器視窗中展示您選擇的網路資源，HTTP是一套電腦通過網路進行通訊的規則。

HTTP的請求與響應

HTTP通訊由兩部分組成： 用戶端請求訊息 與 伺服器響應訊息

瀏覽器發送HTTP請求的過程：

1. 當使用者在瀏覽器的地址欄中輸入一個URL並按斷行符號鍵之後，瀏覽器會向HTTP伺服器發送HTTP請求。HTTP請求主要分為“Get”和“Post”兩種方法。

2. 當我們在瀏覽器輸入URL http://www.baidu.com 的時候，瀏覽器發送一個Request請求去擷取 http://www.baidu.com 的html檔案，伺服器把Response檔案對象發送回給瀏覽器。

3. 瀏覽器分析Response中的 HTML，發現其中引用了很多其他檔案，比如Images檔案，CSS檔案，JS檔案。 瀏覽器會自動再次發送Request去擷取圖片，CSS檔案，或者JS檔案。

4. 當所有的檔案都下載成功後，網頁會根據HTML文法結構，完整的顯示出來了。

URL（Uniform / Universal Resource Locator的縮寫）：統一資源定位器，是用於完整地描述Internet上網頁和其他資源的地址的一種標識方法。

 

基本格式：

scheme://host[:port#]/path/…/[?query-string][#anchor]

• scheme：協議(例如：http, https, ftp)
• host：伺服器的IP地址或者網域名稱
• port#：伺服器的連接埠（如果是走協議預設連接埠，預設連接埠80）
• path：訪問資源的路徑
• query-string：參數，發送給http伺服器的資料
• anchor：錨（跳轉到網頁的指定錨點位置）

例如：

• ftp://192.168.0.116:8080/index

• http://www.baidu.com

• http://item.jd.com/11936238.html#product-detail

用戶端HTTP請求

URL只是標識資源的位置，而HTTP是用來提交和擷取資源。用戶端發送一個HTTP請求到伺服器的請求訊息，包括以下格式：

請求行、要求標頭部、空行、請求資料

四個部分組成，給出了請求報文的一般格式。

 

一個典型的HTTP請求樣本

GET https://www.baidu.com/ HTTP/1.1Host: www.baidu.comConnection: keep-aliveUpgrade-Insecure-Requests: 1User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.99 Safari/537.36Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8Referer: http://www.baidu.com/Accept-Encoding: gzip, deflate, sdch, brAccept-Language: zh-CN,zh;q=0.8,en;q=0.6Cookie: BAIDUID=04E4001F34EA74AD4601512DD3C41A7B:FG=1; BIDUPSID=04E4001F34EA74AD4601512DD3C41A7B; PSTM=1470329258; MCITY=-343%3A340%3A; BDUSS=nF0MVFiMTVLcUh-Q2MxQ0M3STZGQUZ4N2hBa1FFRkIzUDI3QlBCZjg5cFdOd1pZQVFBQUFBJCQAAAAAAAAAAAEAAADpLvgG0KGyvLrcyfrG-AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFaq3ldWqt5XN; H_PS_PSSID=1447_18240_21105_21386_21454_21409_21554; BD_UPN=12314753; sug=3; sugstore=0; ORIGIN=0; bdime=0; H_PS_645EC=7e2ad3QHl181NSPbFbd7PRUCE1LlufzxrcFmwYin0E6b%2BW8bbTMKHZbDP0g; BDSVRTM=0

要求方法

GET https://www.baidu.com/ HTTP/1.1

根據HTTP標準，HTTP請求可以使用多種要求方法。

HTTP 0.9：只有基本的文本 GET 功能。

HTTP 1.0：完善的請求/響應模型，並將協議補充完整，定義了三種要求方法： GET, POST 和 HEAD方法。

HTTP 1.1：在 1.0 基礎上進行更新，新增了五種要求方法：OPTIONS, PUT, DELETE, TRACE 和 CONNECT 方法。

HTTP 2.0（未普及）：請求/響應首部的定義基本沒有改變，只是所有首部鍵必須全部小寫，而且請求行要獨立為 :method、:scheme、:host、:path這些索引值對。

 

序號	方法	描述
1	GET	請求指定的頁面資訊，並返回實體主體。
2	HEAD	類似於get請求，只不過返回的響應中沒有具體的內容，用於擷取前序
3	POST	向指定資源提交資料進行處理請求（例如提交表單或者上傳檔案），資料被包含在請求體中。POST請求可能會導致新的資源的建立和/或已有資源的修改。
4	PUT	從用戶端向伺服器傳送的資料取代指定的文檔的內容。
5	DELETE	請求伺服器刪除指定的頁面。
6	CONNECT	HTTP/1.1協議中預留給能夠將串連改為管道方式的Proxy 伺服器。
7	OPTIONS	允許用戶端查看伺服器的效能。
8	TRACE	回顯伺服器收到的請求，主要用於測試或診斷。

 

HTTP請求主要分為 Get和 Post兩種方法

• GET是從伺服器上擷取資料，POST是向伺服器傳送資料

• GET請求參數顯示，都顯示在瀏覽器網址上，HTTP伺服器根據該請求所包含URL中的參數來產生響應內容，即“Get”請求的參數是URL的一部分。 例如： http://www.baidu.com/s?wd=Chinese

• POST請求參數在請求體當中，訊息長度沒有限制而且以隱式的方式進行發送，通常用來向HTTP伺服器提交量比較大的資料（比如請求中包含許多參數或者檔案上傳操作等），請求的參數包含在“Content-Type”訊息頭裡，指明該訊息體的媒體類型和編碼，

注意：避免使用Get方式提交表單，因為有可能會導致安全問題。 比如說在登陸表單中用Get方式，使用者輸入的使用者名稱和密碼將在地址欄中暴露無遺。

常用的請求前序1. Host (主機和連接埠號碼)

Host：對應網址URL中的Web名稱和連接埠號碼，用於指定被請求資源的Internet主機和連接埠號碼，通常屬於URL的一部分。

2. Connection (連結類型)

Connection：表示用戶端與服務連線類型

1. Client 發起一個包含 Connection:keep-alive 的請求，HTTP/1.1使用 keep-alive 為預設值。

2. Server收到請求後：

   • 如果 Server 支援 keep-alive，回複一個包含 Connection:keep-alive 的響應，不關閉串連；
   • 如果 Server 不支援 keep-alive，回複一個包含 Connection:close 的響應，關閉串連。

3. 如果client收到包含 Connection:keep-alive 的響應，向同一個串連發送下一個請求，直到一方主動關閉串連。

keep-alive在很多情況下能夠重用串連，減少資源消耗，縮短回應時間，比如當瀏覽器需要多個檔案時(比如一個HTML檔案和相關的圖形檔案)，不需要每次都去請求建立串連。

3. Upgrade-Insecure-Requests (升級為HTTPS請求)

Upgrade-Insecure-Requests：升級不安全的請求，意思是會在載入 http 資源時自動替換成 https 請求，讓瀏覽器不再顯示https頁面中的http請求警報。

HTTPS 是以安全為目標的 HTTP 通道，所以在 HTTPS 承載的頁面上不允許出現 HTTP 要求，一旦出現就是提示或報錯。

4. User-Agent (瀏覽器名稱)

User-Agent：是客戶瀏覽器的名稱，以後會詳細講。

5. Accept (傳輸檔案類型)

Accept：指瀏覽器或其他用戶端可以接受的MIME（Multipurpose Internet Mail Extensions（多用途互連網郵件擴充））檔案類型，伺服器可以根據它判斷並返回適當的檔案格式。

舉例：

Accept: */*：表示什麼都可以接收。

Accept：image/gif：表明用戶端希望接受GIF映像格式的資源；

Accept：text/html：表明用戶端希望接受html文本。

Accept: text/html, application/xhtml+xml;q=0.9, image/*;q=0.8：表示瀏覽器支援的 MIME 類型分別是 html文本、xhtml和xml文檔、所有的映像格式資源。

q是權重係數，範圍 0 =< q <= 1，q 值越大，請求越傾向於獲得其“;”之前的類型表示的內容。若沒有指定q值，則預設為1，按從左至右排序次序；若被賦值為0，則用於表示瀏覽器不接受此內容類型。

Text：用於標準化地表示的文本資訊，簡訊可以是多種字元集和或者多種格式的；Application：用於傳輸應用程式資料或者位元據。詳細請點擊

6. Referer (頁面跳轉處)

Referer：表明產生請求的網頁來自於哪個URL，使用者是從該 Referer頁面訪問到當前請求的頁面。這個屬性可以用來跟蹤Web請求來自哪個頁面，是從什麼網站來的等。

有時候遇到下載某網站圖片，需要對應的referer，否則無法下載圖片，那是因為人家做了防盜鏈，原理就是根據referer去判斷是否是本網站的地址，如果不是，則拒絕，如果是，就可以下載；

7. Accept-Encoding（檔案編解碼格式）

Accept-Encoding：指出瀏覽器可以接受的編碼方式。編碼方式不同於檔案格式，它是為了壓縮檔並加速檔案傳遞速度。瀏覽器在接收到Web響應之後先解碼，然後再檢查檔案格式，許多情形下這可以減少大量的下載時間。

舉例：Accept-Encoding:gzip;q=1.0, identity; q=0.5, *;q=0

如果有多個Encoding同時匹配, 按照q值順序排列，本例中按順序支援 gzip, identity壓縮編碼，支援gzip的瀏覽器會返回經過gzip編碼的HTML頁面。 如果請求訊息中沒有設定這個網域服務器假定用戶端對各種內容編碼都可以接受。

8. Accept-Language（語言種類）

Accept-Langeuage：指出瀏覽器可以接受的語言種類，如en或en-us指英語，zh或者zh-cn指中文，當伺服器能夠提供一種以上的語言版本時要用到。

9. Accept-Charset（字元編碼）

Accept-Charset：指出瀏覽器可以接受的字元編碼。

舉例：Accept-Charset:iso-8859-1,gb2312,utf-8

• ISO8859-1：通常叫做Latin-1。Latin-1包括了書寫所有西方歐洲語言不可缺少的附加字元，英文瀏覽器的預設值是ISO-8859-1.
• gb2312：標準簡體中文字元集;
• utf-8：UNICODE 的一種變長字元編碼，可以解決多種語言文本顯示問題，從而實現應用國際化和本地化。

如果在請求訊息中沒有設定這個域，預設是任何字元集都可以接受。

10. Cookie （Cookie）

Cookie：瀏覽器用這個屬性向伺服器發送Cookie。Cookie是在瀏覽器中寄存的小型資料體，它可以記載和伺服器相關的使用者資訊，也可以用來實現會話功能，以後會詳細講。

11. Content-Type (POST資料類型)

Content-Type：POST請求裡用來表示的內容類型。

舉例：Content-Type = Text/XML; charset=gb2312：

指明該請求的訊息體中包含的是純文字的XML類型的資料，字元編碼採用“gb2312”。

服務端HTTP響應

HTTP響應也由四個部分組成，分別是： 狀態行、訊息前序、空行、響應本文

 

HTTP/1.1 200 OKServer: TengineConnection: keep-aliveDate: Wed, 30 Nov 2016 07:58:21 GMTCache-Control: no-cacheContent-Type: text/html;charset=UTF-8Keep-Alive: timeout=20Vary: Accept-EncodingPragma: no-cacheX-NWS-LOG-UUID: bd27210a-24e5-4740-8f6c-25dbafa9c395Content-Length: 180945<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" ....

常用的響應前序(瞭解)

理論上所有的回應標頭資訊都應該是回應要求標頭的。但是服務端為了效率，安全，還有其他方面的考慮，會添加相對應的回應標頭資訊，從可以看到：

1. Cache-Control：must-revalidate, no-cache, private。

這個值告訴用戶端，服務端不希望用戶端緩衝資源，在下次請求資源時，必須要從新請求伺服器，不能從快取複本中擷取資源。

• Cache-Control是回應標頭中很重要的資訊，當用戶端要求標頭中包含Cache-Control:max-age=0請求，明確表示不會快取服務器資源時,Cache-Control作為作為回應資訊，通常會返回no-cache，意思就是說，"那就不緩衝唄"。

• 當用戶端在要求標頭中沒有包含Cache-Control時，服務端往往會定,不同的資源不同的緩衝策略，比如說oschina在緩衝圖片資源的策略就是Cache-Control：max-age=86400,這個意思是，從目前時間開始，在86400秒的時間內，用戶端可以直接從快取複本中讀取資源，而不需要向伺服器請求。

2. Connection：keep-alive

這個欄位作為回應用戶端的Connection：keep-alive，告訴用戶端伺服器的tcp串連也是一個長串連，用戶端可以繼續使用這個tcp串連發送http請求。

3. Content-Encoding:gzip

告訴用戶端，服務端發送的資源是採用gzip編碼的，用戶端看到這個資訊後，應該採用gzip對資源進行解碼。

4. Content-Type：text/html;charset=UTF-8

告訴用戶端，資源檔的類型，還有字元編碼，用戶端通過utf-8對資源進行解碼，然後對資源進行html解析。通常我們會看到有些網站是亂碼的，往往就是伺服器端沒有返回正確的編碼。

5. Date：Sun, 21 Sep 2016 06:18:21 GMT

這個是服務端發送資源時的伺服器時間，GMT是格林尼治所在地的標準時間。http協議中發送的時間都是GMT的，這主要是解決在互連網上，不同時區在相互請求資源的時候，時間混亂問題。

6. Expires:Sun, 1 Jan 2000 01:00:00 GMT

這個回應標頭也是跟緩衝有關的，告訴用戶端在這個時間前，可以直接存取快取複本，很顯然這個值會存在問題，因為用戶端和伺服器的時間不一定會都是相同的，如果時間不同就會導致問題。所以這個回應標頭是沒有Cache-Control：max-age=*這個回應標頭準確的，因為max-age=date中的date是個相對時間，不僅更好理解，也更準確。

7. Pragma:no-cache

這個含義與Cache-Control等同。

8.Server：Tengine/1.4.6

這個是伺服器和相對應的版本，只是告訴用戶端伺服器的資訊。

9. Transfer-Encoding：chunked

這個回應標頭告訴用戶端，伺服器發送的資源的方式是分塊發送的。一般分塊發送的資源都是伺服器動態產生的，在發送時還不知道發送資源的大小，所以採用分塊發送，每一塊都是獨立的，獨立的塊都能標示自己的長度，最後一塊是0長度的，當用戶端讀到這個0長度的塊時，就可以確定資源已經傳輸完了。

10. Vary: Accept-Encoding

告訴快取服務器，緩衝壓縮檔和非壓縮檔兩個版本，現在這個欄位用處並不大，因為現在的瀏覽器都是支援壓縮的。

響應狀態代碼

響應狀態碼有三位元字組成，第一個數字定義了響應的類別，且有五種可能取值。

常見狀態代碼：

• 100~199：表示伺服器成功接收部分請求，要求用戶端繼續提交其餘請求才能完成整個處理過程。

• 200~299：表示伺服器成功接收請求並已完成整個處理過程。常用200（OK 請求成功）。

• 300~399：為完成請求，客戶需進一步細化請求。例如：請求的資源已經移動一個新地址、常用302（所請求的頁面已經臨時轉移至新的url）、307和304（使用緩衝資源）。
• 400~499：用戶端的請求有錯誤，常用404（伺服器無法找到被請求的頁面）、403（伺服器拒絕訪問，許可權不夠）。
• 500~599：伺服器端出現錯誤，常用500（請求未完成。伺服器遇到不可預知的情況）。

Cookie 和 Session：

伺服器和用戶端的互動僅限於請求/響應過程，結束之後便斷開，在下一次請求時，伺服器會認為新的用戶端。

為了維護他們之間的連結，讓伺服器知道這是前一個使用者發送的請求，必須在一個地方儲存用戶端的資訊。

Cookie：通過在 用戶端 記錄的資訊確定使用者的身份。

Session：通過在 伺服器端 記錄的資訊確定使用者的身份。

 

Python學習之路 （四）爬蟲（三）HTTP和HTTPS