HTTP和HTTPS

HTTP協(xié)議（HyperText Transfer Protocol，超文本傳輸協(xié)議）：是一種發(fā)布和接收 HTML頁面的方法。

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

SSL（Secure Sockets Layer 安全套接層）主要用于Web的安全傳輸協(xié)議蹋嵌，在傳輸層對網(wǎng)絡(luò)連接進(jìn)行加密，保障在Internet上數(shù)據(jù)傳輸?shù)陌踩?

• HTTP的端口號為80
• HTTPS的端口號為443

HTTP的工作原理

網(wǎng)絡(luò)爬蟲抓取過程可以理解為模擬瀏覽器操作的過程。

瀏覽器的主要功能是向服務(wù)器發(fā)出請求，在瀏覽器窗口中展示您選擇的網(wǎng)絡(luò)資源姻成，HTTP是一套計(jì)算機(jī)通過網(wǎng)絡(luò)進(jìn)行通信的規(guī)則。

HTTP的請求與響應(yīng)

HTTP通信由兩部分組成：** 客戶端請求消息** 與 服務(wù)器響應(yīng)消息

image.png

瀏覽器發(fā)送HTTP請求的過程：

1. 當(dāng)用戶在瀏覽器的地址欄中輸入一個(gè)URL并按回車鍵之后愿棋，瀏覽器會向HTTP服務(wù)器發(fā)送HTTP請求科展。HTTP請求主要分為“Get”和“Post”兩種方法。

2. 當(dāng)我們在瀏覽器輸入U(xiǎn)RL http://www.baidu.com 的時(shí)候糠雨，瀏覽器發(fā)送一個(gè)Request請求去獲取 http://www.baidu.com 的html文件才睹，服務(wù)器把Response文件對象發(fā)送回給瀏覽器。

3. 瀏覽器分析Response中的 HTML甘邀，發(fā)現(xiàn)其中引用了很多其他文件琅攘，比如Images文件，CSS文件松邪，JS文件坞琴。 瀏覽器會自動(dòng)再次發(fā)送Request去獲取圖片，CSS文件逗抑，或者JS文件剧辐。

4. 當(dāng)所有的文件都下載成功后，網(wǎng)頁會根據(jù)HTML語法結(jié)構(gòu)邮府，完整的顯示出來了荧关。

URL（Uniform / Universal Resource Locator的縮寫）：統(tǒng)一資源定位符，是用于完整地描述Internet上網(wǎng)頁和其他資源的地址的一種標(biāo)識方法褂傀。

image.png

• scheme：協(xié)議(例如：http, https, ftp)
• host：服務(wù)器的IP地址或者域名
• port#：服務(wù)器的端口（如果是走協(xié)議默認(rèn)端口忍啤，缺省端口80）
• path：訪問資源的路徑
• query-string：參數(shù)，發(fā)送給http服務(wù)器的數(shù)據(jù)
• anchor：錨（跳轉(zhuǎn)到網(wǎng)頁的指定錨點(diǎn)位置）

例如：

• ftp://192.168.0.116:8080/index

• http://www.baidu.com

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

客戶端HTTP請求

URL只是標(biāo)識資源的位置紊服，而HTTP是用來提交和獲取資源檀轨。客戶端發(fā)送一個(gè)HTTP請求到服務(wù)器的請求消息欺嗤，包括以下格式：
請求行参萄、請求頭部、空行煎饼、請求數(shù)據(jù)
四個(gè)部分組成讹挎，下圖給出了請求報(bào)文的一般格式。

image.png

GET https://www.baidu.com/ HTTP/1.1
Host: www.baidu.com
Connection: keep-alive
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.99 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Referer: http://www.baidu.com/
Accept-Encoding: gzip, deflate, sdch, br
Accept-Language: zh-CN,zh;q=0.8,en;q=0.6
Cookie: 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

根據(jù)HTTP標(biāo)準(zhǔn)，HTTP請求可以使用多種請求方法筒溃。

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

HTTP 1.0：完善的請求/響應(yīng)模型，并將協(xié)議補(bǔ)充完整怜奖，定義了三種請求方法： GET, POST 和 HEAD方法浑测。

HTTP 1.1：在 1.0 基礎(chǔ)上進(jìn)行更新，新增了五種請求方法：OPTIONS, PUT, DELETE, TRACE 和 CONNECT 方法歪玲。

HTTP 2.0（未普及）：請求/響應(yīng)首部的定義基本沒有改變迁央，只是所有首部鍵必須全部小寫，而且請求行要獨(dú)立為 :method滥崩、:scheme岖圈、:host、:path這些鍵值對钙皮。

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

• GET是從服務(wù)器上獲取數(shù)據(jù)命斧，POST是向服務(wù)器傳送數(shù)據(jù)

• GET請求參數(shù)顯示，都顯示在瀏覽器網(wǎng)址上嘱兼，HTTP服務(wù)器根據(jù)該請求所包含URL中的參數(shù)來產(chǎn)生響應(yīng)內(nèi)容国葬，即“Get”請求的參數(shù)是URL的一部分。 例如： http://www.baidu.com/s?wd=Chinese

• POST請求參數(shù)在請求體當(dāng)中芹壕，消息長度沒有限制而且以隱式的方式進(jìn)行發(fā)送汇四，通常用來向HTTP服務(wù)器提交量比較大的數(shù)據(jù)（比如請求中包含許多參數(shù)或者文件上傳操作等），請求的參數(shù)包含在“Content-Type”消息頭里踢涌，指明該消息體的媒體類型和編碼通孽，
  注意：避免使用Get方式提交表單，因?yàn)橛锌赡軙?dǎo)致安全問題睁壁。 比如說在登陸表單中用Get方式背苦，用戶輸入的用戶名和密碼將在地址欄中暴露無遺互捌。

常用的請求報(bào)頭

1. Host (主機(jī)和端口號)

Host：對應(yīng)網(wǎng)址URL中的Web名稱和端口號，用于指定被請求資源的Internet主機(jī)和端口號行剂，通常屬于URL的一部分秕噪。

2. Connection (鏈接類型)

Connection：表示客戶端與服務(wù)連接類型

1.Client 發(fā)起一個(gè)包含 Connection:keep-alive 的請求，HTTP/1.1使用 keep-alive 為默認(rèn)值厚宰。

2.Server收到請求后：

• 如果 Server 支持 keep-alive腌巾，回復(fù)一個(gè)包含 Connection:keep-alive 的響應(yīng)，不關(guān)閉連接固阁；
• 如果 Server 不支持 keep-alive壤躲，回復(fù)一個(gè)包含 Connection:close 的響應(yīng)，關(guān)閉連接备燃。

3.如果client收到包含 Connection:keep-alive 的響應(yīng)，向同一個(gè)連接發(fā)送下一個(gè)請求凌唬，直到一方主動(dòng)關(guān)閉連接并齐。
keep-alive在很多情況下能夠重用連接，減少資源消耗客税，縮短響應(yīng)時(shí)間况褪，比如當(dāng)瀏覽器需要多個(gè)文件時(shí)(比如一個(gè)HTML文件和相關(guān)的圖形文件)，不需要每次都去請求建立連接更耻。

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

Upgrade-Insecure-Requests：升級不安全的請求测垛，意思是會在加載 http 資源時(shí)自動(dòng)替換成 https 請求，讓瀏覽器不再顯示https頁面中的http請求警報(bào)秧均。

HTTPS 是以安全為目標(biāo)的 HTTP 通道食侮，所以在 HTTPS 承載的頁面上不允許出現(xiàn) HTTP 請求，一旦出現(xiàn)就是提示或報(bào)錯(cuò)目胡。

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

User-Agent：是客戶瀏覽器的名稱锯七，以后會詳細(xì)講

5. Accept (傳輸文件類型)

Accept： 指瀏覽器或其他客戶端可以接受的MIME（Multipurpose Internet Mail Extensions（多用途互聯(lián)網(wǎng)郵件擴(kuò)展））文件類型，服務(wù)器可以根據(jù)它判斷并返回適當(dāng)?shù)奈募袷健?br> 舉例

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是權(quán)重系數(shù)筑累，范圍 0 =< q <= 1袱蜡，q 值越大，請求越傾向于獲得其“;”之前的類型表示的內(nèi)容疼阔。若沒有指定q值戒劫，則默認(rèn)為1半夷，按從左到右排序順序；若被賦值為0迅细，則用于表示瀏覽器不接受此內(nèi)容類型巫橄。

Text：用于標(biāo)準(zhǔn)化地表示的文本信息，文本消息可以是多種字符集和或者多種格式的茵典；Application：用于傳輸應(yīng)用程序數(shù)據(jù)或者二進(jìn)制數(shù)據(jù)詳細(xì)請點(diǎn)擊

6. Referer (頁面跳轉(zhuǎn)處)

Referer：表明產(chǎn)生請求的網(wǎng)頁來自于哪個(gè)URL湘换，用戶是從該 Referer頁面訪問到當(dāng)前請求的頁面。這個(gè)屬性可以用來跟蹤Web請求來自哪個(gè)頁面统阿，是從什么網(wǎng)站來的等彩倚。

有時(shí)候遇到下載某網(wǎng)站圖片，需要對應(yīng)的referer扶平，否則無法下載圖片帆离，那是因?yàn)槿思易隽朔辣I鏈，原理就是根據(jù)referer去判斷是否是本網(wǎng)站的地址结澄，如果不是哥谷，則拒絕，如果是麻献，就可以下載们妥；

7. Accept-Encoding（文件編解碼格式）

Accept-Encoding：指出瀏覽器可以接受的編碼方式。編碼方式不同于文件格式勉吻，它是為了壓縮文件并加速文件傳遞速度监婶。瀏覽器在接收到Web響應(yīng)之后先解碼，然后再檢查文件格式齿桃，許多情形下這可以減少大量的下載時(shí)間惑惶。
舉例：Accept-Encoding:gzip;q=1.0, identity; q=0.5, ;q=0
如果有多個(gè)Encoding同時(shí)匹配, 按照q值順序排列，本例中按順序支持 gzip, identity壓縮編碼源譬，支持gzip的瀏覽器會返回經(jīng)過gzip編碼的HTML頁面集惋。如果請求消息中沒有設(shè)置這個(gè)域服務(wù)器假定客戶端對各種內(nèi)容編碼都可以接受。

8. Accept-Language（語言種類）

Accept-Langeuage：指出瀏覽器可以接受的語言種類踩娘，如en或en-us指英語刮刑，zh或者zh-cn指中文，當(dāng)服務(wù)器能夠提供一種以上的語言版本時(shí)要用到养渴。

9. Accept-Charset（字符編碼）

Accept-Charset：指出瀏覽器可以接受的字符編碼雷绢。
舉例：Accept-Charset:iso-8859-1,gb2312,utf-8

• ISO8859-1：通常叫做Latin-1。Latin-1包括了書寫所有西方歐洲語言不可缺少的附加字符理卑，英文瀏覽器的默認(rèn)值是ISO-8859-1.
• gb2312：標(biāo)準(zhǔn)簡體中文字符集;
• utf-8：UNICODE 的一種變長字符編碼翘紊，可以解決多種語言文本顯示問題，從而實(shí)現(xiàn)應(yīng)用國際化和本地化藐唠。
  如果在請求消息中沒有設(shè)置這個(gè)域帆疟，缺省是任何字符集都可以接受鹉究。

10. Cookie （Cookie）

Cookie：瀏覽器用這個(gè)屬性向服務(wù)器發(fā)送Cookie。Cookie是在瀏覽器中寄存的小型數(shù)據(jù)體踪宠，它可以記載和服務(wù)器相關(guān)的用戶信息自赔，也可以用來實(shí)現(xiàn)會話功能，以后會詳細(xì)講柳琢。

11. Content-Type (POST數(shù)據(jù)類型)

Content-Type：POST請求里用來表示的內(nèi)容類型绍妨。

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

指明該請求的消息體中包含的是純文本的XML類型的數(shù)據(jù)，字符編碼采用“gb2312”柬脸。

服務(wù)端HTTP響應(yīng)

HTTP響應(yīng)也由四個(gè)部分組成他去，分別是：狀態(tài)行、消息報(bào)頭倒堕、空行灾测、響應(yīng)正文

image.png

HTTP/1.1 200 OK
Server: Tengine
Connection: keep-alive
Date: Wed, 30 Nov 2016 07:58:21 GMT
Cache-Control: no-cache
Content-Type: text/html;charset=UTF-8
Keep-Alive: timeout=20
Vary: Accept-Encoding
Pragma: no-cache
X-NWS-LOG-UUID: bd27210a-24e5-4740-8f6c-25dbafa9c395
Content-Length: 180945

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" ....

常用的響應(yīng)報(bào)頭(了解)

理論上所有的響應(yīng)頭信息都應(yīng)該是回應(yīng)請求頭的。但是服務(wù)端為了效率涩馆，安全行施，還有其他方面的考慮，會添加相對應(yīng)的響應(yīng)頭信息魂那，從上圖可以看到：

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

這個(gè)值告訴客戶端稠项，服務(wù)端不希望客戶端緩存資源涯雅，在下次請求資源時(shí)，必須要從新請求服務(wù)器展运，不能從緩存副本中獲取資源活逆。

• Cache-Control是響應(yīng)頭中很重要的信息，當(dāng)客戶端請求頭中包含Cache-Control:max-age=0請求拗胜，明確表示不會緩存服務(wù)器資源時(shí),Cache-Control作為作為回應(yīng)信息蔗候，通常會返回no-cache，意思就是說埂软，"那就不緩存唄"锈遥。

• 當(dāng)客戶端在請求頭中沒有包含Cache-Control時(shí)，服務(wù)端往往會定,不同的資源不同的緩存策略勘畔，比如說oschina在緩存圖片資源的策略就是Cache-Control：max-age=86400,這個(gè)意思是所灸，從當(dāng)前時(shí)間開始，在86400秒的時(shí)間內(nèi)炫七，客戶端可以直接從緩存副本中讀取資源爬立，而不需要向服務(wù)器請求。

2. Connection：keep-alive

這個(gè)字段作為回應(yīng)客戶端的Connection：keep-alive万哪，告訴客戶端服務(wù)器的tcp連接也是一個(gè)長連接侠驯，客戶端可以繼續(xù)使用這個(gè)tcp連接發(fā)送http請求抡秆。

3. Content-Encoding:gzip

告訴客戶端，服務(wù)端發(fā)送的資源是采用gzip編碼的吟策，客戶端看到這個(gè)信息后儒士，應(yīng)該采用gzip對資源進(jìn)行解碼。

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

告訴客戶端踊挠，資源文件的類型乍桂，還有字符編碼，客戶端通過utf-8對資源進(jìn)行解碼效床，然后對資源進(jìn)行html解析睹酌。通常我們會看到有些網(wǎng)站是亂碼的，往往就是服務(wù)器端沒有返回正確的編碼剩檀。

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

這個(gè)是服務(wù)端發(fā)送資源時(shí)的服務(wù)器時(shí)間憋沿，GMT是格林尼治所在地的標(biāo)準(zhǔn)時(shí)間。http協(xié)議中發(fā)送的時(shí)間都是GMT的沪猴，這主要是解決在互聯(lián)網(wǎng)上辐啄，不同時(shí)區(qū)在相互請求資源的時(shí)候，時(shí)間混亂問題运嗜。

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

這個(gè)響應(yīng)頭也是跟緩存有關(guān)的壶辜，告訴客戶端在這個(gè)時(shí)間前，可以直接訪問緩存副本担租，很顯然這個(gè)值會存在問題砸民，因?yàn)榭蛻舳撕头?wù)器的時(shí)間不一定會都是相同的，如果時(shí)間不同就會導(dǎo)致問題奋救。所以這個(gè)響應(yīng)頭是沒有Cache-Control：max-age=*這個(gè)響應(yīng)頭準(zhǔn)確的岭参，因?yàn)閙ax-age=date中的date是個(gè)相對時(shí)間，不僅更好理解尝艘，也更準(zhǔn)確演侯。

7. Pragma:no-cache

這個(gè)含義與Cache-Control等同。

8.Server：Tengine/1.4.6

這個(gè)是服務(wù)器和相對應(yīng)的版本背亥，只是告訴客戶端服務(wù)器的信息秒际。

9. Transfer-Encoding：chunked

這個(gè)響應(yīng)頭告訴客戶端，服務(wù)器發(fā)送的資源的方式是分塊發(fā)送的隘梨。一般分塊發(fā)送的資源都是服務(wù)器動(dòng)態(tài)生成的程癌，在發(fā)送時(shí)還不知道發(fā)送資源的大小，所以采用分塊發(fā)送轴猎，每一塊都是獨(dú)立的嵌莉，獨(dú)立的塊都能標(biāo)示自己的長度，最后一塊是0長度的捻脖，當(dāng)客戶端讀到這個(gè)0長度的塊時(shí)锐峭，就可以確定資源已經(jīng)傳輸完了中鼠。

10. Vary: Accept-Encoding

告訴緩存服務(wù)器，緩存壓縮文件和非壓縮文件兩個(gè)版本沿癞，現(xiàn)在這個(gè)字段用處并不大援雇，因?yàn)楝F(xiàn)在的瀏覽器都是支持壓縮的。

響應(yīng)狀態(tài)碼

響應(yīng)狀態(tài)代碼有三位數(shù)字組成椎扬，第一個(gè)數(shù)字定義了響應(yīng)的類別惫搏，且有五種可能取值。

常見狀態(tài)碼：

• 100~199：表示服務(wù)器成功接收部分請求蚕涤，要求客戶端繼續(xù)提交其余請求才能完成整個(gè)處理過程筐赔。

• 200~299：表示服務(wù)器成功接收請求并已完成整個(gè)處理過程。常用200（OK 請求成功）揖铜。

• 300~399：為完成請求茴丰，客戶需進(jìn)一步細(xì)化請求。例如：請求的資源已經(jīng)移動(dòng)一個(gè)新地址天吓、常用302（所請求的頁面已經(jīng)臨時(shí)轉(zhuǎn)移至新的url）贿肩、-307和304（使用緩存資源）。

• 400~499：客戶端的請求有錯(cuò)誤龄寞，常用404（服務(wù)器無法找到被請求的頁面）汰规、403（服務(wù)器拒絕訪問，權(quán)限不夠）物邑。

• 500~599：服務(wù)器端出現(xiàn)錯(cuò)誤控轿，常用500（請求未完成。服務(wù)器遇到不可預(yù)知的情況）拂封。

Cookie 和 Session：

服務(wù)器和客戶端的交互僅限于請求/響應(yīng)過程，結(jié)束之后便斷開鹦蠕，在下一次請求時(shí)冒签，服務(wù)器會認(rèn)為新的客戶端。

為了維護(hù)他們之間的鏈接钟病，讓服務(wù)器知道這是前一個(gè)用戶發(fā)送的請求萧恕，必須在一個(gè)地方保存客戶端的信息。

Cookie：通過在 客戶端 記錄的信息確定用戶的身份肠阱。

Session：通過在 服務(wù)器端 記錄的信息確定用戶的身份票唆。