前言

通常使用的網(wǎng)絡(luò)（包括互聯(lián)網(wǎng)）是在TCP/IP協(xié)議族的基礎(chǔ)上運(yùn)作的。而HTTP屬于它內(nèi)部的一個(gè)子集。在整個(gè)網(wǎng)絡(luò)通行過(guò)程中，先通過(guò)TCP的三次握手建立連接，連接建立后再通過(guò)HTTP進(jìn)行通信，通信完畢后通過(guò)TCP的四次揮手?jǐn)嚅_(kāi)連接。整個(gè)流程如下圖：

一、TCP/IP協(xié)議

計(jì)算機(jī)與網(wǎng)絡(luò)設(shè)備要相互通信，雙方必須基于相同的通信規(guī)則，我們把這種規(guī)則成為協(xié)議。TCP/IP是互聯(lián)網(wǎng)相關(guān)的各類(lèi)協(xié)議族的總稱(chēng)。協(xié)議中存在各式各樣的內(nèi)容，從電纜的規(guī)格到IP地址的選定方法、尋找異地用戶(hù)的方法、雙方建立通信的順序等等。

ARP：ARP（Address Resolution Protocol）地址解析協(xié)議，根據(jù)IP地址獲取物理地址的一個(gè)TCP/IP協(xié)議。主機(jī)發(fā)送信息時(shí)將包含目標(biāo)IP地址的ARP請(qǐng)求廣播到網(wǎng)絡(luò)上的所有主機(jī)，并接收返回消息，以此確定目標(biāo)的物理地址；收到返回消息后將該IP地址和物理地址存入本機(jī)ARP緩存中并保留一定時(shí)間，下次請(qǐng)求時(shí)直接查詢(xún)ARP緩存以節(jié)約資源。

RARP：反向地址轉(zhuǎn)換協(xié)議（RARP：Reverse Address Resolution Protocol） 反向地址轉(zhuǎn)換協(xié)議（RARP）允許局域網(wǎng)的物理機(jī)器從網(wǎng)關(guān)服務(wù)器的 ARP 表或者緩存上請(qǐng)求其 IP 地址。網(wǎng)絡(luò)管理員在局域網(wǎng)網(wǎng)關(guān)路由器里創(chuàng)建一個(gè)表以映射物理地址（MAC）和與其對(duì)應(yīng)的 IP 地址。當(dāng)設(shè)置一臺(tái)新的機(jī)器時(shí)，其 RARP 客戶(hù)機(jī)程序需要向路由器上的 RARP 服務(wù)器請(qǐng)求相應(yīng)的 IP 地址。假設(shè)在路由表中已經(jīng)設(shè)置了一個(gè)記錄，RARP 服務(wù)器將會(huì)返回 IP 地址給機(jī)器，此機(jī)器就會(huì)存儲(chǔ)起來(lái)以便日后使用。

ICMP：ICMP是（Internet Control Message Protocol）Internet控制報(bào)文協(xié)議。它是TCP/IP協(xié)議族的一個(gè)子協(xié)議，用于在IP主機(jī)、路由器之間傳遞控制消息。控制消息是指網(wǎng)絡(luò)通不通、主機(jī)是否可達(dá)、路由是否可用等網(wǎng)絡(luò)本身的消息。這些控制消息雖然并不傳輸用戶(hù)數(shù)據(jù)，但是對(duì)于用戶(hù)數(shù)據(jù)的傳遞起著重要的作用。

1、TCP/IP的分層管理

TCP/IP協(xié)議族里最重要的一點(diǎn)就是分層。TCP/IP協(xié)議族按層次分為4層：應(yīng)用層、傳輸層、網(wǎng)絡(luò)層、鏈路層。

應(yīng)用層：提供應(yīng)用程序網(wǎng)絡(luò)接口；

傳輸層：建立端到端連接；

網(wǎng)絡(luò)層：選址和路由選擇，該層規(guī)定了通過(guò)什么樣的傳輸線(xiàn)路到達(dá)對(duì)方計(jì)算機(jī)，并把數(shù)據(jù)包傳送給對(duì)方；

鏈路層：用來(lái)處理連接網(wǎng)絡(luò)的硬件部，包括控制操作系統(tǒng)、硬件的設(shè)備驅(qū)動(dòng)、NIC(Network Interface Card，網(wǎng)卡)，及光線(xiàn)等物理可見(jiàn)部分，硬件上的范疇均在鏈路層的作用范圍之內(nèi)；

2、TCP/IP通信傳輸流

1、客戶(hù)端在應(yīng)用層發(fā)出一個(gè)HTTP請(qǐng)求；

2、在傳輸層(TCP協(xié)議)把從應(yīng)用層接收到的數(shù)據(jù)(HTTP請(qǐng)求報(bào)文)進(jìn)行分割，并在各個(gè)報(bào)文上打上標(biāo)記序號(hào)及端口號(hào)后傳給網(wǎng)絡(luò)層；

3、在網(wǎng)絡(luò)層(IP協(xié)議)，添加作為通信目的的MAC地址后轉(zhuǎn)發(fā)給鏈路層；(至此，發(fā)往網(wǎng)絡(luò)的通信請(qǐng)求就準(zhǔn)備齊全了)

4、接收端的服務(wù)器在接收到鏈路層的數(shù)據(jù)后，按序往上層發(fā)送并一層一層解析，一直到應(yīng)用層；

發(fā)送端在層與層之間傳輸數(shù)據(jù)時(shí)，每經(jīng)過(guò)一層是必定會(huì)被打上一個(gè)該層所屬的首部信息。反之、接收到層與層傳輸?shù)臄?shù)據(jù)時(shí)，每經(jīng)過(guò)一層會(huì)把對(duì)應(yīng)的首部消去。

3、TCP/IP三次握手

TCP（Transmission Control Protocol）傳輸控制協(xié)議。

為了準(zhǔn)確無(wú)誤地將數(shù)據(jù)送達(dá)目標(biāo)處，TCP協(xié)議采用了三次握手策略，TCP會(huì)向?qū)Ψ酱_認(rèn)發(fā)送出去的數(shù)據(jù)是否成功到達(dá)。握手過(guò)程中使用了TCP的標(biāo)志(flag)，有6種標(biāo)志：

SYN（建立聯(lián)機(jī)）、ACK（確認(rèn)）、PSH（傳送）、FIN（結(jié)束）、RST（重置）、URG（緊急）

Sequence number(順序號(hào)碼)? ? Acknowledge number(確認(rèn)號(hào)碼)

使用 connect() 建立連接時(shí)，客戶(hù)端和服務(wù)器端會(huì)相互發(fā)送三個(gè)數(shù)據(jù)包，請(qǐng)看下圖：

客戶(hù)端調(diào)用 socket() 函數(shù)創(chuàng)建套接字后，因?yàn)闆](méi)有建立連接，所以套接字處于CLOSED狀態(tài)；服務(wù)器端調(diào)用 listen() 函數(shù)后，套接字進(jìn)入LISTEN狀態(tài)，開(kāi)始監(jiān)聽(tīng)客戶(hù)端請(qǐng)求。

這個(gè)時(shí)候，客戶(hù)端開(kāi)始發(fā)起請(qǐng)求：

1) 當(dāng)客戶(hù)端調(diào)用 connect() 函數(shù)后，TCP協(xié)議會(huì)組建一個(gè)數(shù)據(jù)包，并設(shè)置 SYN 標(biāo)志位，表示該數(shù)據(jù)包是用來(lái)建立同步連接的。同時(shí)生成一個(gè)隨機(jī)數(shù)字 1000，填充“序號(hào)（Seq）”字段，表示該數(shù)據(jù)包的序號(hào)。完成這些工作，開(kāi)始向服務(wù)器端發(fā)送數(shù)據(jù)包，客戶(hù)端就進(jìn)入了SYN-SEND狀態(tài)。

2) 服務(wù)器端收到數(shù)據(jù)包，檢測(cè)到已經(jīng)設(shè)置了 SYN 標(biāo)志位，就知道這是客戶(hù)端發(fā)來(lái)的建立連接的“請(qǐng)求包”。服務(wù)器端也會(huì)組建一個(gè)數(shù)據(jù)包，并設(shè)置 SYN 和 ACK 標(biāo)志位，SYN 表示該數(shù)據(jù)包用來(lái)建立連接，ACK 用來(lái)確認(rèn)收到了剛才客戶(hù)端發(fā)送的數(shù)據(jù)包。

服務(wù)器生成一個(gè)隨機(jī)數(shù) 2000，填充“序號(hào)（Seq）”字段。2000 和客戶(hù)端數(shù)據(jù)包沒(méi)有關(guān)系。

服務(wù)器將客戶(hù)端數(shù)據(jù)包序號(hào)（1000）加1，得到1001，并用這個(gè)數(shù)字填充“確認(rèn)號(hào)（Ack）”字段。

服務(wù)器將數(shù)據(jù)包發(fā)出，進(jìn)入SYN-RECV狀態(tài)。

3) 客戶(hù)端收到數(shù)據(jù)包，檢測(cè)到已經(jīng)設(shè)置了 SYN 和 ACK 標(biāo)志位，就知道這是服務(wù)器發(fā)來(lái)的“確認(rèn)包”。客戶(hù)端會(huì)檢測(cè)“確認(rèn)號(hào)（Ack）”字段，看它的值是否為 1000+1，如果是就說(shuō)明連接建立成功。

接下來(lái)，客戶(hù)端會(huì)繼續(xù)組建數(shù)據(jù)包，并設(shè)置 ACK 標(biāo)志位，表示客戶(hù)端正確接收了服務(wù)器發(fā)來(lái)的“確認(rèn)包”。同時(shí)，將剛才服務(wù)器發(fā)來(lái)的數(shù)據(jù)包序號(hào)（2000）加1，得到 2001，并用這個(gè)數(shù)字來(lái)填充“確認(rèn)號(hào)（Ack）”字段。

客戶(hù)端將數(shù)據(jù)包發(fā)出，進(jìn)入ESTABLISED狀態(tài)，表示連接已經(jīng)成功建立。

4) 服務(wù)器端收到數(shù)據(jù)包，檢測(cè)到已經(jīng)設(shè)置了 ACK 標(biāo)志位，就知道這是客戶(hù)端發(fā)來(lái)的“確認(rèn)包”。服務(wù)器會(huì)檢測(cè)“確認(rèn)號(hào)（Ack）”字段，看它的值是否為 2000+1，如果是就說(shuō)明連接建立成功，服務(wù)器進(jìn)入ESTABLISED狀態(tài)。

至此，客戶(hù)端和服務(wù)器都進(jìn)入了ESTABLISED狀態(tài)，連接建立成功，接下來(lái)就可以收發(fā)數(shù)據(jù)了。

最后說(shuō)明：三次握手的關(guān)鍵是要確認(rèn)對(duì)方收到了自己的數(shù)據(jù)包，這個(gè)目標(biāo)就是通過(guò)“確認(rèn)號(hào)（Ack）”字段實(shí)現(xiàn)的。計(jì)算機(jī)會(huì)記錄下自己發(fā)送的數(shù)據(jù)包序號(hào) Seq，待收到對(duì)方的數(shù)據(jù)包后，檢測(cè)“確認(rèn)號(hào)（Ack）”字段，看Ack = Seq + 1是否成立，如果成立說(shuō)明對(duì)方正確收到了自己的數(shù)據(jù)包。

思考：為什么要三次握手呢，兩次握手不就可以了嗎？

客戶(hù)端發(fā)送了第一個(gè)連接的請(qǐng)求報(bào)文，但是由于網(wǎng)絡(luò)不好，這個(gè)請(qǐng)求沒(méi)有立即到達(dá)服務(wù)端，而是在某個(gè)網(wǎng)絡(luò)節(jié)點(diǎn)中滯留了，直到某個(gè)時(shí)間才到達(dá)服務(wù)端，本來(lái)這已經(jīng)是一個(gè)失效的報(bào)文，但是服務(wù)端接收到這個(gè)請(qǐng)求報(bào)文后，還是會(huì)向客戶(hù)端發(fā)出確認(rèn)的報(bào)文，表示同意連接。假如不采用三次握手，那么只要服務(wù)端發(fā)出確認(rèn)，新的連接就建立了，但其實(shí)這個(gè)請(qǐng)求是失效的請(qǐng)求，客戶(hù)端是不會(huì)理睬服務(wù)端的確認(rèn)信息，也不會(huì)向服務(wù)端發(fā)送確認(rèn)的請(qǐng)求，但是服務(wù)端認(rèn)為新的連接已經(jīng)建立起來(lái)了，并一直等待客戶(hù)端發(fā)來(lái)數(shù)據(jù)，這樣，服務(wù)端的很多資源就沒(méi)白白浪費(fèi)掉了，采用三次握手就是為了防止這種情況的發(fā)生，服務(wù)端會(huì)因?yàn)槭詹坏酱_認(rèn)的報(bào)文，就知道客戶(hù)端并沒(méi)有建立連接。這就是三次握手的作用。

4、TCP/IP四次揮手

下圖演示了客戶(hù)端主動(dòng)斷開(kāi)連接的場(chǎng)景：

建立連接后，客戶(hù)端和服務(wù)器都處于ESTABLISED狀態(tài)。這時(shí)，客戶(hù)端發(fā)起斷開(kāi)連接的請(qǐng)求：

1) 客戶(hù)端調(diào)用 close() 函數(shù)后，向服務(wù)器發(fā)送 FIN 數(shù)據(jù)包，進(jìn)入FIN_WAIT_1狀態(tài)。FIN 是 Finish 的縮寫(xiě)，表示完成任務(wù)需要斷開(kāi)連接。

2) 服務(wù)器收到數(shù)據(jù)包后，檢測(cè)到設(shè)置了 FIN 標(biāo)志位，知道要斷開(kāi)連接，于是向客戶(hù)端發(fā)送“確認(rèn)包”，進(jìn)入CLOSE_WAIT狀態(tài)。

注意：服務(wù)器收到請(qǐng)求后并不是立即斷開(kāi)連接，而是先向客戶(hù)端發(fā)送“確認(rèn)包”，告訴它我知道了，我需要準(zhǔn)備一下才能斷開(kāi)連接。

3) 客戶(hù)端收到“確認(rèn)包”后進(jìn)入FIN_WAIT_2狀態(tài)，等待服務(wù)器準(zhǔn)備完畢后再次發(fā)送數(shù)據(jù)包。

4) 等待片刻后，服務(wù)器準(zhǔn)備完畢，可以斷開(kāi)連接，于是再主動(dòng)向客戶(hù)端發(fā)送 FIN 包，告訴它我準(zhǔn)備好了，斷開(kāi)連接吧。然后進(jìn)入LAST_ACK狀態(tài)。

5) 客戶(hù)端收到服務(wù)器的 FIN 包后，再向服務(wù)器發(fā)送 ACK 包，告訴它你斷開(kāi)連接吧。然后進(jìn)入TIME_WAIT狀態(tài)。

6) 服務(wù)器收到客戶(hù)端的 ACK 包后，就斷開(kāi)連接，關(guān)閉套接字，進(jìn)入CLOSED狀態(tài)。

思考：那么為什么是4次揮手呢？

可能有人會(huì)有疑問(wèn)，TCP我握手的時(shí)候?yàn)楹蜛CK(確認(rèn))和SYN(建立連接)是一起發(fā)送。揮手的時(shí)候?yàn)槭裁词欠珠_(kāi)的時(shí)候發(fā)送呢.因?yàn)榻⑦B接時(shí)，當(dāng)服務(wù)端收到客戶(hù)端的SYN連接請(qǐng)求報(bào)文后，可以直接發(fā)送SYN+ACK報(bào)文。其中ACK報(bào)文是用來(lái)應(yīng)答的，SYN報(bào)文是用來(lái)同步的。但是關(guān)閉連接時(shí)，當(dāng)服務(wù)端收到FIN報(bào)文時(shí)，很可能并不會(huì)立即關(guān)閉SOCKET，所以只能先回復(fù)一個(gè)ACK報(bào)文，告訴客戶(hù)端，"你發(fā)的FIN報(bào)文我收到了"。只有等到我服務(wù)端所有的報(bào)文都發(fā)送完了，才能發(fā)送FIN報(bào)文，因此不能一起發(fā)送。故需要四步握手。

二、負(fù)責(zé)域名解析的DNS服務(wù)

DNS（Domain Name System）域名系統(tǒng)，作為域名和IP地址相互映射的一個(gè)分布式數(shù)據(jù)庫(kù)。它提供通過(guò)域名查找IP地址，或逆向從IP地址反查域名的服務(wù)，使用戶(hù)更方便的訪(fǎng)問(wèn)互聯(lián)網(wǎng)。DNS協(xié)議運(yùn)行在UDP（User Datagram Protocol ）用戶(hù)數(shù)據(jù)報(bào)協(xié)議之上，使用端口號(hào)53。和HTTP協(xié)議一樣也是位于應(yīng)用層的協(xié)議。

三、使用Cookie的狀態(tài)管理

1、關(guān)于Cookie

HTTP是無(wú)狀態(tài)協(xié)議。

優(yōu)點(diǎn)：由于不必保留狀態(tài)，自然可減少服務(wù)器的CPU及內(nèi)存資源的消耗；

缺點(diǎn)：它不對(duì)之前發(fā)生過(guò)的請(qǐng)求和響應(yīng)的狀態(tài)進(jìn)行管理。也就是說(shuō)，無(wú)法根據(jù)之前的狀態(tài)進(jìn)行本次的請(qǐng)求處理。

假設(shè)要求登錄認(rèn)證的web頁(yè)面本身無(wú)法進(jìn)行狀態(tài)管理（不記錄登錄狀態(tài)），那么每次跳轉(zhuǎn)新頁(yè)面不是要再次登錄，就是要在每次請(qǐng)求報(bào)文中附加參數(shù)來(lái)管理登錄狀態(tài)。要想保留無(wú)狀態(tài)協(xié)議特征的同時(shí)，又要解決類(lèi)似的矛盾問(wèn)題，于是引入了Cookie技術(shù)。Cookie技術(shù)通過(guò)在請(qǐng)求和響應(yīng)報(bào)文中寫(xiě)入Cookie信息來(lái)控制客戶(hù)端的狀態(tài)。

Cookie會(huì)根據(jù)從服務(wù)器發(fā)送的響應(yīng)報(bào)文內(nèi)的一個(gè)叫做Set-Cookie的首部字段信息，通知客戶(hù)端保存Cookie。當(dāng)下一次客戶(hù)端在往該服務(wù)器發(fā)送請(qǐng)求時(shí)，客戶(hù)端會(huì)自動(dòng)在請(qǐng)求報(bào)文中加入Cookie值后發(fā)送出去。

服務(wù)端發(fā)現(xiàn)客戶(hù)端發(fā)送過(guò)來(lái)的Cookie后，會(huì)去檢查究竟是從哪個(gè)客戶(hù)端發(fā)送過(guò)來(lái)的請(qǐng)求，然后對(duì)比服務(wù)器上的記錄，最后得到之前的狀態(tài)信息。

2、為Cookie服務(wù)的首部字段

expires屬性：Cookie的有效期（若不明確指定，則默認(rèn)為瀏覽器關(guān)閉前為止）

path屬性：將服務(wù)器上的文件目錄作為Cookie的適用對(duì)象（若不指定，則默認(rèn)為文檔所在的文件目錄）

domain屬性：作為Cookie適用對(duì)象的域名（若不指定，則默認(rèn)為創(chuàng)建Cookie的服務(wù)器的域名）

secure屬性：僅在HTTPS安全通信時(shí)才會(huì)發(fā)送Cookie

HttpOnly屬性：加以限制，使Cookie不能被JavaScript腳本訪(fǎng)問(wèn)

四、HTTP協(xié)議

1、HTTP協(xié)議進(jìn)化史

HTTP 0.9

HTTP于1990年問(wèn)世。那時(shí)的HTTP并沒(méi)有作為正式的標(biāo)準(zhǔn)被建立。現(xiàn)在的HTTP其實(shí)含有HTTP 1.0之前版本的意思，因此被稱(chēng)為HTTP 0.9。HTTP 0.9作為HTTP協(xié)議的第一個(gè)版本，是非常弱的。請(qǐng)求(Request)只有一行，比如：GET www.baidu.com

如此簡(jiǎn)單的請(qǐng)求體，沒(méi)有POST方法，沒(méi)有HTTP請(qǐng)求頭，并且，如果得不到所求的信息也不會(huì)報(bào)404 500等錯(cuò)誤。那個(gè)時(shí)代的HTTP客戶(hù)端只能接收純文本類(lèi)型。雖然HTTP 0.9看起來(lái)如此弱，但已經(jīng)能滿(mǎn)足那個(gè)時(shí)代的需求了。

HTTP 1.0

HTTP正式作為標(biāo)準(zhǔn)被公布是在1996年5月，版本命名為HTTP 1.0。HTTP 1.0最大的改變是引入了POST方法，使得客戶(hù)端可以向服務(wù)器發(fā)送數(shù)據(jù)。另一個(gè)重大的改變是引入了HTTP頭，使得HTTP不僅能返回錯(cuò)誤代碼，并且HTTP協(xié)議所傳輸?shù)膬?nèi)容不僅限于純文本，還可以是圖片、動(dòng)畫(huà)等一系列格式。除此之外，還允許保持連接，即一次TCP連接后，可以多次通信，雖然HTTP 1.0默認(rèn)是傳輸一次數(shù)據(jù)后就關(guān)閉。

HTTP 1.1

1997年1月發(fā)布的HTTP 1.1版本是目前主流的HTTP協(xié)議版本。HTTP 1.1并不像HTTP 1.0對(duì)于HTTP 0.9那樣的革命性。但也有很多增強(qiáng)。

默認(rèn)持久連接；

增加了Host頭，比如：

GET /Careyson HTTP/1.1

Host: www.imooc.com

Get后面僅僅需要相對(duì)路徑即可。這個(gè)提升使得在Web上的一臺(tái)主機(jī)可以存在多個(gè)域。否則多個(gè)域名指向同一個(gè)IP會(huì)產(chǎn)生混淆。

此外，還引入了Range頭，使得客戶(hù)端通過(guò)HTTP下載時(shí)只下載內(nèi)容的一部分，這使得線(xiàn)程下載成為可能。

另外，HTTP 1.1默認(rèn)連接是一致保持的。

HTTP 2.0

HTTP 2.0在2013年8月進(jìn)行首次合作共事性測(cè)試。HTTP 2.0采用二進(jìn)制格式而非文本格式。HTTP 2.0的目的是通過(guò)支持請(qǐng)求與響應(yīng)的多路復(fù)用來(lái)減少延遲，通過(guò)壓縮HTTPS首部字段將協(xié)議開(kāi)銷(xiāo)降低，同時(shí)增加請(qǐng)求優(yōu)先級(jí)和服務(wù)器端對(duì)推送功能的支持。

2、HTTP簡(jiǎn)介

1、HTTP協(xié)議（Hypertext transfer protocol 超文本傳輸協(xié)議）是一個(gè)基于請(qǐng)求與響應(yīng)模式的、無(wú)狀態(tài)的、應(yīng)用層的協(xié)議。默認(rèn)端口號(hào)為8080，HTTPS端口號(hào)為443；

2、HTTP協(xié)議承載于TCP協(xié)議之上，或者承載于SSL或TLS協(xié)議層之上（即HTTPS），如下圖：

3、HTTP協(xié)議簡(jiǎn)單，客戶(hù)向服務(wù)器請(qǐng)求服務(wù)時(shí)，只需傳送請(qǐng)求方法和路徑。因此，HTTP服務(wù)器的程序規(guī)模小，通信速度很快。

4、HTTP協(xié)議允許傳輸任意類(lèi)型的數(shù)據(jù)對(duì)象，正在傳輸?shù)念?lèi)型由Content-Type字段標(biāo)記；

3、HTTP之請(qǐng)求消息Request

1、關(guān)于URI（統(tǒng)一資源標(biāo)識(shí)符）

URI就是由某個(gè)協(xié)議方案表示的資源的定位標(biāo)識(shí)符。協(xié)議方案是指訪(fǎng)問(wèn)資源所使用的協(xié)議類(lèi)型名稱(chēng)。

http://host[":"port][abs_path]

http表示要通過(guò)HTTP協(xié)議來(lái)定位網(wǎng)絡(luò)資源；

host表示合法的Internet主機(jī)域名或者IP地址；

port指定一個(gè)端口號(hào)，為空則使用缺省端口80；

abs_path指定請(qǐng)求資源的URI；如果URL中沒(méi)有給出abs_path，那么當(dāng)它作為請(qǐng)求URI時(shí)，必須以“/”的形式給出

例如：

2、HTTP請(qǐng)求方法：

GET請(qǐng)求：獲取資源（瀏覽網(wǎng)頁(yè)、下載應(yīng)用、觀看視頻等）

POST請(qǐng)求：傳輸實(shí)體的主體（提交登錄信息、上傳文件到公有云等）

PUT請(qǐng)求：傳輸文件（鑒于HTTP 1.1的PUT方法自身不帶驗(yàn)證機(jī)制，任何人都可以上傳文件，存在安全性問(wèn)題，因此一般不使用該方法）

HEAD請(qǐng)求：獲得報(bào)文首部（和GET方法一樣，但不返回報(bào)文主體，用于確認(rèn)URI的有效性、資源更新日期、獲取文件大小、做可用性探測(cè)等）

DELETE請(qǐng)求：刪除文件（HTTP 1.1的DELETE方法和PUT方法一樣不帶驗(yàn)證機(jī)制，所以一般不使用該方法）

OPTIONS請(qǐng)求：用來(lái)查詢(xún)請(qǐng)求URI資源時(shí)，服務(wù)器支持的方法（返回服務(wù)器支持的方法）

TRACE請(qǐng)求：追蹤路徑（發(fā)送請(qǐng)求時(shí)，在Max-Forwards首部字段中填入數(shù)值，每經(jīng)過(guò)一個(gè)服務(wù)器就將該數(shù)字減1，當(dāng)數(shù)值剛好減到0時(shí)，就停止繼續(xù)傳輸，最后接受請(qǐng)求的服務(wù)器返回200 OK響應(yīng)?？蛻?hù)端通過(guò)TRACE方法可以查詢(xún)發(fā)送出去的請(qǐng)求是怎么被加工修/篡改的。TRACE方法容易引起跨站追蹤攻擊，所以一般不會(huì)用）

3、請(qǐng)求報(bào)文結(jié)構(gòu)：

Host：請(qǐng)求資源所在的服務(wù)器（HTTP 1.1版本添加的字段。當(dāng)多臺(tái)虛擬主機(jī)運(yùn)行在同一個(gè)IP上時(shí)，用Host加以區(qū)分）

User-Agent：HTTP客戶(hù)端程序的信息（User-Agent會(huì)將創(chuàng)建請(qǐng)求的瀏覽器和用戶(hù)代理的名稱(chēng)等信息傳給服務(wù)器）

Accept：可接受的媒體類(lèi)型

Accept-Language：接受的語(yǔ)言（如：en-us;q=0.7 表示美式英語(yǔ)，q是優(yōu)先級(jí)權(quán)重值，在0-1.0之間，1優(yōu)先級(jí)最高，不寫(xiě)q值則使用默認(rèn)優(yōu)先級(jí)1）

Accept-Encoding：接受的編碼

DNT：禁止追蹤（Do Not Track），1代表用戶(hù)不想被第三方網(wǎng)站追蹤，0代表接受追蹤，null代表用戶(hù)不置可否

Connection：Keep-Alive 持久連接

Pragma：要求所有的中間服務(wù)器不返回緩存的資源（Pragma是HTTP 1.1之前版本的歷史遺留字段，僅作為與HTTP 1.0的向后兼容而定義）

Cache-Control：no-cache 要求所有的中間服務(wù)器不返回緩存的資源（HTTP 1.1版本的字段，由于要整體掌握全部中間服務(wù)器使用的HTTP版本是不現(xiàn)實(shí)的，所以，發(fā)送請(qǐng)求會(huì)同時(shí)含有Pragma和Cache-Control字段）

Via：代理服務(wù)器的相關(guān)信息（列出從客戶(hù)端到源服務(wù)器經(jīng)過(guò)了哪些代理服務(wù)器，他們用什么協(xié)議（和版本）發(fā)送的請(qǐng)求。當(dāng)客戶(hù)端請(qǐng)求到達(dá)第一個(gè)代理服務(wù)器時(shí)，該服務(wù)器會(huì)在自己發(fā)出的請(qǐng)求里面添加 Via 頭部，并填上自己的相關(guān)信息，當(dāng)下一個(gè)代理服務(wù)器收到第一個(gè)代理服務(wù)器的請(qǐng)求時(shí)，會(huì)在自己發(fā)出的請(qǐng)求里面復(fù)制前一個(gè)代理服務(wù)器的請(qǐng)求的Via部，并把自己的相關(guān)信息加到后面，以此類(lèi)推，當(dāng)源服務(wù)器收到最后一個(gè)代理服務(wù)器的請(qǐng)求時(shí)，檢查 Via 頭部，就知道該請(qǐng)求所經(jīng)過(guò)的路由）

If-Match：比較實(shí)體標(biāo)記ETag（只有當(dāng)If-Match的字段值跟ETag值匹配一致時(shí)，服務(wù)器才會(huì)接受請(qǐng)求）

If-Modified-Since：比較資源的更新時(shí)間（如果在If-Modified-Since字段指定日期時(shí)間后，資源發(fā)生了更新，服務(wù)器會(huì)接受請(qǐng)求）

Refere：只要查看Refere就能知道請(qǐng)求的URI是從哪個(gè)web頁(yè)面發(fā)起的

通用首部字段：

請(qǐng)求首部字段：

4、HTTP之響應(yīng)消息Response

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

2xx：成功

200：請(qǐng)求成功

204：該狀態(tài)碼表示服務(wù)器接收的請(qǐng)求已成功處理，但在返回的響應(yīng)報(bào)文中不含實(shí)體的主體部分（一般只在需要從客戶(hù)端往服務(wù)器發(fā)送信息，而對(duì)客戶(hù)端不需要發(fā)送新信息內(nèi)容的情況下使用）

206：該狀態(tài)碼表示客戶(hù)端進(jìn)行了范圍請(qǐng)求，而服務(wù)器成功執(zhí)行了這部分GET請(qǐng)求。響應(yīng)報(bào)文中包含由Content-Range指定范圍的實(shí)體內(nèi)容。

3xx：重定向

301：永久性重定向

302：臨時(shí)重定向

304：文件未更新

4xx：客戶(hù)端錯(cuò)誤

401：該狀態(tài)碼表示發(fā)送的請(qǐng)求需要有通過(guò)HTTP認(rèn)證的認(rèn)證信息。另外若之前已進(jìn)行1次請(qǐng)求了，則表示用戶(hù)認(rèn)證失敗。

403：該狀態(tài)碼表明對(duì)請(qǐng)求資源的訪(fǎng)問(wèn)被服務(wù)器拒絕了。

404：該狀態(tài)嗎表明服務(wù)器上無(wú)法找到請(qǐng)求的資源。

5xx：服務(wù)器錯(cuò)誤

500：該狀態(tài)碼表明服務(wù)器在執(zhí)行請(qǐng)求時(shí)發(fā)生了錯(cuò)誤。

502：執(zhí)行請(qǐng)求時(shí)，從上游服務(wù)器接收到無(wú)效的響應(yīng)

503：該狀態(tài)碼表明服務(wù)器暫時(shí)處于超負(fù)載或正在進(jìn)行停機(jī)維護(hù)，現(xiàn)在無(wú)法處理請(qǐng)求

504：執(zhí)行請(qǐng)求時(shí)，未能及時(shí)從上游服務(wù)器或者輔助服務(wù)器（例如DNS）收到響應(yīng)

2、響應(yīng)報(bào)文結(jié)構(gòu)：

Date：日期和時(shí)間

Server：服務(wù)器上安裝的HTTP服務(wù)器應(yīng)用程序信息（軟件名稱(chēng)、版本號(hào)、啟用時(shí)間等）

Last-Modified：資源的最后修改日期和時(shí)間

ETag：實(shí)體標(biāo)識(shí)（服務(wù)器為每一份資源分配對(duì)應(yīng)的ETag值，將資源以字符串形式做唯一性標(biāo)識(shí)的方式，資源更新時(shí)，ETag值也需要更新）

Accept-Ranges：告知客戶(hù)端服務(wù)器是否能處理范圍請(qǐng)求（bytes：可以處理范圍請(qǐng)求；none：服務(wù)器不能處理范圍請(qǐng)求）

Content-Length：表明實(shí)體主體部分的大小（單位是字節(jié)）

Connection：keep-alive 或 close? 開(kāi)啟或關(guān)閉HTTP持久連接

Content-Type：實(shí)體主體的媒體類(lèi)型

Vary：代理服務(wù)器緩存的管理信息

Content-Range：bytes 5001-10000/10000? 告知客戶(hù)端響應(yīng)返回的實(shí)體范圍

Content-Length：實(shí)體主體部分的大?。▎挝皇亲止?jié)）

Content-Encoding：實(shí)體的主體部分適用的編碼方式

響應(yīng)首部字段：

實(shí)體首部字段：

5、HTTP的缺點(diǎn)

1、明文通信（不加密），可能遭竊聽(tīng)；

2、不驗(yàn)證通信方身份，可能遭偽裝；

3、無(wú)法證明報(bào)文完整性，可能遭篡改；

為了解決以上這些問(wèn)題，需要在HTTP上再加入加密處理和認(rèn)證等機(jī)制。我們把添加了加密機(jī)認(rèn)證機(jī)制的HTTP稱(chēng)為HTTPS。

五、HTTPS

1、關(guān)于HTTPS

1、HTTP + 加密 + 認(rèn)證 + 完整性保護(hù) = HTTPS

2、HTTPS是身披SSL外殼的HTTP

HTTPS并非是應(yīng)用層的一種新協(xié)議。只是HTTP通信接口部分用SSL（Secure Socket Layer 安全套接層）和TLS（Transport Layer Security? 傳輸層安全性協(xié)議）協(xié)議代替而已。

通常，HTTP直接和TCP通信。當(dāng)使用SSL時(shí)，則演變成先和SSL通信，再由SSL和TCP通信。采用SSL后，HTTP就有了加密、證書(shū)校驗(yàn)和數(shù)據(jù)完整性保護(hù)等功能。

2、HTTPS的加密方式

1、非對(duì)稱(chēng)加密

非對(duì)稱(chēng)加密算法需要兩個(gè)密鑰：公鑰（publickey）和私鑰（privatekey）。公鑰與私鑰是一對(duì)，如果用公鑰對(duì)數(shù)據(jù)進(jìn)行加密，只有用對(duì)應(yīng)的私鑰才能解密；如果用私鑰對(duì)數(shù)據(jù)進(jìn)行加密，那么只有用對(duì)應(yīng)的公鑰才能解密。因?yàn)榧用芎徒饷苁褂玫氖莾蓚€(gè)不同的密鑰，所以這種算法叫作非對(duì)稱(chēng)加密算法。 非對(duì)稱(chēng)加密算法實(shí)現(xiàn)機(jī)密信息交換的基本過(guò)程是：甲方生成一對(duì)秘鑰并將其中的公鑰向其它方公開(kāi)；得到該公鑰的乙方使用該公鑰對(duì)機(jī)密信息進(jìn)行加密后再發(fā)送給甲方；甲方再用自己保存的私鑰對(duì)加密后的信息進(jìn)行解密。

非對(duì)稱(chēng)加密的優(yōu)點(diǎn)：算法強(qiáng)度復(fù)雜、而使得加密解密速度沒(méi)有對(duì)稱(chēng)加密解密的速度快。

2、對(duì)稱(chēng)加密

只有一把秘鑰，采用單秘鑰加密方法，同一個(gè)秘鑰可用于信息的加解密。

對(duì)稱(chēng)加密的優(yōu)點(diǎn)：加密速度快、加密效率高。

3、HTTPS的混合加密機(jī)制

HTTTPS采用非對(duì)稱(chēng)加密和對(duì)稱(chēng)加密并用的混合加密機(jī)制。非對(duì)稱(chēng)加密主要用于交換對(duì)稱(chēng)加密的秘鑰。即在交換秘鑰環(huán)節(jié)使用非對(duì)稱(chēng)加密，之后的建立通信交換報(bào)文階段則使用對(duì)稱(chēng)加密方式。這樣充分利用了兩種加密方式各自的優(yōu)勢(shì)。

3、證明服務(wù)器頒發(fā)的公鑰正確性的證書(shū)

1、CA證書(shū)的生成過(guò)程

公開(kāi)秘鑰加密方式還是存在一些問(wèn)題的。那就是無(wú)法證明公鑰本身就是貨真價(jià)實(shí)的公開(kāi)秘鑰?？赡懿皇穷A(yù)想的那臺(tái)服務(wù)器發(fā)行的公鑰，可能傳輸中被攻擊者調(diào)包了等等。

為了解決上述問(wèn)題，可以使用由數(shù)字證書(shū)認(rèn)證機(jī)構(gòu)（CA，Certificate Authority）和其相關(guān)機(jī)關(guān)頒發(fā)的公開(kāi)秘鑰證書(shū)。數(shù)字證書(shū)認(rèn)證機(jī)構(gòu)處于客戶(hù)端與服務(wù)器雙方都可信賴(lài)的第三方機(jī)構(gòu)的立場(chǎng)上。其業(yè)務(wù)流程如下：

1、服務(wù)端的運(yùn)營(yíng)人員向數(shù)字證書(shū)認(rèn)證機(jī)構(gòu)提出公開(kāi)秘鑰的申請(qǐng)；

2、數(shù)字證書(shū)認(rèn)證機(jī)構(gòu)在判明提出申請(qǐng)者的身份之后，會(huì)對(duì)已申請(qǐng)的公開(kāi)秘鑰做數(shù)字簽名，然后分配這個(gè)已簽名的公開(kāi)秘鑰，并將該公開(kāi)秘鑰放入公鑰證書(shū)后綁定一起；

3、服務(wù)器會(huì)將這份由數(shù)字證書(shū)認(rèn)證機(jī)構(gòu)頒發(fā)的公鑰證書(shū)發(fā)送給客戶(hù)端，用于非對(duì)稱(chēng)加密方式通信；

4、接到數(shù)字證書(shū)的客戶(hù)端使用數(shù)字證書(shū)認(rèn)證機(jī)構(gòu)的公開(kāi)秘鑰，對(duì)那張證書(shū)上的數(shù)字簽名進(jìn)行驗(yàn)證，一旦驗(yàn)證通過(guò)，客戶(hù)端便可明確兩件事：1、認(rèn)證服務(wù)器的公開(kāi)秘鑰是真實(shí)有效的數(shù)字證書(shū)認(rèn)證機(jī)構(gòu)；2、服務(wù)器的公鑰是值得信賴(lài)的；

此處認(rèn)證機(jī)關(guān)的公開(kāi)秘鑰必須安全地轉(zhuǎn)移到客戶(hù)端。使用通信方式時(shí)，如何安全轉(zhuǎn)交是一件很困難的事，因此，多數(shù)瀏覽器開(kāi)發(fā)商發(fā)布版本時(shí)，會(huì)事先在內(nèi)部植入常用認(rèn)證機(jī)關(guān)的認(rèn)證證書(shū)。

2、CA證書(shū)一般會(huì)包含以下內(nèi)容：

1、證書(shū)的頒發(fā)機(jī)構(gòu)、版本；

2、證書(shū)的使用者；

3、證書(shū)的公鑰；

4、證書(shū)的有效時(shí)間；

5、證書(shū)的數(shù)字簽名Hash值和簽名Hash算法

3、客戶(hù)端如何校驗(yàn)CA證書(shū)

CA證書(shū)中的Hash值，其實(shí)是用證書(shū)的私鑰進(jìn)行加密后的值（證書(shū)的私鑰不在CA證書(shū)中）。然后客戶(hù)端得到證書(shū)后，利用證書(shū)中的公鑰去解密該Hash值，得到Hash-a；然后再利用證書(shū)內(nèi)的簽名Hash算法去生成一個(gè)Hash-b。最后比較Hash-a和Hash-b這兩個(gè)的值。如果相等，那么證明了該證書(shū)是對(duì)的，服務(wù)端是可以被信任的；如果不相等，那么就說(shuō)明該證書(shū)是錯(cuò)誤的，可能被篡改了，瀏覽器會(huì)給出相關(guān)提示，無(wú)法建立起HTTPS連接。除此之外，還會(huì)校驗(yàn) CA 證書(shū)的有效時(shí)間和域名匹配等。

4、HTTPS 中的 SSL 握手建立過(guò)程

1、客戶(hù)端通過(guò)發(fā)送ClientHello報(bào)文開(kāi)始SSL通信。報(bào)文中包含客戶(hù)端支持的SSL版本、加密組件列表（所使用的加密算法及秘鑰長(zhǎng)度等）；

2、服務(wù)端可進(jìn)行SSL通信時(shí)，會(huì)以ServerHello報(bào)文作為應(yīng)答。和客戶(hù)端一樣，在報(bào)文中包含SSL版本及加密組件。服務(wù)器的加密組件內(nèi)容是從接收到的客戶(hù)端加密組件內(nèi)篩選出來(lái)的；

3、之后服務(wù)器發(fā)送Certificate報(bào)文。報(bào)文中包含公開(kāi)秘鑰證書(shū)；

4、最后服務(wù)器發(fā)送ServerHelloDone報(bào)文，通知客戶(hù)端，最初階段的SSL握手協(xié)商部分結(jié)束；

5、SSL第一次握手結(jié)束之后，客戶(hù)端以ClientKeyExchange報(bào)文作為回應(yīng)。報(bào)文中包含通信加密中使用的一種被稱(chēng)為Pre-master secret的隨機(jī)密碼串。該報(bào)文已用步驟3中的公開(kāi)秘鑰進(jìn)行加密；

6、接著客戶(hù)端繼續(xù)發(fā)生Change Cipher Spec報(bào)文。該報(bào)文會(huì)提示服務(wù)器，在此報(bào)文之后的通信會(huì)采用Pre-master secret秘鑰加密；

7、客戶(hù)端發(fā)送Finished報(bào)文。該報(bào)文包含連接至今全部報(bào)文的整體校驗(yàn)值。這次握手協(xié)商是否能夠成功，要以服務(wù)器是否能夠正確解碼該報(bào)文作為判定標(biāo)準(zhǔn)；

8、服務(wù)器同樣發(fā)送Change Cipher Spec報(bào)文；

9、服務(wù)器同樣發(fā)送Finished報(bào)文；

10、服務(wù)器和客戶(hù)端的Finished報(bào)文交換完畢后，SSL連接就算建立完成。之后的通信會(huì)受到SSL保護(hù)。從此處開(kāi)始進(jìn)行應(yīng)用層協(xié)議的通信，即發(fā)送HTTP請(qǐng)求；

11、應(yīng)用層協(xié)議通信，即發(fā)送HTTP響應(yīng)；

12、最后由客戶(hù)端斷開(kāi)連接。斷開(kāi)連接時(shí)，發(fā)送close_notify報(bào)文。上圖做了一些省略，這步之后再發(fā)送TCP FIN報(bào)文來(lái)關(guān)閉與TCP的通信；

以上流程中，應(yīng)用層發(fā)送數(shù)據(jù)是會(huì)附加一種叫做MAC（Message Authentication Code）的報(bào)文摘要。MAC能夠查知報(bào)文是否遭篡改，從而保護(hù)報(bào)文的完整性。

下面是對(duì)整個(gè)流程的圖解。圖中說(shuō)明了使用服務(wù)器的公開(kāi)秘鑰證書(shū)建立HTTPS通信的整個(gè)過(guò)程。

六、通信數(shù)據(jù)轉(zhuǎn)發(fā)程序：代理、網(wǎng)關(guān)、隧道

HTTP通信時(shí)，除客戶(hù)端和服務(wù)器外，還有一些用于通信數(shù)據(jù)轉(zhuǎn)發(fā)的應(yīng)用程序，如：代理、網(wǎng)關(guān)、隧道。它們配合服務(wù)器工作。這些應(yīng)用程序和服務(wù)器可以將請(qǐng)求轉(zhuǎn)發(fā)給通信線(xiàn)路上的下一站服務(wù)器，并且能接收從那臺(tái)服務(wù)器發(fā)送的響應(yīng)再轉(zhuǎn)發(fā)給客戶(hù)端。

1、代理

代理是一種有轉(zhuǎn)發(fā)功能的應(yīng)用程序，它扮演了位于服務(wù)器與客戶(hù)端“中間人”的角色，接收客戶(hù)端發(fā)送的請(qǐng)求并轉(zhuǎn)發(fā)給服務(wù)器，同時(shí)也接收服務(wù)器返回的響應(yīng)并轉(zhuǎn)發(fā)給客戶(hù)端。

使用代理的理由有：利用緩存技術(shù)減少網(wǎng)絡(luò)帶寬的流量，組織內(nèi)部針對(duì)特定網(wǎng)站的訪(fǎng)問(wèn)控制，以獲取訪(fǎng)問(wèn)日志為主要目的等等。

代理分為緩存代理和透明代理

緩存代理：代理轉(zhuǎn)發(fā)響應(yīng)時(shí)，緩存代理會(huì)預(yù)先將資源的副本（緩存）保存在代理服務(wù)器上。當(dāng)代理再次接收到相同資源的請(qǐng)求時(shí)，就可以不從源服務(wù)器那里獲取資源，而是將之前緩存的資源作為響應(yīng)。

透明代理：轉(zhuǎn)發(fā)請(qǐng)求或響應(yīng)時(shí)，不對(duì)報(bào)文做任何加工的代理類(lèi)型被稱(chēng)為透明代理。反之，對(duì)報(bào)文內(nèi)容進(jìn)行加工的代理稱(chēng)為非透明代理。

2、網(wǎng)關(guān)

網(wǎng)關(guān)是轉(zhuǎn)發(fā)其他服務(wù)器通信數(shù)據(jù)的服務(wù)器，接收從客戶(hù)端發(fā)送的請(qǐng)求時(shí)，它就像自己擁有資源一樣對(duì)請(qǐng)求進(jìn)行處理。有時(shí)客戶(hù)端可能都察覺(jué)不到，自己的通信目標(biāo)是一個(gè)網(wǎng)關(guān)。網(wǎng)關(guān)能使通信線(xiàn)路上的服務(wù)器提供非HTTP協(xié)議服務(wù)。

利用網(wǎng)關(guān)能提高通信的安全性，因?yàn)榭梢栽诳蛻?hù)端和彎管之間的通信線(xiàn)路上加密以確保連接的安全。比如：在web購(gòu)物網(wǎng)站上進(jìn)行信用卡結(jié)算時(shí)，網(wǎng)關(guān)可以和信用卡結(jié)算系統(tǒng)聯(lián)動(dòng)。

3、隧道

隧道是在相隔甚遠(yuǎn)的客戶(hù)端和服務(wù)器兩者之間進(jìn)行中轉(zhuǎn)，并保持雙方通信連接的應(yīng)用程序。隧道可以按要求建立一條與其他服務(wù)器的通信線(xiàn)路，屆時(shí)使用SSL等加密手段進(jìn)行通信。隧道的目的是確?？蛻?hù)端與服務(wù)器進(jìn)行安全的通信。隧道本身不去解析HTTP請(qǐng)求。也就是說(shuō)請(qǐng)求保持原樣中轉(zhuǎn)給之后的服務(wù)器。隧道會(huì)在通信雙方斷開(kāi)連接時(shí)結(jié)束。

八、HTTP CONNECT通道

1、關(guān)于CONNECT

為了確保數(shù)據(jù)通信的安全，瀏覽器與源服務(wù)器之間是通過(guò)HTTPS加密通信的。代理服務(wù)器自身無(wú)法讀取通信內(nèi)容。然而當(dāng)瀏覽器需要通過(guò)代理服務(wù)器發(fā)起HTTPS請(qǐng)求時(shí)，由于請(qǐng)求的站點(diǎn)地址和端口號(hào)都保存于HTTPS請(qǐng)求頭中，代理服務(wù)器是如何既確保通信是加密的又知道該往哪里發(fā)送請(qǐng)求呢？

為了解決這個(gè)問(wèn)題，瀏覽器需要先通過(guò)明文HTTP形式向代理服務(wù)器發(fā)送一個(gè)CONNECT請(qǐng)求告訴它目標(biāo)站點(diǎn)地址及端口號(hào)。當(dāng)代理服務(wù)器收到這個(gè)請(qǐng)求后，會(huì)在對(duì)應(yīng)的端口上與目標(biāo)站點(diǎn)建立一個(gè)TCP連接，連接建立成功后返回一個(gè)HTTP 200狀態(tài)碼告訴瀏覽器與該站點(diǎn)的加密通道已建成（此時(shí)的狀態(tài)碼雖然是200，但狀態(tài)碼信息不是OK ，而是Connection Established）。接下來(lái)進(jìn)行通信時(shí)，代理服務(wù)器僅僅是以中轉(zhuǎn)的角色來(lái)回傳輸瀏覽器與該服務(wù)器之間的加密數(shù)據(jù)包，并不對(duì)數(shù)據(jù)包進(jìn)行解密，以保證HTTPS加密通信的安全性。

2、CONNECT通道建立流程

1、瀏覽器向代理服務(wù)器發(fā)送CONNECT請(qǐng)求：

2、代理服務(wù)器返回HTTP 200狀態(tài)臺(tái)碼表示連接已建立：

與普通的HTTP響應(yīng)不同的是，這個(gè)響應(yīng)不需要包含Content-Type首部。此時(shí)連接的是對(duì)原始字節(jié)進(jìn)行轉(zhuǎn)接，不在是報(bào)文的承載者，所以不需要使用內(nèi)容類(lèi)型。

3、瀏覽器和服務(wù)器開(kāi)始HTTPS握手并交換加密數(shù)據(jù)，代理服務(wù)器只負(fù)責(zé)傳輸彼此的數(shù)據(jù)包，并不能讀取具體數(shù)據(jù)內(nèi)容。從Wireshark抓包中可以看出，在第12貞HTTP/1.0 200返回后，瀏覽器和服務(wù)器開(kāi)始進(jìn)行SSL握手。

九、隧道（tunnel）

1、介紹

用戶(hù)使用隧道方式，可以通過(guò)HTTP應(yīng)用程序訪(fǎng)問(wèn)使用非HTTP協(xié)議的應(yīng)用程序。這樣就可以在HTTP上捎帶其他協(xié)議數(shù)據(jù)。

2、用途

隧道的常見(jiàn)用途是通過(guò)HTTP連接承載安全套接層的加密數(shù)據(jù)流，這樣SSL數(shù)據(jù)流就可以穿過(guò)只允許web數(shù)據(jù)流通過(guò)的防火墻。

例如：隧道收到一條HTTP請(qǐng)求，要求建立一條到目標(biāo)地址和端口的輸出連接，然后在HTTP信道上通過(guò)隧道傳輸加密的SSL數(shù)據(jù)流，這樣就可以將其盲轉(zhuǎn)發(fā)到目標(biāo)服務(wù)器上。

3、隧道分為不使用CONNECT的隧道和使用CONNECT的隧道?

1.不使用CONNECT的隧道

代理服務(wù)器收到客戶(hù)端的HTTP請(qǐng)求后，會(huì)重新創(chuàng)建Request請(qǐng)求，并發(fā)送到目標(biāo)服務(wù)器。當(dāng)目標(biāo)服務(wù)器返回Response給代理后，代理會(huì)對(duì)Response進(jìn)行解析，然后重裝Response發(fā)給客戶(hù)端。

可以看出，在不使用CONNECT的情況下，代理服務(wù)器完全可以對(duì)數(shù)據(jù)進(jìn)行修改，而且還有一個(gè)弊端是代理HTTPS時(shí)，代理服務(wù)器由于沒(méi)有密鑰因此無(wú)法解密，從而無(wú)法實(shí)現(xiàn)數(shù)據(jù)包的重組與轉(zhuǎn)發(fā)。

2、使用CONNECT的隧道

客戶(hù)端向代理發(fā)起CONNECT時(shí)，就是告訴代理，先在代理和目標(biāo)服務(wù)器之間建立起連接，在連接建立后，目標(biāo)服務(wù)器會(huì)返回一個(gè)響應(yīng)給代理，代理創(chuàng)建并返回一個(gè)連接就緒的報(bào)文給客戶(hù)端。（狀態(tài)碼為200，狀態(tài)碼信息為Connection Established）。在此之后，客戶(hù)端跟目標(biāo)服務(wù)器的所有通信將使用之前建立起來(lái)的連接進(jìn)行通信。

在這種情況下的隧道，代理僅僅實(shí)現(xiàn)盲轉(zhuǎn)發(fā)，而不會(huì)去關(guān)心轉(zhuǎn)發(fā)的數(shù)據(jù)。

4、CONNECT建立一條SSL隧道的流程

1、圖中a，客戶(hù)端發(fā)送一條CONNECT請(qǐng)求給隧道網(wǎng)關(guān)。客戶(hù)端的CONNECT方法請(qǐng)求隧道網(wǎng)關(guān)打開(kāi)一條TCP連接（在這里打開(kāi)的是到主機(jī)orders.joes-hardware.com的標(biāo)準(zhǔn)SSL端口443的鏈接）；

2、圖中b和c創(chuàng)建TCP連接；

3、一旦建立了TCP連接，網(wǎng)關(guān)就會(huì)發(fā)送一條HTTP 200 Connection Established響應(yīng)來(lái)通知客戶(hù)端（如圖d）；

4、此時(shí)，隧道就建立起來(lái)了?？蛻?hù)端通過(guò)HTTP隧道發(fā)送的所有數(shù)據(jù)都會(huì)被直接轉(zhuǎn)發(fā)給輸出TCP連接，服務(wù)器發(fā)送的所有數(shù)據(jù)都會(huì)通過(guò)HTTP隧道轉(zhuǎn)發(fā)給客戶(hù)端；