在本節中,我們會詳細瞭解HTTP的基本原理,瞭解在瀏覽器中敲入URL到獲取網頁內容之間發生了什麼。瞭解了這些內容,有助於我們進一步瞭解爬蟲的基本原理。
1. URI和URL
這裡我們先了解一下URI和URL,URI的全稱為Uniform Resource Identifier,即統一資源標誌符,URL的全稱為Universal Resource Locator,即統一資源定位符。
舉例來說,github.com/favicon.ico是GitHub的網站圖示連結,它是一個URL,也是一個URI。即有這樣的一個圖示資源,我們用URL/URI來唯一指定了它的訪問方式,這其中包括了訪問協議https、訪問路徑(/即根目錄)和資源名稱favicon.ico。通過這樣一個連結,我們便可以從網際網路上找到這個資源,這就是URL/URI。
URL是URI的子集,也就是說每個URL都是URI,但不是每個URI都是URL。那麼,怎樣的URI不是URL呢?URI還包括一個子類叫作URN,它的全稱為Universal Resource Name,即統一資源名稱。URN只命名資源而不指定如何定位資源,比如urn:isbn:0451450523指定了一本書的ISBN,可以唯一標識這本書,但是沒有指定到哪裡定位這本書,這就是URN。URL、URN和URI的關係可以用圖2-1表示。
圖2-1 URL、URN和URI關係圖
但是在目前的網際網路中,URN用得非常少,所以幾乎所有的URI都是URL,一般的網頁連結我們既可以稱為URL,也可以稱為URI,我個人習慣稱為URL。
2. 超文字
接下來,我們再瞭解一個概念——超文字,其英文名稱叫作hypertext,我們在瀏覽器裡看到的網頁就是超文字解析而成的,其網頁原始碼是一系列HTML程式碼,裡面包含了一系列標籤,比如img
顯示圖片,p
指定顯示段落等。瀏覽器解析這些標籤後,便形成了我們平常看到的網頁,而網頁的原始碼HTML就可以稱作超文字。
例如,我們在Chrome瀏覽器裡面開啟任意一個頁面,如淘寶首頁,右擊任一地方並選擇“檢查”項(或者直接按快捷鍵F12),即可開啟瀏覽器的開發者工具,這時在Elements選項卡即可看到當前網頁的原始碼,這些原始碼都是超文字,如圖2-2所示。
圖2-2 原始碼
3. HTTP和HTTPS
在淘寶的首頁www.taobao.com/中,URL的開頭會有http或https,這就是訪問資源需要的協議型別。有時,我們還會看到ftp、sftp、smb開頭的URL,它們都是協議型別。在爬蟲中,我們抓取的頁面通常就是http或https協議的,這裡首先了解一下這兩個協議的含義。
HTTP的全稱是Hyper Text Transfer Protocol,中文名叫作超文字傳輸協議。HTTP協議是用於從網路傳輸超文字資料到本地瀏覽器的傳送協議,它能保證高效而準確地傳送超文字文件。HTTP由全球資訊網協會(World Wide Web Consortium)和Internet工作小組IETF(Internet Engineering Task Force)共同合作制定的規範,目前廣泛使用的是HTTP 1.1版本。
HTTPS的全稱是Hyper Text Transfer Protocol over Secure Socket Layer,是以安全為目標的HTTP通道,簡單講是HTTP的安全版,即HTTP下加入SSL層,簡稱為HTTPS。
HTTPS的安全基礎是SSL,因此通過它傳輸的內容都是經過SSL加密的,它的主要作用可以分為兩種。
- 建立一個資訊保安通道來保證資料傳輸的安全。
- 確認網站的真實性,凡是使用了HTTPS的網站,都可以通過點選瀏覽器位址列的鎖頭標誌來檢視網站認證之後的真實資訊,也可以通過CA機構頒發的安全簽章來查詢。
現在越來越多的網站和App都已經向HTTPS方向發展,例如:
- 蘋果公司強制所有iOS App在2017年1月1日前全部改為使用HTTPS加密,否則App就無法在應用商店上架;
- 谷歌從2017年1月推出的Chrome 56開始,對未進行HTTPS加密的網址連結亮出風險提示,即在位址列的顯著位置提醒使用者“此網頁不安全”;
- 騰訊微信小程式的官方需求文件要求後臺使用HTTPS請求進行網路通訊,不滿足條件的域名和協議無法請求。
而某些網站雖然使用了HTTPS協議,但還是會被瀏覽器提示不安全,例如我們在Chrome瀏覽器裡面開啟12306,連結為:www.12306.cn/,這時瀏覽器就會提示“您的連線不是私密連線”這樣的話,如圖2-3所示。
圖2-3 12306頁面
這是因為12306的CA證照是中國鐵道部自行簽發的,而這個證照是不被CA機構信任的,所以這裡證照驗證就不會通過而提示這樣的話,但是實際上它的資料傳輸依然是經過SSL加密的。如果要爬取這樣的站點,就需要設定忽略證照的選項,否則會提示SSL連結錯誤。
4. HTTP請求過程
我們在瀏覽器中輸入一個URL,回車之後便會在瀏覽器中觀察到頁面內容。實際上,這個過程是瀏覽器向網站所在的伺服器傳送了一個請求,網站伺服器接收到這個請求後進行處理和解析,然後返回對應的響應,接著傳回給瀏覽器。響應裡包含了頁面的原始碼等內容,瀏覽器再對其進行解析,便將網頁呈現了出來,模型如圖2-4所示。
圖2-4 模型圖
此處客戶端即代表我們自己的PC或手機瀏覽器,伺服器即要訪問的網站所在的伺服器。
為了更直觀地地說明這個過程,這裡用Chrome瀏覽器的開發者模式下的Network監聽元件來做下演示,它可以顯示訪問當前請求網頁時發生的所有網路請求和響應。
開啟Chrome瀏覽器,右擊並選擇“檢查”項,即可開啟瀏覽器的開發者工具。這裡訪問百度www.baidu.com/,輸入該URL後回車,觀察這個過程中發生了怎樣的網路請求。可以看到,在Network頁面下方出現了一個個的條目,其中一個條目就代表一次傳送請求和接收響應的過程,如圖2-5所示。
圖2-5 Network皮膚
我們先觀察第一個網路請求,即www.baidu.com。
其中各列的含義如下。
- 第一列Name:請求的名稱,一般會將URL的最後一部分內容當作名稱。
- 第二列Status:響應的狀態碼,這裡顯示為200,代表響應是正常的。通過狀態碼,我們可以判斷髮送了請求之後是否得到了正常的響應。
- 第三列Type:請求的文件型別。這裡為document,代表我們這次請求的是一個HTML文件,內容就是一些HTML程式碼。
- 第四列Initiator:請求源。用來標記請求是由哪個物件或程式發起的。
- 第五列Size:從伺服器下載的檔案和請求的資源大小。如果是從快取中取得的資源,則該列會顯示from cache。
- 第六列Time:發起請求到獲取響應所用的總時間。
- 第七列Waterfall:網路請求的視覺化瀑布流。
點選這個條目,即可看到更詳細的資訊,如圖2-6所示。
圖2-6 詳細資訊
首先是General部分,Request URL為請求的URL,Request Method為請求的方法,Status Code為響應狀態碼,Remote Address為遠端伺服器的地址和埠,Referrer Policy為Referrer判別策略。
再繼續往下看,可以看到,有Response Headers和Request Headers,這分別代表響應頭和請求頭。請求頭裡帶有許多請求資訊,例如瀏覽器標識、Cookies、Host等資訊,這是請求的一部分,伺服器會根據請求頭內的資訊判斷請求是否合法,進而作出對應的響應。圖中看到的Response Headers就是響應的一部分,例如其中包含了伺服器的型別、文件型別、日期等資訊,瀏覽器接受到響應後,會解析響應內容,進而呈現網頁內容。
下面我們分別來介紹一下請求和響應都包含哪些內容。
5. 請求
請求,由客戶端向服務端發出,可以分為4部分內容:請求方法(Request Method)、請求的網址(Request URL)、請求頭(Request Headers)、請求體(Request Body)。
(1) 請求方法
常見的請求方法有兩種:GET和POST。
在瀏覽器中直接輸入URL並回車,這便發起了一個GET請求,請求的引數會直接包含到URL裡。例如,在百度中搜尋Python,這就是一個GET請求,連結為www.baidu.com/s?wd=Python,其中URL中包含了請求的引數資訊,這裡引數wd
表示要搜尋的關鍵字。POST請求大多在表單提交時發起。比如,對於一個登入表單,輸入使用者名稱和密碼後,點選“登入”按鈕,這通常會發起一個POST請求,其資料通常以表單的形式傳輸,而不會體現在URL中。
GET和POST請求方法有如下區別。
- GET請求中的引數包含在URL裡面,資料可以在URL中看到,而POST請求的URL不會包含這些資料,資料都是通過表單形式傳輸的,會包含在請求體中。
- GET請求提交的資料最多隻有1024位元組,而POST方式沒有限制。
一般來說,登入時,需要提交使用者名稱和密碼,其中包含了敏感資訊,使用GET方式請求的話,密碼就會暴露在URL裡面,造成密碼洩露,所以這裡最好以POST方式傳送。上傳檔案時,由於檔案內容比較大,也會選用POST方式。
我們平常遇到的絕大部分請求都是GET或POST請求,另外還有一些請求方法,如GET、HEAD、POST、PUT、DELETE、OPTIONS、CONNECT、TRACE等,我們簡單將其總結為表2-1。
表2-1 其他請求方法
方法 | 描述 |
---|---|
GET | 請求頁面,並返回頁面內容 |
HEAD | 類似於GET請求,只不過返回的響應中沒有具體的內容,用於獲取報頭 |
POST | 大多用於提交表單或上傳檔案,資料包含在請求體中 |
PUT | 從客戶端向伺服器傳送的資料取代指定文件中的內容 |
DELETE | 請求伺服器刪除指定的頁面 |
CONNECT | 把伺服器當作跳板,讓伺服器代替客戶端訪問其他網頁 |
OPTIONS | 允許客戶端檢視伺服器的效能 |
TRACE | 回顯伺服器收到的請求,主要用於測試或診斷 |
本表參考:www.runoob.com/http/http-m…。
(2) 請求的網址
請求的網址,即統一資源定位符URL,它可以唯一確定我們想請求的資源。
(3) 請求頭
請求頭,用來說明伺服器要使用的附加資訊,比較重要的資訊有Cookie、Referer、User-Agent等。下面簡要說明一些常用的頭資訊。
- Accept:請求報頭域,用於指定客戶端可接受哪些型別的資訊。
- Accept-Language:指定客戶端可接受的語言型別。
- Accept-Encoding:指定客戶端可接受的內容編碼。
- Host:用於指定請求資源的主機IP和埠號,其內容為請求URL的原始伺服器或閘道器的位置。從HTTP 1.1版本開始,請求必須包含此內容。
- Cookie:也常用複數形式 Cookies,這是網站為了辨別使用者進行會話跟蹤而儲存在使用者本地的資料。它的主要功能是維持當前訪問會話。例如,我們輸入使用者名稱和密碼成功登入某個網站後,伺服器會用會話儲存登入狀態資訊,後面我們每次重新整理或請求該站點的其他頁面時,會發現都是登入狀態,這就是Cookies的功勞。Cookies裡有資訊標識了我們所對應的伺服器的會話,每次瀏覽器在請求該站點的頁面時,都會在請求頭中加上Cookies並將其傳送給伺服器,伺服器通過Cookies識別出是我們自己,並且查出當前狀態是登入狀態,所以返回結果就是登入之後才能看到的網頁內容。
- Referer:此內容用來標識這個請求是從哪個頁面發過來的,伺服器可以拿到這一資訊並做相應的處理,如作來源統計、防盜鏈處理等。
- User-Agent:簡稱UA,它是一個特殊的字串頭,可以使伺服器識別客戶使用的作業系統及版本、瀏覽器及版本等資訊。在做爬蟲時加上此資訊,可以偽裝為瀏覽器;如果不加,很可能會被識別出為爬蟲。
- Content-Type:也叫網際網路媒體型別(Internet Media Type)或者MIME型別,在HTTP協議訊息頭中,它用來表示具體請求中的媒體型別資訊。例如,text/html代表HTML格式,image/gif代表GIF圖片,application/json代表JSON型別,更多對應關係可以檢視此對照表:tool.oschina.net/commons。
因此,請求頭是請求的重要組成部分,在寫爬蟲時,大部分情況下都需要設定請求頭。
(4) 請求體
請求體一般承載的內容是POST請求中的表單資料,而對於GET請求,請求體則為空。
例如,這裡我登入GitHub時捕獲到的請求和響應如圖2-7所示。
圖2-7 詳細資訊
登入之前,我們填寫了使用者名稱和密碼資訊,提交時這些內容就會以表單資料的形式提交給伺服器,此時需要注意Request Headers中指定Content-Type為application/x-www-form-urlencoded。只有設定Content-Type為application/x-www-form-urlencoded,才會以表單資料的形式提交。另外,我們也可以將Content-Type設定為application/json來提交JSON資料,或者設定為multipart/form-data來上傳檔案。
表2-2列出了Content-Type和POST提交資料方式的關係。
表2-2 Content-Type和POST提交資料方式的關係
Content-Type | 提交資料的方式 |
---|---|
application/x-www-form-urlencoded | 表單資料 |
multipart/form-data | 表單檔案上傳 |
application/json | 序列化JSON資料 |
text/xml | XML資料 |
在爬蟲中,如果要構造POST請求,需要使用正確的Content-Type,並瞭解各種請求庫的各個引數設定時使用的是哪種Content-Type,不然可能會導致POST提交後無法正常響應。
6. 響應
響應,由服務端返回給客戶端,可以分為三部分:響應狀態碼(Response Status Code)、響應頭(Response Headers)和響應體(Response Body)。
(1) 響應狀態碼
響應狀態碼錶示伺服器的響應狀態,如200代表伺服器正常響應,404代表頁面未找到,500代表伺服器內部發生錯誤。在爬蟲中,我們可以根據狀態碼來判斷伺服器響應狀態,如狀態碼為200,則證明成功返回資料,再進行進一步的處理,否則直接忽略。表2-3列出了常見的錯誤程式碼及錯誤原因。
表2-3 常見的錯誤程式碼及錯誤原因
狀態碼 | 說明 | 詳情 |
---|---|---|
100 | 繼續 | 請求者應當繼續提出請求。伺服器已收到請求的一部分,正在等待其餘部分 |
101 | 切換協議 | 請求者已要求伺服器切換協議,伺服器已確認並準備切換 |
200 | 成功 | 伺服器已成功處理了請求 |
201 | 已建立 | 請求成功並且伺服器建立了新的資源 |
202 | 已接受 | 伺服器已接受請求,但尚未處理 |
203 | 非授權資訊 | 伺服器已成功處理了請求,但返回的資訊可能來自另一個源 |
204 | 無內容 | 伺服器成功處理了請求,但沒有返回任何內容 |
205 | 重置內容 | 伺服器成功處理了請求,內容被重置 |
206 | 部分內容 | 伺服器成功處理了部分請求 |
300 | 多種選擇 | 針對請求,伺服器可執行多種操作 |
301 | 永久移動 | 請求的網頁已永久移動到新位置,即永久重定向 |
302 | 臨時移動 | 請求的網頁暫時跳轉到其他頁面,即暫時重定向 |
303 | 檢視其他位置 | 如果原來的請求是POST,重定向目標文件應該通過GET提取 |
304 | 未修改 | 此次請求返回的網頁未修改,繼續使用上次的資源 |
305 | 使用代理 | 請求者應該使用代理訪問該網頁 |
307 | 臨時重定向 | 請求的資源臨時從其他位置響應 |
400 | 錯誤請求 | 伺服器無法解析該請求 |
401 | 未授權 | 請求沒有進行身份驗證或驗證未通過 |
403 | 禁止訪問 | 伺服器拒絕此請求 |
404 | 未找到 | 伺服器找不到請求的網頁 |
405 | 方法禁用 | 伺服器禁用了請求中指定的方法 |
406 | 不接受 | 無法使用請求的內容響應請求的網頁 |
407 | 需要代理授權 | 請求者需要使用代理授權 |
408 | 請求超時 | 伺服器請求超時 |
409 | 衝突 | 伺服器在完成請求時發生衝突 |
410 | 已刪除 | 請求的資源已永久刪除 |
411 | 需要有效長度 | 伺服器不接受不含有效內容長度標頭欄位的請求 |
412 | 未滿足前提條件 | 伺服器未滿足請求者在請求中設定的其中一個前提條件 |
413 | 請求實體過大 | 請求實體過大,超出伺服器的處理能力 |
414 | 請求URI過長 | 請求網址過長,伺服器無法處理 |
415 | 不支援型別 | 請求格式不被請求頁面支援 |
416 | 請求範圍不符 | 頁面無法提供請求的範圍 |
417 | 未滿足期望值 | 伺服器未滿足期望請求標頭欄位的要求 |
500 | 伺服器內部錯誤 | 伺服器遇到錯誤,無法完成請求 |
501 | 未實現 | 伺服器不具備完成請求的功能 |
502 | 錯誤閘道器 | 伺服器作為閘道器或代理,從上游伺服器收到無效響應 |
503 | 服務不可用 | 伺服器目前無法使用 |
504 | 閘道器超時 | 伺服器作為閘道器或代理,但是沒有及時從上游伺服器收到請求 |
505 | HTTP版本不支援 | 伺服器不支援請求中所用的HTTP協議版本 |
(2) 響應頭
響應頭包含了伺服器對請求的應答資訊,如Content-Type、Server、Set-Cookie等。下面簡要說明一些常用的頭資訊。
- Date:標識響應產生的時間。
- Last-Modified:指定資源的最後修改時間。
- Content-Encoding:指定響應內容的編碼。
- Server:包含伺服器的資訊,比如名稱、版本號等。
- Content-Type:文件型別,指定返回的資料型別是什麼,如text/html代表返回HTML文件,application/x-javascript則代表返回JavaScript檔案,image/jpeg則代表返回圖片。
- Set-Cookie:設定Cookies。響應頭中的Set-Cookie告訴瀏覽器需要將此內容放在Cookies中,下次請求攜帶Cookies請求。
- Expires:指定響應的過期時間,可以使代理伺服器或瀏覽器將載入的內容更新到快取中。如果再次訪問時,就可以直接從快取中載入,降低伺服器負載,縮短載入時間。
(3) 響應體
最重要的當屬響應體的內容了。響應的正文資料都在響應體中,比如請求網頁時,它的響應體就是網頁的HTML程式碼;請求一張圖片時,它的響應體就是圖片的二進位制資料。我們做爬蟲請求網頁後,要解析的內容就是響應體,如圖2-8所示。
圖2-8 響應體內容
在瀏覽器開發者工具中點選Preview,就可以看到網頁的原始碼,也就是響應體的內容,它是解析的目標。
在做爬蟲時,我們主要通過響應體得到網頁的原始碼、JSON資料等,然後從中做相應內容的提取。
本節中,我們瞭解了HTTP的基本原理,大概瞭解了訪問網頁時背後的請求和響應過程。本節涉及的知識點需要好好掌握,後面分析網頁請求時會經常用到。
本資源首發於崔慶才的個人部落格靜覓: Python3網路爬蟲開發實戰教程 | 靜覓
如想了解更多爬蟲資訊,請關注我的個人微信公眾號:進擊的Coder
weixin.qq.com/r/5zsjOyvEZ… (二維碼自動識別)