1.爬蟲基礎

時間 2019-12-13

標籤爬蟲基礎欄目網絡爬蟲简体版

原文原文鏈接

最近讀到崔慶才大神的Python3網絡爬蟲開發實戰,本文基本上是書中的內容,有小的改動,僅供參考,若有侵權請聯繫刪除。javascript

爬蟲基礎

1.HTTP基本原理

1.URI和URLcss

URL的全稱是Uniform Resource Locator,即統一資源定位符,又叫作網頁地址,是互聯網上標準的資源的地址。html

URL的組成結構:協議,服務器名稱,路徑,文件名前端

URI的全稱是Uniform Resource Identifier,即統一資源標誌符,Web上可用的每種資源,好比HTML文檔,圖像,視頻,音頻等,有URL進行定位。java

eg:https://github.com/favicon.ico是Github網站圖標的連接,他是一個URL,他也是一個URI,就是說有這樣一個圖標資源,咱們能夠用URL/URI來惟一指定他的訪問方式,即咱們能夠經過這個連接來訪問這個資源,這就是URL/URI。python

URL是URI的子集,每個URL都是URI,但不是每一個URI都是URL。那麼,什麼樣的URI不是URL呢?URI還有一個子類是URN,他的全稱是Universal Resource Name,即統一資源名稱,URN只命名資源而不定位資源,好比:urn:isbn:123456,指定一本書的ISBN,能夠惟一表示這本書,可是並未有定位這個書,咱們不知道去哪裏找到這本書,這就是URN。git

URN,URL,URI的關係以下所示github

在如今的互聯網中,URN用的很是少,並且幾乎全部的URI都是URL,因此通常網頁連接咱們皆能夠稱爲URL,也能夠稱爲URI,習慣上稱爲URL。正則表達式

2.超文本

超文本,hypertext,就是頁面能夠包含圖片,連接甚至音樂,程序等非文本元素。HTML是超文本標記語言,咱們能夠用HTML來寫超文本文檔,咱們在瀏覽器中看到的網頁就是超文本解析而成的,網頁的源代碼爲HTML代碼。數據庫

咱們在一個網頁右擊檢查或者F12,能夠看到前端的開發工具,而後再Elements中能夠看到網頁的源代碼,這些都是超文本。

3.HTTP和HTTPS

淘寶網的首頁https://www.taobao.com/,URL的開頭爲https,這是訪問資源須要遵循的協議,有時咱們還能看到ftp,sftp,smb開頭的URL,他們都是協議類型。在之後的爬蟲中,咱們爬取的頁面一般是http或https協議的,因此咱們來了解一下這兩個協議的含義。

HTTP的全稱是HyperText Transfer Protocol,即超文本傳輸協議,HTTP協議是用於網絡傳輸超文本數據到本地服務器的傳送協議,它能保證高效並且準確的傳送超文本文檔。

HTTPS的全稱是HyperText Transfer Protocol over Secure Socket Layer,是以安全爲目標的HTTP通道,通俗的說就是HTTP的安全版,在HTTP下加入SSL層,簡稱爲HTTPS

HTTPS的安全基礎是SSL,它傳輸的內容都是通過SSL加密的,HTTPS的主要做用分爲兩種:

1.創建一個信息安全通道,保證數據傳輸的安全

2.確認網站的真實性，凡是使用了 https 的網站，均可以經過點擊瀏覽器地址欄的鎖頭標誌來查看網站認證以後的真實信息，也能夠經過 CA 機構頒發的安全簽章來查詢。

如今大部分的網站都是用HTTPS協議

4.HTTP請求過程

咱們在瀏覽器中輸入一個URL,回車以後便會在瀏覽器中觀察到網頁內容。實際上這個過程是瀏覽器向網站所在的服務器發送了一個請求,網站服務器接受到這個請求後進行處理和解析,並返回對應的響應,返回給瀏覽器。響應中包含了頁面的源代碼等內容,瀏覽器對響應進行解析將網頁呈現出來,對應的模型以下:

客戶端表明咱們的PC或手機端的瀏覽器,服務器表明要訪問的網站的服務器

爲了更加直觀的說明這個過程,咱們用Chrome瀏覽器中的開發者模式下的工具NetWork監聽組件來演示,他能夠顯示當前請求網頁時發生的全部的網絡請求和響應。

咱們打開Chrome瀏覽器,右擊檢查或F12打開開發者工具,而後點擊Network而後在頂部的地址欄上輸入https://www.baidu.com/ 後回車,咱們能夠看到Network下方出現了一個個的條目,其中一個條目就表明發送請求和接受響應的過程,以下圖所示

咱們先來觀察第一個網絡請求,即http://www.javashuo.com/tag/www.baidu.com

其中各列的含義以下:

第一列 Name:請求的名稱。通常將URL的最後一部份內容當作名稱

第二列 Status:響應的狀態碼。這裏顯示爲200,表明響應是正常的。經過狀態碼,咱們能夠判斷髮送響應後是否獲得了正常的響應

第三列 Type:請求的文件類型。這裏是document,表明咱們此次請求的是一個HTML文檔,內容就是一些HTML 代碼

第四列 Initiator:請求源。用來標記請求是由哪一個對象或者進程發起的。

第五列 Size:從服務器下載的文件和請求的資源的大小。若是是從緩存中獲取的資源,則該列會顯示from cache

第六列 Time:發起請求到獲取響應的時間。

第七列 Waterfall:網絡請求的可視化瀑布流,

點擊條目能夠看到更加詳細的信息,以下圖:

首先是General部分:

Request URL:請求的URL;

Request Method:請求的方法;

Status Code:響應狀態碼;

Remote Address:遠程服務器的地址的端口

Referrer Policy:Referrer判別策略

繼續往下看,能夠看到有Response Headers和Request Headers,這倆分別表明響應頭和請求頭。

請求頭裏帶有不少的請求信息,例如瀏覽器標識,Cookies,Host等信息,這是請求的一部分,服務器會根據請求頭內的信息判斷請求是否合法,進而作出響應。

響應頭中的內容是響應的一部分,其中包含了服務器的類型,文旦類型,日期等信息,瀏覽器接收到響應後,會解析響應的內容,進而呈現網頁的內容。

5.請求

請求,由客戶端向服務端發出,能夠分爲4部份內容:請求方法(Request Method)、請求的網址(Request URL)、

請求頭(Request Headers)、請求體(Request Body)

1.請求方法

常見的請求方法有兩種:GET和POST

在瀏覽器的地址欄中直接輸入URL並回車,這便發起了一個GET請求,請求的參數會直接包含到URL裏。例如,在百度中搜索Python,這既是一個GET請求,連接爲https://www.baidu.com/s?wd=Python ,其中URL中包含了請求的參數信息,參數wd表示要搜尋的關鍵字。POST請求大多在表單提交時發起。好比一個登陸表單,輸入用戶名和密碼後,點擊登陸按鈕,這一般會發起一個POST請求,其數據以表單的形式傳輸,不會體如今URL中。

GET和POST請求方法的區別:

1.GET請求的參數包含在URL中,數據能夠再URL中看到,而POST請求的URL不會包含這些數據,數據都是通

過表單形式傳輸的,會包含在請求體中。

2.GET請求提交的數據最多有1024字節,而POST方式沒有限制

通常來講,登陸時,須要提交用戶名和密碼,其中包含了敏感信息,使用GET方式請求的話,密碼就會暴露在URL中, 從而形成密碼泄露,因此這裏最好以POST請求發送。上傳文件時,因爲文件內容比較大,也會選用POST方式。

咱們大部分遇到的請求方式爲GET和POST,還有另外的一些請求方法:

2.請求網址

即URL,它能夠惟一肯定咱們想請求的資源

3.請求頭

請求頭,用來講明服務器要使用的附加信息,比較重要的信息有:Cookies、Referer、User-Agent等,下面簡要說說明一下經常使用的頭信息:

Accept:請求報頭域,用於指定客戶端可接受哪些類型的信息

Accept-Language:指定客戶端可接受的語言類型。

Accept-Encoding:指定客戶端可接受的內容編碼

Host:用於指定請求資源的主機IP和端口號,其內容爲請求URL的原始服務器或網管的位置。

Cookies:網站爲了辨別用戶進行會話跟蹤而存儲在用戶本地的數據。他的主要功能是維持當前訪問會話。舉個例子:當咱們輸入用戶名和密碼成功登陸某個網站後,服務器會用會話保存登陸狀態信息,後面咱們刷新或者請求該站點的其餘頁面時,會發現都是登陸狀態,這就是Cookies的功勞。Cookies裏有信息標識了咱們所對應的服務器的會話,每次服務器請求該站點的頁面時,都會在請求頭上加上Cookies,並將其發送給服務器,服務器經過 Cookies來識別出是咱們本身,並查出當前狀態是登陸狀態,因此返回結果就是登陸後才能看到的網頁內容。

Referer:用來表示這個請求是從那個頁面發起的,服務器能夠拿到這個信息並作相應的處理,如:來源統計,防盜鏈處理

User-Agent:簡稱UA,它是一個特殊的字符串頭,可使服務器識別客戶使用的操做系統及版本、瀏覽器及版本等信息。在作爬蟲時加上此信息,能夠假裝爲瀏覽器;若是不加,極可能被識別爲爬蟲

Content-Type:互聯網媒體類型或者MIME類型,在HTTP協議消息頭中,用來具體表示請求頭中的媒體類型信息。

例如:text/html表明HTML格式,image/gif表明GIF圖片,application/json表明JSON類型等等,以下表所示:

https://www.runoob.com/http/http-content-type.html

所以,請求頭是請求的重要組成部分,在寫爬蟲時,大部分狀況下都須要設定請求頭

4.請求體

請求體通常承載的內容是POST請求中的表單數據,而對於GET請求,請求體爲空

eg:登陸Github是捕獲到的請求和響應:

登陸以前,咱們填寫了用戶名和密碼信息,提交時這些內容就會以表單數據的形式提交到服務器,此時須要注意的是Request Headers中指定Content-Type爲application/x-www-form-urlencoded。重點來了,只有設置Content-Type 爲application/x-www-form-urlencoded,纔會以表單數據的形式提交。此外,咱們也能夠將Content-Type設置爲application/json來提交json數據,或者設置爲multipart/form-data來上傳文件。

下表是Content-Type和POST提交數據方式的關係:

在爬蟲中,若是要構造POST請求,須要使用正確的Content-Type,並瞭解各類請求庫的各個參數設置時使用的是哪一種Content-Type,否則可能會致使POST提交後沒法正常響應

6.響應

響應,由服務端返回客戶端,能夠分爲三個部分:響應狀態碼(Response Status Code)、響應頭(Response Headers)和響應體(Response Body)。

1.響應狀態碼

響應狀態碼錶示服務器的響應狀態,如200表明服務器正常響應,404表明頁面沒找到,500表明服務器內部發生錯誤。

在爬蟲中,咱們能夠根據狀態碼來判斷服務器的響應狀態,如狀態碼爲200,則證實成功返回數據,再進行進一步的處理,不然直接忽略。

下面連接是常見的狀態碼:

https://www.runoob.com/http/http-status-codes.html

2.響應頭

響應頭包含了服務器對請求的應答信息,若Content-Type、Sever、Set-Cookie等,下邊簡要說明一些經常使用的頭信息:

Date:標識響應產生的時間

Last-Modified:指定資源的最後修改時間

Content-Encoding:指定響應內容的最後修改時間

Server:包含服務器的信息,好比名稱,版本號等

Content-Type:響應內容的數據類型,eg:text/html表明返回HTML文檔,application/x-javascript表明返回 JavaScript文件,image/jpeg表明返回圖片等。

Set-Cookie:設置Cookies。響應頭中的Set-Cookies告訴瀏覽器須要將此內容放在Cookies中,下次請求攜帶 Cookies請求。

Expires:指定響應的過時時間。可使代理服務器或者瀏覽器將加載的內容更新到緩存中。若是再次訪問,就能夠直接從緩存中加載,下降服務器負載,縮短加載時間。

3.響應體

響應體很重要,響應的正文數據都在響應體中,作爬蟲請求網頁後要解析的就是響應體中的內容

preview和response都是響應體內容,可是兩者有區別。通常狀況下兩者的內容相同,在Preview中控制檯會把json數據轉化爲JavaScript的對象格式,並且response不能顯示圖片等

Preview是預覽面板,用於資源的預覽,Response是響應信息面板,包含未進行格式處理的內容

在作爬蟲時,咱們主要經過響應體獲得的網頁源代碼,JSON數據等,而後從中作相應內容的提取。

本節中,咱們瞭解了HTTP基本原理,大概認識和了解了訪問頁面時背後的請求和響應過程,本節涉及的知識點須要好好掌握,後邊分析網頁請求時常常用到。

2.網頁基礎

網頁由html,css,javascript組成,html定義了網頁的結構,css更改了網頁的樣式,javascript封裝了網頁的動做

https://www.runoob.com/ 上邊的教程不錯,能夠看一下,這裏就不詳細說了

http://www.w3school.com.cn/tags/html_ref_byfunc.asp HTML參考手冊

http://css.doyoe.com/ CSS參考手冊

http://www.w3school.com.cn/jsref/index.asp JavaScript參考手冊

3.爬蟲基本原理

咱們能夠把互聯網比做一張大網,而爬蟲就是在這張網上爬行的蜘蛛。把網的每一個節點比做一個個網頁,爬蟲爬到這,就獲取了網站的信息。把節點之間的連線比做網頁與網頁之間的連接關係,爬蟲爬到一個節點後還能夠經過節點之間的連線爬到下一個節點,即經過一個網頁獲取後續網頁,這樣的話整個網的節點均可以被爬蟲所有爬行到,網頁的數據就能夠被抓取下來。

1.爬蟲概述

簡言之,爬蟲就是獲取網頁並提取和保存信息的自動化程序。

1.獲取網頁

爬蟲首先要作的工做就是獲取網頁,這裏指的是獲取網頁的源代碼。源代碼裏包含了網頁的部分有用信息,因此咱們只要把源代碼獲取下來,就能夠從中提取到想要獲取的信息了。

手工獲取大量的網頁源代碼不太現實,python爲咱們提供了許多庫來幫助咱們實現這個操做,如urllib、requests等。咱們能夠用這些庫來幫助咱們實現HTTP請求操做,請求和響應均可以用類庫提供的數據結構來表示,獲得響應後只需解析數據結構中Body部分便可,即獲得網頁的源代碼,這就是咱們用程序來實現獲取網頁的過程。

2.提取信息

獲取到網頁的源代碼後,接下來就是分析網頁的源代碼,從中提取到咱們想要的數據。

提取網頁信息有兩種方法:

1.使用正則表達式(萬能方法) 使用正則表達式比較複雜並且容易出錯。

2.藉助提取網頁信息的庫,如Beautiful Soup、pyquery、lxml等藉助這些庫,咱們能夠快速高效的提取網頁信息。

提取信息是爬蟲中很是重要的部分,它能夠是雜亂的數據變的條理清晰,以便咱們分析和處理數據。

3.保存數據

提取信息後,咱們通常會將提取到的數據保存到某處以便後續使用。保存數據的形式多種多樣,既能夠保存爲TXT文本和JSON文本,也能夠保存到數據庫,像MySQL和MongoDB等,也能夠保存至遠程服務器,如藉助SFTP進行操做等。

4.自動化程序

首先,提取信息咱們固然能夠手動完成,可是當量特別大或者想要快速抓取信息的時候,手動就比較尷尬,還得藉助程序。手速再快也沒程序操做的快對吧。因此爬蟲應運而生了,它就是抓取信息的自動化程序,它還能夠在抓取過程當中進行各類異常處理,錯誤重試等操做,確保爬取持續高效的進行。

2.能抓取怎樣的數據

首先最多見的就是常規網頁,它對應HTML代碼,最常抓取的就是HTML源代碼,另外有些頁面返回的是JSON字符串(API接口大多采用這種形式),一樣也可抓取。此外,咱們還能夠看到各類二進制數據,如圖片,視頻和音頻等,利用爬蟲咱們均可以抓取下來,保存爲對應的文件名。還有JavaScript文件,CSS文件及配置文件,瀏覽器能訪問到的咱們均可以抓取。

簡言之,基於HTTP和HTTPS的URL中的數據均可以抓取。

3.JavaScript渲染頁面

有時候咱們抓取網頁時,獲得的源代碼實際和瀏覽器中看到的不同,這是一個很常見的問題,如今的網頁極可能都是由Javascript渲染出來的,原來的HMTL代碼就是一個空殼,看下圖:

咱們能夠從圖中看到,body節點裏面只有一個id="container"的div標籤,可是下方script標籤引入了app.js文件,它便負責整個網站的渲染.在瀏覽器打開這個頁面的時候,首先會加載這個HTML內容,接着瀏覽器會發現其中引入了一個js文件,而後去請求這個文件,獲取到文件後,對文件中代碼進行執行,就會改變網頁的佈局,從而獲得整個完整的網頁

可是咱們在用urllib或requests等庫請求文件時,咱們獲得的只是這個HTML代碼,不會繼續去加載這個js文件,因此咱們也就看不到瀏覽器的內容了.這也解釋了爲何有時咱們獲得的源代碼和瀏覽器看到的不同.

問題總有解決方法,對於這種狀況,咱們能夠分析其後臺Ajax接口,也可使用Selenium、Splash這樣的庫來實現模擬JavaScript的渲染

4.會話和Cookies

咱們在瀏覽網站的過程當中,會常常遇到須要登陸的狀況,有些頁面只有登陸以後才能訪問,並且登陸以後能夠連續訪問不少網站,可是有時候過一段時間就須要從新登陸。還有一些網站,咱們打開以後自動登陸,並且很長時間都不會失效,這是什麼狀況呢?這裏面涉及會話(Session)和Cookies的相關知識,咱們來揭開它們的神祕面紗。

1.靜態網頁和動態網頁

這有一段代碼,這是最基本的HTML代碼,咱們將其保存爲一個.html文件,而後把它放在某臺具備固定公網IP的主機上,主機上裝上Apache或Nginx等服務器,這樣這臺主機就可做爲服務器了,其餘人即可以經過訪問服務器來看到這個頁面,這樣就搭建了一個簡單的網站.

這樣的網頁的內容用HTML寫好,文字、圖片等內容均經過寫好的HTML來指定,這種頁面叫作靜態頁面。它加載速度快,編寫簡單,可是也存在很大的缺陷,好比可維護性差,不能根據URL的靈活多變來顯示內容等。舉個很簡單的例子,咱們給這個URL傳遞一個name參數,這個網頁就顯示不出來了。

所以,動態網網頁就應運而生了,它能夠動態解析URL中參數的變化,關聯數據庫並動態呈現不一樣的網頁內容,很是靈活多變。咱們如今遇到的大多數網站都是動態網站,他們再也不是一個簡單的HTML,可能由JSP,PHP,Python等語言編寫的,功能比靜態網頁強大和豐富太多了。

此外,動態網站還能夠實現用戶登陸和註冊的功能。回到上邊提到的問題,不少頁面是須要登陸後才能查看的。按照通常的邏輯來講,輸入正確的用戶名和密碼後,確定是拿到了一種相似用憑證的東西,有了它,咱們才能保持登陸,狀態,才能訪問登陸以後看到的頁面。

那麼問題又雙叒叕來了,這神祕的憑證是什麼呢?其實它就是Cookies和會話共同做用的結果,下面咱們來一探究竟。

2.無狀態HTTP

在瞭解會話和Cookies以前,咱們還須要瞭解HTTP的一個特色:無狀態。

HTTP的無狀態是指HTTP協議對事務處理是沒有記憶能力的,也就是說服務器不知道客戶端是處於什麼狀態。當咱們向服務器發送請求後,服務器解析此請求,而後返回對應的響應,服務器負責完成這個過程,但這個過程是徹底獨立的,而服務器不會記錄先後狀態的變化,也就是說缺乏狀態記錄。這就意味值若是後續須要處理前邊的信息,則必須重傳一遍,這就致使額外傳遞了一些前面的重複請求,才能獲取後續響應,這種效果顯然不是咱們想要的。爲了保持先後狀態,咱們確定不能講前邊的請求所有重傳一次,這太浪費資源了,特別對於這種須要用戶登陸的頁面來講,更是棘手。這時兩個用於保持HTTP鏈接狀態的技術就出現了,它們分別是Cookies和會話。會話在服務端,也就是網站的服務器,用來保存用戶的會話信息;Cookies在客戶端,也能夠理解爲瀏覽器端,有了Cookies,瀏覽器在下一次訪問網頁時自動附帶上它發送給服務器,服務器經過識別Cookies並鑑定出是哪一個用戶,而後再判斷用戶是不是登陸狀態,而後返回響應的信息。

咱們能夠理解爲Cookies裏面保存了登陸的憑證,有了它,只須要在下次請求的時候攜帶Cookies發送請求,而不用從新輸入用戶名和密碼等信息。

在爬蟲中,有時候須要處理登陸才能訪問的頁面,咱們通常會直接把登陸成功後獲取的Cookies放在請求頭裏面直接請求,而沒必要從新模擬登陸。

下面,咱們來詳細剖析會話和Cookies。

1.會話

會話,其原本的含義是指善始善終的一系列動做或消息。好比,打電話時,從拿起電話撥號到掛斷電話這中間的一系列過程能夠稱爲一個會話。

而在Web中,會話對象用來儲存特定用戶會話所需的屬性及配置信息。這樣,當用戶在應用程序的Web頁之間跳轉時,存儲在會話對象中的變量將不會丟失,而是在整個用戶會話中一直存在下去。當用戶請求來自應用程序的Web頁時,若是該用戶尚未會話,Web服務器會自動建立一個會話對象。當會話過時或被放棄後,服務器將終止該會話。

總結一下,會話就是客戶端與服務器之間連續發生的一系列請求和響應的過程,會話對象session就是服務端用來存儲會話過程當中的信息。

2.Cookies

Cookies指某些網站爲了辨別用戶身份、進行會話跟蹤而存儲在用戶本地終端上的數據。

會話維持

那麼,咱們怎樣利用Cookies保持狀態呢?當客戶端第一次請求服務器時,服務器會返回一個響應頭中帶有Set-Cookies字段的響應給客戶端,用來標記是哪個用戶,客戶端瀏覽器會把Cookies保存起來。當瀏覽器下一次再次請求此網站時,瀏覽器會把此Cookies放到請求頭一塊兒提交給服務器,Cookies攜帶了會話的ID信息,服務器檢查該Cookies即可找到對應的會話是什麼,而後判斷會話狀態來辨認用戶狀態。

在成功登錄某個網站時,服務器會告訴客戶端設置了哪些Cookies信息,在後續訪問頁面時客戶端會把Cookies發送給服務器,服務器再找到對應的會話進行判斷。若是會話中的某些設置登陸狀態的變量是有效的,那就證實用戶處於登陸狀態,此時就會返回登陸以後才能看的頁面。

反之,若是Cookie是無效得,或者會話已通過期,咱們就不能繼續訪問頁面,此時極可能收到錯誤的響應或者跳轉到登陸頁面從新登陸。

因此,Cookies和會話須要配合,Cookies處於客戶端,會話處於服務端,兩者共同協做,就實現了登陸會話維持。

屬性結構

下來咱們來看一下Cookies裏面有哪些內容。以百度爲例,在瀏覽器開發者工具中的打開Application選項卡,而後在左側有一個Storage部分,最後一項即爲Cookies,將其點開,以下圖所示,這些就是Cookies。

能夠看到,這裏有不少條目,其中每一個條目能夠稱爲Cookie。他有如下幾個屬性:

Name:該Cookie的名稱。一旦建立,該名稱便不可更改。

Value:該Cookie的值。若是值爲Unicode字符,須要爲字符編碼。若是值爲二進制數據,則須要使用BASE64編碼。

Domain:能夠訪問該Cookie的域名。例如,若是設置爲.baidu.com,則全部以baidu.com結尾的域名均可以訪問該Cookie。

Max Age:該Cookie失效的時間,單位爲秒,也常和Expires一塊兒使用,經過它能夠計算出其有效時間。Max Age若是爲正數,則該Cookie在Max Age秒以後失效。若是爲負數,則關閉瀏覽器即失效,瀏覽器也不會以任何形式保留該Cookie。

Path:該Cookie的使用路徑。若是設置爲/path/,則只有路徑爲/path/的頁面才能夠訪問該Cookie。若是設置爲/,則本域名下的全部頁面均可以訪問該Cookie。

Size:該Cookie的大小。

HTTP:Cookie的httponly屬性。若此屬性爲true,則只有在HTTP頭中會帶有次Cookie信息,而不能經過document.cookie的訪問此Cookie。

Secure:該Cookie是否僅被使用安全協議傳輸。安全協議有HTTPS和SSL等,在網絡傳輸數據以前先將數據加密。默認爲false。

會話Cookie和持久Cookie

從表面意思上來看,會話Cookie就是把Cookie放在瀏覽器的內存裏,瀏覽器在關閉以後該Cookie失效;持久Cookie則會保存到客戶端的硬盤中,下次還能夠繼續使用,用於長久保持登陸狀態。

其實嚴格來講,沒有會話Cookie和持久Cookie之分,只不過由Cookie的Max Age和Expires字段決定了過時時間。

因此,一些持久化登陸的網站其實就是把Cookie的有效時間和會話有效期設置的比較長,下次咱們訪問頁面發送請求時仍然攜帶Cookies,就能夠直接保持登陸狀態。

3.常見誤區

當談論到會話機制時,經常聽到這樣一種誤解-------"只要把瀏覽器關閉,會話就消失了"。咱們能夠想象一下會員卡的例子,除非顧客主動對店家提出銷卡,不然店家絕對不會輕易刪除顧客的資料。對於會話來講也是同樣的,除非程序通知服務器刪除一個會話,不然服務器會一直保留。好比程序通常都是在咱們作註銷操做時纔去刪除會話。

當咱們關閉瀏覽時,瀏覽器不會通知服務器它將要關閉,因此當關閉瀏覽器時Cookies消失了,而大部分的會話機制都是用會話Cookie來保存會話ID信息,因此Cookies消失了,會話也就找不到了,這就是咱們產生錯覺的緣由了。

但若是咱們將Cookies保存到硬盤上,或者是使用某種手段改寫瀏覽器發出的HTTP請求頭,將原來的Cookies發送給服務器,咱們就能夠找到原來的會話ID,就會維持登陸狀態了。

而偏偏是因爲關閉瀏覽器不會刪除會話信息,這就須要服務器爲會話設置一個失效時間,當距客戶端上次使用這個會話的時間的時間超過了失效時間,服務器就會認爲客戶端中止了活動,就會刪除會話。

5.代理的基本原理

咱們在作爬蟲的過程當中常常會遇到這樣的狀況,剛開始爬蟲正常運行,正確抓取數據,一切都是那麼美好,然而一眨眼的功夫就可能出現錯誤,好比403 Forbidden,這時候打開網頁一看,可能會看到"您的IP訪問頻率過高"這樣的提示。出現這種現象的緣由是網站採起了一些反爬蟲的措施。好比,服務器會檢測某個IP在單位時間內的請求次數,若是超過了某個閾值,就會直接拒絕服務,返回一些錯誤信息,這種狀況稱爲封IP。

既然服務器檢測的是某個IP單位時間的請求次數,那麼藉助某種方法來封裝咱們的IP,讓服務器識別不出來是由咱們本機發起的請求,這樣不就能夠防止封IP了嗎?

一種有效的方式就是使用代理,下面咱們先了解一下代理的基本原理。

1.基本原理

代理實際上指的就是代理服務器,英文叫作proxy server,他的功能是代理網絡用戶去取得網絡信息。形象的說,它就是網絡信息中轉站。在咱們正常請求一個網站時,是發送請求給Web服務器,Web服務器把響應傳回給咱們。若是設置了代理服務器,實際上就是在本機和服務器之間搭建了一個橋,此時本機不是直接向Web服務器發起請求,而是向代理服務器發送請求,請求會發送給代理服務器,而後由代理服務器再發送給Web服務器,接着又代理服務器將服務器返回的響應返回給本機。這樣咱們能夠正常訪問頁面,可是Web服務器識別的真是IP就再也不是咱們本機的IP了,成功實現了IP假裝,這就是代理的基本原理。