一、網絡爬蟲相關概念
網絡爬蟲介紹
我們都知道，當前我們所處的時代是大數據的時代，在大數據時代，要進行數據分析，首先要有數據源，而學習爬蟲，可以讓我們獲取更多的數據源，並且這些數據源可以按我們的目的進行采集。
優酷推出的火星情報局就是基於網絡爬蟲和數據分析制作完成的。其中每期的節目話題都是從相關熱門的互動平台中進行相關數據的爬取，然后對爬取到的數據進行數據分析而得來的。另一方面，優酷根據用戶實時觀看視頻時的前進，后退等行為數據，能夠推測計算出觀眾的興趣點和愛好點，這樣有助於節目的剪輯和后期的節目方案的編寫。
今日頭條作為一個新聞推薦類的應用，其內部的新聞數據都是通過爬蟲程序在各個新聞網站進行新聞數據的爬取，然后通過相應的處理和運算將用戶感興趣的新聞話題推送到用戶的手機上。、
robots.txt協議
如果自己的門戶網站中的指定頁面中的數據不想讓爬蟲程序爬取到的話，那么則可以通過編寫一個robots.txt的協議文件來約束爬蟲程序的數據爬取。robots協議的編寫格式可以觀察淘寶網的robots（訪問www.taobao.com/robots.txt即可）。但是需要注意的是，該協議只是相當於口頭的協議，並沒有使用相關技術進行強制管制，所以該協議是防君子不防小人。但是我們在學習爬蟲階段編寫的爬蟲程序可以先忽略robots協議。
反爬蟲
門戶網站通過相應的策略和技術手段，防止爬蟲程序進行網站數據的爬取。
反反爬蟲
爬蟲程序通過相應的策略和技術手段，破解門戶網站的反爬蟲手段，從而爬取到相應的數據。
二、HTTP和HTTPS協議
2.1 HTTP協議
HTTP協議是Hyper Text Transfer Protocol（超文本傳輸協議）的縮寫,是用於從萬維網（WWW:World Wide Web ）服務器傳輸超文本到本地瀏覽器的傳送協議。
工作原理：
HTTP協議工作於客戶端-服務端架構為上。瀏覽器作為HTTP客戶端通過URL向HTTP服務端即WEB服務器發送所有請求。Web服務器根據接收到的請求后，向客戶端發送響應信息。
2.2 HTTP之Request:
報文頭：常被叫做請求頭，請求頭中存儲的是該請求的一些主要說明（自我介紹）。服務器據此獲取客戶端的信息。
常見的請求頭：
accept:瀏覽器通過這個頭告訴服務器，它所支持的數據類型
Accept-Charset: 瀏覽器通過這個頭告訴服務器，它支持哪種字符集
Accept-Encoding：瀏覽器通過這個頭告訴服務器，支持的壓縮格式
Accept-Language：瀏覽器通過這個頭告訴服務器，它的語言環境
Host：瀏覽器通過這個頭告訴服務器，想訪問哪台主機
If-Modified-Since: 瀏覽器通過這個頭告訴服務器，緩存數據的時間
Referer：瀏覽器通過這個頭告訴服務器，客戶機是哪個頁面來的 防盜鏈
Connection：瀏覽器通過這個頭告訴服務器，請求完后是斷開鏈接還是何持鏈接
X-Requested-With: XMLHttpRequest 代表通過ajax方式進行訪問
User-Agent：請求載體的身份標識
報文體：常被叫做請求體，請求體中存儲的是將要傳輸/發送給服務器的數據信息。
2.3 HTTP之Response：
服務器回傳一個HTTP響應到客戶端的響應消息包括以下組成部分：
常見的相應頭信息：
Location: 服務器通過這個頭，來告訴瀏覽器跳到哪里
Server：服務器通過這個頭，告訴瀏覽器服務器的型號
Content-Encoding：服務器通過這個頭，告訴瀏覽器，數據的壓縮格式
Content-Length: 服務器通過這個頭，告訴瀏覽器回送數據的長度
Content-Language: 服務器通過這個頭，告訴瀏覽器語言環境
Content-Type：服務器通過這個頭，告訴瀏覽器回送數據的類型
Refresh：服務器通過這個頭，告訴瀏覽器定時刷新
Content-Disposition: 服務器通過這個頭，告訴瀏覽器以下載方式打數據
Transfer-Encoding：服務器通過這個頭，告訴瀏覽器數據是以分塊方式回送的
Expires: -1 控制瀏覽器不要緩存
Cache-Control: no-cache
Pragma: no-cache
相應體：根據客戶端指定的請求信息，發送給客戶端的指定數據
2.4 HTTPS協議
1.官方概念：
HTTPS (Secure Hypertext Transfer Protocol)安全超文本傳輸協議，HTTPS是在HTTP上建立SSL加密層，並對傳輸數據進行加密，是HTTP協議的安全版。
2.5 HTTPS采用的加密技術
SSL加密技術
SSL采用的加密技術叫做“共享密鑰加密”，也叫作“對稱密鑰加密”，這種加密方法是這樣的，比如客戶端向服務器發送一條信息，首先客戶端會采用已知的算法對信息進行加密，比如MD5或者Base64加密，接收端對加密的信息進行解密的時候需要用到密鑰，中間會傳遞密鑰，（加密和解密的密鑰是同一個），密鑰在傳輸中間是被加密的。這種方式看起來安全，但是仍有潛在的危險，一旦被竊聽，或者信息被挾持，就有可能破解密鑰，而破解其中的信息。因此“共享密鑰加密”這種方式存在安全隱患：
非對稱秘鑰加密技術
“非對稱加密”使用的時候有兩把鎖，一把叫做“私有密鑰”，一把是“公開密鑰”，使用非對象加密的加密方式的時候，服務器首先告訴客戶端按照自己給定的公開密鑰進行加密處理，客戶端按照公開密鑰加密以后，服務器接受到信息再通過自己的私有密鑰進行解密，這樣做的好處就是解密的鑰匙根本就不會進行傳輸，因此也就避免了被挾持的風險。就算公開密鑰被竊聽者拿到了，它也很難進行解密，因為解密過程是對離散對數求值，這可不是輕而易舉就能做到的事。以下是非對稱加密的原理圖：
但是非對稱秘鑰加密技術也存在如下缺點：
第一個是：如何保證接收端向發送端發出公開秘鑰的時候，發送端確保收到的是預先要發送的，而不會被挾持。只要是發送密鑰，就有可能有被挾持的風險。
第二個是：非對稱加密的方式效率比較低，它處理起來更為復雜，通信過程中使用就有一定的效率問題而影響通信速度
2.7 HTTPS的證書機制
在上面我們講了非對稱加密的缺點，其中第一個就是公鑰很可能存在被挾持的情況，無法保證客戶端收到的公開密鑰就是服務器發行的公開密鑰。此時就引出了公開密鑰證書機制。數字證書認證機構是客戶端與服務器都可信賴的第三方機構。證書的具體傳播過程如下：
1：服務器的開發者攜帶公開密鑰，向數字證書認證機構提出公開密鑰的申請，數字證書認證機構在認清申請者的身份，審核通過以后，會對開發者申請的公開密鑰做數字簽名，然后分配這個已簽名的公開密鑰，並將密鑰放在證書里面，綁定在一起
2：服務器將這份數字證書發送給客戶端，因為客戶端也認可證書機構，客戶端可以通過數字證書中的數字簽名來驗證公鑰的真偽，來確保服務器傳過來的公開密鑰是真實的。一般情況下，證書的數字簽名是很難被偽造的，這取決於認證機構的公信力。一旦確認信息無誤之后，客戶端就會通過公鑰對報文進行加密發送，服務器接收到以后用自己的私鑰進行解密