python爬蟲登陸保持及對http總結

【前言】這幾天一直看python爬蟲登陸保持。實現接口太多,太亂,新手不免雲山霧罩。各類get、post,深刻理解一下,其實就是因爲http的特性須要這些操做。http是一種無狀態、不保存上次通訊結果的一種網絡傳輸協議,雖然基於tcp可是不是鏈接的。html

  本文先從原理角度介紹http各類特性,而後基於python語言,介紹其比較出名的一個http庫——requests。主要會參考其中文的【開發文檔】來總結,翻譯的仍是不錯的。下面這幅圖片是我截的文檔開頭,我一直認爲真正的高手應該對其知識信手拈來,能夠以一種風趣幽默的形式展示出來。哈哈,扯遠了。python

參考:《圖解http》和https://blog.csdn.net/u011054333/article/details/69486364web

1、http基礎知識瀏覽器

  web使用http(超文本傳輸協議)來實現客戶端與服務器通訊。htttp屬於tcp/ip協議族(四層),位於應用層。一、應用層協議是各類進程間通訊的規則;二、傳輸層主要就是tcp和udp;三、網絡層ipv4/6,用來對網絡上的數據包進行封裝,數據包是網絡傳輸的最小數據單位,該層規定使用怎樣的路徑將數據包傳給對方。要準確的到達目的地址,IP協議有兩個量:ip和mac,解決局域網問題。ip經過ARP協議能夠反查mac四、鏈路層,網絡的硬件部分,網卡的驅動協議等。注意封裝是逐級的,打包和解包的過程。緩存

2、請求和響應報文安全

 請求: headers={}    由三部分組成服務器

一、請求方法:get()、post()至少掌握,其餘put(......之後再說。eg:GET/sample.jspHTTP/1.1(方法/URi/版本協議)大神講解:http://www.cnblogs.com/hyddd/archive/2009/03/31/1426026.htmlcookie

  簡單說,get是明文請求url信息,由於全部的響應返回信息都會跟在url中的?後面,用&鏈接參數,相對不安全,並且響應不會對當前瀏覽器產生影響;post的是攜帶信息請求,會把信息都封裝在報文裏面,相對安全,收到響應後瀏覽器界面也隨即改變了。網絡

二、請求頭:connection默認設置爲keep-alive這樣在一次TCP鏈接時能夠屢次發送接收數據,提升吞吐,即持久鏈接,下面有介紹。session

  還有其餘那幾個通常默認,惟一必須傳的就是user-agent:瀏覽器的版本。

  ...(還有好多)

三、請求正文:密碼,用戶名能夠寫在headers裏面,python是攜帶在data={}裏面提交。同樣的,其實就是覆蓋。

    響應:HTTP響應也由3個部分構成

一、狀態行:狀態行由協議版本、數字形式的狀態代碼、及相應的狀態描述,各元素之間以空格分隔。eg :HTTP/1.1 200 OK

其中:200爲狀態代碼。第一個數字有五種可能的取值:

  - 1xx:   指示信息—表示請求已接收,繼續處理。

  - 2xx:   成功—表示請求已經被成功接收、理解、接受。

  - 3xx:   重定向—要完成請求必須進行更進一步的操做。

  - 4xx:   客戶端錯誤—請求有語法錯誤或請求沒法實現。

  - 5xx: 服務器端錯誤—服務器未能實現合法的請求

二、響應頭: 

服務器端軟件xinxi:Server:Apache Tomcat/5.0.12

時間:Date:Mon,6Oct2003 13:23:42 GMT

正文長度:Content-Length:112

3、幾種數據傳輸方式

一、無狀態

  http協議是一種自身不對請求和響應之間的通訊狀態進行保存的協議,即無狀態協議。這種設置的好處是:更快的處理更多的請求事務,j減輕服務器負擔,確保協議的可伸縮性(快速型?)。不過隨着web的不斷髮展,有時候須要將這種狀態進行保持,例如保持登陸。隨即,就引入了cookie技術,cookie技術經過在請求和響應報文中寫入cookie信息來控制客戶端的狀態。

二、持久性

  最第一版本的http確實是鏈接一次收到一條數據就斷開,而後周而復始的tcp三次握手,四次揮手。如今html裏面會包含其餘請求文件,這樣頻繁斷開消耗太大,提出持久化技術:keep-alive.一次鏈接屢次收發數據的次數,默認開啓,次數在服務器端設置,通常300。

三、線管化

  在鏈接中,一次請求發出不用等待收到響應,就能夠發出其餘的請求。

四、內容編碼

  因爲某些報文的內容過大,所以在傳輸時,爲了減小傳輸的時間,會採起一些壓縮的措施。例如上面的報文信息中,Accept-Encoding就定義了內容編碼的格式:gzip(GUN壓縮格式)

五、cookie  

  Cookie 會根據從服務器端發送的響應報文內的一個叫作 Set-Cookie 首部字段信息, 通知客戶端保存 Cookie。 當下次客戶端再往該服務器發送請求時, 客戶端會自動在請求報文中加入 Cookie 值後發送出去。 這樣服務器端只須要保存剛剛向誰發送了這個cookie,一對比就知道是誰了。必定程度解決了登陸保持是不會給服務器帶來太大負擔,並且服務器留存cookie的記錄有個有效時長,必定時間收不到客戶端的cookie就會清除記錄。

  區分一下攜帶cookie和保持session.

六、數據轉發:代理、網管、隧道  

  HTTP 通訊時, 除客戶端和服務器之外, 還有一些用於通訊數據轉發的應用程序, 例如代理、 網關和隧道。 它們能夠配合服務器工做。 這些應用程序和服務器能夠將請求轉發給通訊線路上的下一站服務器, 而且能接收從那臺服務器發送的響應再轉發給客戶端。 

  6.1代理    

  代理服務器的基本行爲就是接收客戶端發送的請求後轉發給其餘服務器。 代理不改變請求 URI, 會直接發送給前方持有資源的目標服務器。持有資源實體的服務器被稱爲源服務器。 從源服務器返回的響應通過代理服務器後再傳給客戶端。 緩存代理:代理轉發響應時, 緩存代理(Caching Proxy) 會預先將資源的副本(緩存) 保存在代理服務器上。 當代理再次接收到對相同資源的請求時, 就能夠不從源服務器那裏獲取資源, 而是將以前緩存的資源做爲響應返回。 透明代理:不對收到的報文信息作任何修改。

  不只有服務器緩存,還有客戶端緩存。識別驗證碼的時候帶上時間戳就是避免瀏覽器緩存的一種機制。

  六、2網關

  網關的做用和位置和代理差很少,不一樣的是,網關能夠對http報文分析,而後和其餘的服務器進行非http通訊,例如能夠和安全系統聯動,分析數據安全性,也能夠進行報文加密。

  六、3隧道

  一種長距離加密傳輸方式,透明存在。

4、http協議頭的詳解

相關文章
相關標籤/搜索