• 1.OkHttp源碼解析(一):OKHttp初階
• 2 OkHttp源碼解析(二):OkHttp連接的"前戲"——HTTP的那些事
• 3 OkHttp源碼解析(三):OKHttp中階之線程池和消息隊列
• 4 OkHttp源碼解析(四):OKHttp中階之?dāng)r截器及調(diào)用鏈
• 5 OkHttp源碼解析(五):OKHttp中階之OKio簡介
• 6 OkHttp源碼解析(六):OKHttp中階之緩存基礎(chǔ)
• 7 OkHttp源碼解析(七):OKHttp中階之緩存機制
• 8 OkHttp源碼解析(八):OKHttp中階之連接與請求值前奏
• 9 OkHttp源碼解析(九):OKHTTP連接中三個"核心"RealConnection、ConnectionPool、StreamAllocation
• 10 OkHttp源碼解析(十) OKHTTP中連接與請求
• 11 OkHttp的感謝

本篇文章為OkHttp的"前戲"篇，主要講解關(guān)于http協(xié)議的一些基礎(chǔ)知識泪勒。主要內(nèi)容如下：

• 1棕兼、TCP
• 2、TCP的3次握手和4次揮手
• 3、HTTPS
• 4茎芋、SPDY
• 5败徊、HTTP2.0
• 6煤杀、隧道
• 7酌儒、代理
• 8忌怎、InetAddress和InetSocketAddress

一、TCP

關(guān)于TCP的具體鸥印，我這里就不細(xì)說，如這是我們每個程序員的基本知識潜的，我這里就簡單說下疏咐，看下OSI的七層模型：

osi.png

我們知道TCP工作在第四層Transport層(傳輸層)，IP在第三層Network層(網(wǎng)絡(luò)層)酌壕，ARP在第二層Data Link層(數(shù)據(jù)鏈路層)；在第二層上的數(shù)據(jù)糊昙，我們把她叫做Frame，在第三層上的數(shù)據(jù)叫Packet没咙，第四層的數(shù)據(jù)叫Segment。并且，我們需要知道捉捅，數(shù)據(jù)從應(yīng)用層發(fā)下來，會在每一層都加上頭部信息陌凳，進行封裝，然后再發(fā)送到數(shù)據(jù)接收端充岛。這個基本的流程你需要知道夜只，就是每個數(shù)據(jù)都會經(jīng)過數(shù)據(jù)的封裝和解封裝的過程。在OSI七層模型中，每一層的作用對應(yīng)的協(xié)議如下：

協(xié)議.png

TCP是一個協(xié)議粘茄，那這個協(xié)議是如何定義的，它的數(shù)據(jù)格式是什么樣子的师妙？那就要進行更深層次的剖析怔檩，就需要了解，甚至是熟記TCP協(xié)議中的每個字段的含義乙埃，如下圖：

tcp.png

上面就是TCP協(xié)議頭部的格式，由于它太重要了，所以下面就將每個字段的信息都詳細(xì)說明下

• Source Port和Destination Port:分別占用16位鸠珠，表示源端口號和目的端口號炬太；用于區(qū)別主機中的不同進程，IP地址用來區(qū)分不同主機的，源端口號和目的端口號配合上IP首部中的源IP地址就能確定為一個TCP連接
• Sequenece Number:用來標(biāo)識從TCP發(fā)送端向TCP接收端的數(shù)據(jù)字節(jié)流女气，他表示在這個報文中的第一個數(shù)據(jù)字節(jié)流在數(shù)據(jù)流中的序號；主要用來解決網(wǎng)絡(luò)亂序的問題。
• Acknowledgment Number：32位確認(rèn)序號包發(fā)送確認(rèn)的一端所期望收到的下一個序號霎肯，因此，確認(rèn)需要應(yīng)該是上次已成功收到數(shù)據(jù)字節(jié)序號+1，不過只有當(dāng)標(biāo)志位中的ACK標(biāo)志(下面介紹)為1時該確認(rèn)序列號的字段才有效。主要用來解決不丟包的問題工碾。
• Offset:給出首部中32bit字的數(shù)目，需要這個值是因為任選字段的長度是可變的焦读。這個字段占4bit(最多能表示15個32bit的字，即4*15=60個字節(jié)的首部長度)张症，因此TCP最多有60個字節(jié)的首部。然而，沒有任選字段，正常的長度是20字節(jié)畏铆。
• TCP Flags:TCP首部中有6個比特，它們總的多個可同時被設(shè)置為1，主要是用于操控TCP的狀態(tài)機，依次為URG，ACK，PSH上荡，RST叁征，SYN，F(xiàn)IN。
• Window:窗口大小，也就是有名的滑動窗口醇锚，用來進行流量控制；這是一個復(fù)雜的問題

TCP是主機對主機層的傳輸控制協(xié)議，提供可靠的連接服務(wù)，采用三次握手確認(rèn)建立一個連接:位碼即tcp標(biāo)志位,有6種標(biāo)示:SYN(synchronous建立聯(lián)機) ACK(acknowledgement 確認(rèn)) PSH(push傳送) FIN(finish結(jié)束) RST(reset重置) URG(urgent緊急)Sequence number(順序號碼) Acknowledge number(確認(rèn)號碼)
現(xiàn)在來介紹一下這些的標(biāo)志位：

• URG:次標(biāo)志表示TCP包的緊急指針域(后面馬上就要說到)有效，用來保證TCP連接不被中斷凸主，并督促中間層設(shè)備要盡快處理這些數(shù)據(jù)。
• ACK:此標(biāo)志表示應(yīng)答域有效，就是說前面所說的TCP的應(yīng)答將會包含在TCP數(shù)據(jù)包中；有兩個取值：0和1婆咸，為1的時候表示應(yīng)答域有效，反之為0憾儒。
• PSH:這個標(biāo)志位表示Push操作警儒。所謂Push操作就是是在數(shù)據(jù)包到達接受端以后边琉，立即傳送給應(yīng)用程序，而不是在緩沖區(qū)排隊。
• RST:這個標(biāo)志位表示連接復(fù)位請求砍鸠。用來復(fù)位哪些產(chǎn)生錯誤的鏈接耍属，也被用來拒絕錯誤和非法的數(shù)據(jù)包。
• SYN:表示同步序號，用來建立連接舍咖。SYN標(biāo)志位和ACK標(biāo)志位搭配使用，當(dāng)連接請求的時候，SYN=1，ACK=0浪谴；連接被響應(yīng)的時候扶檐，SYN=1官卡，ACK=1颈嚼。這個標(biāo)志的數(shù)據(jù)包常常被用來進行端口掃描叫挟。掃描者發(fā)送一個只有SYN的數(shù)據(jù)包，如果對方主機響應(yīng)了一個數(shù)據(jù)包回來健霹，就表明這臺主機存在這個端口窃这，但是由于這種掃描只是進行TCP三次握手的第一次握手祟敛，因此這種掃描的成功表明被掃描的機器很不安全痪宰，一臺安全的主機將會強制要求一個連接嚴(yán)格的進行TCP的三次握手乖订。
• FIN:表示發(fā)送端已經(jīng)達到數(shù)據(jù)末尾扛点，也就是說雙方數(shù)據(jù)傳送完成，沒有數(shù)據(jù)可以傳送了，發(fā)送FIN標(biāo)志位的TCP數(shù)據(jù)包后，連接將斷開召娜。這個表示的數(shù)據(jù)包也經(jīng)常被用于進行端口掃描胁后。

講完標(biāo)志位后就要開始正式的連接。

二、TCP3次握手和4次揮手

(一)、3次握手

TCP是面向連接的彼棍，無論哪一方向另一方發(fā)送數(shù)據(jù)之前涕蜂，都必須現(xiàn)在雙方之間建立一條連接。在TCP/IP協(xié)議中，TCP協(xié)議提供可靠的連接服務(wù)，連接是通過三次握手進行初始化的年局。三次握手的目的是同步連接雙方的序列號和確認(rèn)號并交換TCP窗口大小的信息际看。這就是面試中經(jīng)常被問到的TCP三次握手。那咱們就詳細(xì)的了解下矢否，看圖述說：

image.png

多么清晰的一張圖啊，可惜不是我的僵朗，我"借"來的

• 1赖欣、第一次握手:建立連接屑彻，客戶端先發(fā)送連接請求報文佛寿，將SYN位置為1艰猬，Sequence Number為X;然后，客戶端進入SYN+SEND狀態(tài)纺铭，等待服務(wù)器的確認(rèn)悴了；
• 2搏恤、第二次握手：服務(wù)器收到SYN報文。服務(wù)器收到客戶端的SYN報文湃交，需要對這個SYN報文進行確認(rèn)熟空，設(shè)置Acknowledgment Number為x+1(Sequence+1)；同時搞莺，自己還要送法SYN消息息罗，將SYN位置為1，Sequence Number為y才沧；服務(wù)器將上述所有信息放到一個報文段(即SYN+ACK報文段)中迈喉，一并發(fā)送給客戶端，此時服務(wù)器進入SYN+RECV狀態(tài)糜工。
• 3弊添、第三次握手；客戶端收到服務(wù)器的 SYN+ACK報文段捌木。然后將Acknowlegment Number設(shè)為y+1,向服務(wù)器發(fā)送ACK報文段油坝，這個報文段發(fā)送完畢后，客戶端端服務(wù)器都進入ESTABLISHED狀態(tài)刨裆，完成TCP三次握手澈圈。

實例:

• IP 192.168.1.116.3337 > 192.168.1.123.7788: S 3626544836
  第一次握手：192.168.1.116發(fā)送位碼syn＝1,隨機產(chǎn)生seq number=3626544836的數(shù)據(jù)包到192.168.1.123,由SYN=1知道192.168.1.116要求建立聯(lián)機;
• IP 192.168.1.123.7788 > 192.168.1.116.3337: S 1739326486: ack 3626544837
  第二次握手：192.168.1.123收到請求后要確認(rèn)聯(lián)機信息，向192.168.1.116發(fā)送ack number=3626544837,syn=1,ack=1,隨機產(chǎn)生seq=1739326486的包;
• IP 192.168.1.116.3337 > 192.168.1.123.7788: ack 1739326487,ack 1
  第三次握手：192.168.1.116收到后檢查ack number是否正確帆啃，即第一次發(fā)送的seq number+1,以及位碼ack是否為1瞬女，若正確，192.168.1.116會再發(fā)送ack number=1739326487,ack=1努潘，192.168.1.123收到后確認(rèn)seq=seq+1,ack=1則連接建立成功诽偷。

完成了三次握手，客戶端和服務(wù)器就可以開始傳送數(shù)據(jù)了疯坤，以上就是TCP三次握手的總體介紹报慕。

(二)、4次回?fù)]手

當(dāng)客戶端和服務(wù)器進行三次握手簡歷TCP連接以后压怠，當(dāng)數(shù)據(jù)傳送完畢眠冈，肯定要斷開TCP連接。那對于TCP的斷開菌瘫，就是"4次揮手"蜗顽。

• 1布卡、客戶端(也可以是服務(wù)器)，設(shè)置Sequence Number和Acknowledgment Number雇盖，向服務(wù)器發(fā)送一個FIN報文段忿等。此時客戶端進入FIN_WAIT_1狀態(tài)；這表示客戶端沒有數(shù)據(jù)發(fā)送給主機了刊懈。
• 2这弧、服務(wù)器收到客戶端發(fā)來的FIN報文段，向客戶端回一個ACK報文段虚汛，Acknowledgement Number為Sequence Number加1；客戶端進入FIN_WAIT_2狀態(tài)皇帮，服務(wù)器進入CLOSE_WAIT狀態(tài)卷哩；服務(wù)器告訴客戶端，我同意你的"關(guān)閉"請求属拾。
• 3将谊、服務(wù)器向客戶端發(fā)送FIN報文段，請求關(guān)閉連接渐白，同時服務(wù)器進入LAST_ACK狀態(tài)尊浓。
• 4、客戶端收到服務(wù)器發(fā)送的FIN報文段纯衍，向主機發(fā)送ACK報文段栋齿，然后客戶端進入TIME_WAIT狀態(tài)，服務(wù)器收到客戶端的ACK報文段以后襟诸，就關(guān)閉連接瓦堵，此時，客戶端等待2MSL后一次沒有到收到回復(fù)歌亲，則證明Server端已正常關(guān)閉菇用，那好，客戶端也可以關(guān)閉連接了陷揪。

至此惋鸥，TCP的四次分手就完成了。

為了讓大家更好的理解3次握手和4次揮手悍缠，我準(zhǔn)備了幾道問題卦绣，讓大家更好的理解3次握手和4次揮手。

1扮休、為什么握手要“3”次迎卤？

一般同學(xué)會認(rèn)為，握手為什么要3次玷坠，感覺2次就可以了蜗搔。在謝希仁的<計算機網(wǎng)絡(luò)>中是這樣說的

為了防止已失效的連接請求報文段突然又傳送到了服務(wù)端劲藐，因而產(chǎn)生錯誤。

在書中同時舉了一個例子樟凄，如下:

“已失效的連接請求報文段”的產(chǎn)生在這樣一種情況下：client發(fā)出的第一個連接請求報文段并沒有丟失聘芜，而是在某個網(wǎng)絡(luò)結(jié)點長時間的滯留了，以致延誤到連接釋放以后的某個時間才到達server缝龄。本來這是一個早已失效的報文段汰现。但server收到此失效的連接請求報文段后，就誤認(rèn)為是client再次發(fā)出的一個新的連接請求叔壤。于是就向client發(fā)出確認(rèn)報文段瞎饲，同意建立連接。假設(shè)不采用“三次握手”炼绘，那么只要server發(fā)出確認(rèn)嗅战，新的連接就建立了。由于現(xiàn)在client并沒有發(fā)出建立連接的請求俺亮，因此不會理睬server的確認(rèn)驮捍，也不會向server發(fā)送數(shù)據(jù)。但server卻以為新的運輸連接已經(jīng)建立脚曾，并一直等待client發(fā)來數(shù)據(jù)东且。這樣，server的很多資源就白白浪費掉了本讥。采用“三次握手”的辦法可以防止上述現(xiàn)象發(fā)生珊泳。例如剛才那種情況，client不會向server的確認(rèn)發(fā)出確認(rèn)囤踩。server由于收不到確認(rèn)旨椒，就知道client并沒有要求建立連接《率”

這就很明白了综慎，防止了服務(wù)器端的一直等待而浪費資源

2、為什么握手要“3”次勤庐，而揮手要"4"次?

TCP協(xié)議是一種面向連接的示惊、可靠的、基于字節(jié)流的運輸層通信協(xié)議愉镰。TCP是全雙工模式米罚，這就意味著，當(dāng)客戶端發(fā)起FIN報文段時丈探，只表示客戶端已經(jīng)已經(jīng)沒有數(shù)據(jù)要發(fā)送了录择，客戶端告訴服務(wù)器，它的數(shù)據(jù)已經(jīng)全部發(fā)送完畢了，但是此時客戶端還是可以接受服務(wù)器的數(shù)據(jù)隘竭；當(dāng)服務(wù)器返回ACK報文段是時塘秦，表示它已經(jīng)知道客戶端沒有數(shù)據(jù)發(fā)送了，但是服務(wù)器還是可以發(fā)送數(shù)據(jù)到客戶端动看；當(dāng)服務(wù)器也發(fā)送了FIN報文時尊剔，這時候就是表示服務(wù)器也沒有數(shù)據(jù)要發(fā)送給客戶端了，之后就可以愉快地中斷這次TCP連接菱皆。

為了讓大家更好的地理解四次揮手的原理须误，我們再講解下四次揮手的狀態(tài)：

• 1、FIN_WAIT_1:這個狀態(tài)要好好解釋一下仇轻，其實FIN_WAIT_1和FIN_WAIT_2狀態(tài)的真正含義都是表示等待對方的FIN報文京痢。而這兩種狀態(tài)的區(qū)別：FIN_WAIT_1狀態(tài)實際上是當(dāng)SOCKET在ESTABLISHED狀態(tài)時，它想主動關(guān)閉連接拯田，向?qū)Ψ桨l(fā)送了FIN報文历造，此時該SOCKET即進入FIN_WAIT_1狀態(tài)。而當(dāng)對方回應(yīng)ACK報文后船庇，則進入FIN_WAIT_2狀態(tài)，當(dāng)然在實際的正常情況下侣监，無論對方何種情況下鸭轮，都應(yīng)該馬上回應(yīng)ACK報文，所以FIN_WAIT_1狀態(tài)一般是比較難見到的橄霉，而FIN_WAIT_2狀態(tài)還有時常城砸可看到。
• 2姓蜂、FIN_WAIT_2:上面已經(jīng)詳細(xì)解釋了這種狀態(tài)按厘，實際上 FIN_WAIT_2狀態(tài)下的SOCKET，表示半連接钱慢，既有一方要求close連接逮京，但另外還告訴對方，我暫時還有點數(shù)據(jù)需要傳送給你(ACK信息)束莫，稍后再關(guān)閉連接
• 3懒棉、CLOSE_WAIT_2:這種狀態(tài)的含義其實表示在等待關(guān)閉。怎么理解览绿？當(dāng)對方close一個SOCKET后發(fā)送一個FIN報文給自己策严，服務(wù)器系統(tǒng)毫無疑問會回應(yīng)一個ACK報文給對方，此時則進入到CLOSE_WAIT狀態(tài)饿敲。接下來呢妻导，實際上你真正需要考慮的事情是查看你是否還有數(shù)據(jù)發(fā)送給對方，如果沒有的話，那么你也就可以close這個這個SOCKET倔韭，發(fā)送FIN報文給對方术浪，也即關(guān)閉連接。所以你在CLOSE_WAIT狀態(tài)下狐肢，需要完成的事情是等待你去關(guān)閉連接添吗。
• 4、LAST_ACK:這個狀態(tài)還是比較容易好理解的份名，它是被動關(guān)閉一方在發(fā)送FIN報文后碟联，最后等待對方的ACK報文。當(dāng)收到ACK報文后僵腺，也可以進入CLOSED狀態(tài)了鲤孵。
• 5、CLOSED:表示連接中斷
• 6辰如、TIME_WAIT:表示收到對方的FIN報文普监，并發(fā)出了ACK報文就等2MSL后即可會到CLOSED可用狀態(tài)了。如果FIN_WAIT_1下琉兜，收到了對方同時帶FIN標(biāo)志和ACK標(biāo)志的報文時凯正，可以直接進入到TIME_WAIT狀態(tài)，而無須經(jīng)過FIN_WAIT_2狀態(tài)豌蟋。

3廊散、為什么TIME_WAIT狀態(tài)需要經(jīng)過2MSL(最大報文段生存時間)才能返回到CLOSE狀態(tài)？

雖然按道理梧疲，四個報文都發(fā)送完畢允睹，我們可以直接進入CLOSE狀態(tài)了，但是我們必須假設(shè)網(wǎng)絡(luò)是不可靠的幌氮，一切都可能發(fā)生缭受，比如有可能最后一個ACK丟失。所以TIME_WAIT狀態(tài)是用來重發(fā)可能丟失的ACK報文该互。

三米者、HTTPS

(一)、什么是HTTPS?

HTTPS(Hypertext Transfer Protocol over Secure Socket Layer/基于安全套接字層的超文本傳輸協(xié)議,或者也可以說HTTP OVER SSL)是網(wǎng)景公司開發(fā)的web協(xié)議慢洋。SSL的版本最高為3.0塘雳，后來的版本被稱為TLS，現(xiàn)在所用的協(xié)議版本一般都是TLS普筹，但是由于SSL出現(xiàn)的時間比較早败明，所以現(xiàn)在一般指的SSL一般也就是TLS，本文中后面都統(tǒng)一使用SSL來代替TLS太防。HTTPS是以安全為目標(biāo)的HTT通道妻顶，簡單講就是HTTP的安全版酸员，所以你可以理解HTTPS=HTTP+SSL。即HTTP下加入SSL層讳嘱，HTTPS的安全基礎(chǔ)是SSL幔嗦，因此加密的詳細(xì)內(nèi)容是SSL。

(二)沥潭、為什么要用HTTPS?

在沒有HTTPS之前使用HTTP的協(xié)議的邀泉，可見HTTPS肯定是彌補的HTTP的安全缺陷，那么咱們來看下HTTP協(xié)議的那些安全缺點：
1钝鸽、通信使用明文(不加密)汇恤，內(nèi)容可能被竊聽(抓包工具可以獲取請求和響應(yīng)內(nèi)容)如下圖：

缺陷1.png

2、不驗證通訊方的身分拔恰，任何人都坑你發(fā)送請求因谎，不管對方是誰都返回相應(yīng)，如下圖：

缺陷2.png

3颜懊、無法證明報文的完整性财岔，可能會遭到篡改，即沒有辦法確認(rèn)發(fā)出的請求/相應(yīng)前后一致河爹。

缺陷3.png

所以為了解決上述問題匠璧，需要在HTTP上加入加密處理和認(rèn)證機制，我們把添加了加密和認(rèn)證機制的http稱之為http咸这。即HTTP+加密+認(rèn)證+完成性保護=HTTPS患朱。
這里先簡單的說下HTTPS說下他的優(yōu)勢：

• 1、內(nèi)容加密炊苫，建立一個信息的安全通道，來保證數(shù)據(jù)傳輸過程的安全性冰沙。
• 2侨艾、身份認(rèn)證，確認(rèn)網(wǎng)站的真是性拓挥。
• 3唠梨、數(shù)據(jù)完整性，防止內(nèi)容被第三方冒充或者篡改侥啤。

是不是 剛好彌補了上面的缺陷当叭。。盖灸。蚁鳖。
補充一下:HTTPS并非應(yīng)用層的一種新協(xié)議，只是HTTP通訊接口部分用SSL(secure socket layer)和TLS(transport layer security)協(xié)議代替赁炎，通常HTTP直接和TCP通信時醉箕，當(dāng)使用SSL時，則演變成先和SSL通信，再由SSL和TCP通訊讥裤，因此所以HTTPS其實就是身披SSL保護外衣的HTTP

(三)放棒、HTTPS的缺點

上帝給你關(guān)上一道門 同時給你打開一扇窗，所以萬事萬物都是各有利弊己英，那么HTTPS的缺點是什么那?
由于要對數(shù)據(jù)進行加密间螟，認(rèn)證，所以注定他會比HTTP慢损肛，當(dāng)然現(xiàn)在也有很多優(yōu)化厢破。
對數(shù)據(jù)進行加解密決定了它比http慢。
PS:處于安全考慮荧关，瀏覽器是不會再本地保存HTTPS緩存溉奕。實際上，只要在HTTP頭中使用特定的命令忍啤，HTTPS是可以被緩存的加勤。Firefox默認(rèn)只在內(nèi)存中緩存HTTS。但是同波，只要在請求頭中有Cache-Control:Public鳄梅，緩存就會被寫到磁盤上，IE只要http頭允許就可以緩存https內(nèi)容未檩，緩存策略與是否使用HTTPS協(xié)議無關(guān)戴尸。

(四)、HTTP與HTTPS的相同和異同點

1冤狡、HTTP與HTTPS的相同點：
大多數(shù)情況下孙蒙，HTTP和HTTPS是相同的，因此都采用同一個基礎(chǔ)協(xié)議悲雳，作為HTTP或者HTTPS客戶端--瀏覽器/app等挎峦，設(shè)置一個連接到web服務(wù)器指定的寬口。當(dāng)服務(wù)器接收到請求合瓢，它會返回一個狀態(tài)碼以及消息坦胶，這個回應(yīng)可能是請求信息、或者指示某個錯誤發(fā)送的錯誤信息晴楔。系統(tǒng)使用統(tǒng)一資源定位符URI顿苇，因此資源可以被唯一指定。在表面上HTTPS和HTTP唯一不同的只是一個協(xié)議頭HTTPS的說明税弃，其他都一樣纪岁。

2、HTTP與HTTPS的不同點：

• 1钙皮、HTTPS需要用到CA申請證書蜂科。
• 2顽决、HTTP是超文本傳輸協(xié)議，信息是明文的导匣；HTTPS則是具有安全性的SSL加密傳輸協(xié)議才菠。
• 3、HTTPS和HTTP使用的是完全不同的連接方式贡定，用的端口也不一樣赋访，HTTP是80,HTTPS是443。
• 4缓待、HTTP的連接很簡單蚓耽，是無狀態(tài)的，HTTPS是HTTP+SSL協(xié)議構(gòu)建的旋炒，可進行加密傳輸步悠、身份認(rèn)證的網(wǎng)絡(luò)協(xié)議，比HTTP協(xié)議安全瘫镇。

(五)鼎兽、簡單說點加密和證書的事

再詳細(xì)說HTTPS之前先來了解下加密和證書的事情

1、加密

加密的2種技術(shù)：

• 1铣除、對稱加密(也叫私鑰加密)谚咬，是指加密和解密使用相同的密鑰的加密算法。有時又叫傳統(tǒng)加密算法尚粘，就是加密密鑰能夠從解密密鑰中推算出來择卦，同時解密密鑰也可以從加密密鑰中推算出來。而在大多數(shù)的對稱算法中郎嫁，加密密鑰和解密密鑰是相同的秉继，所以也稱這種加密算法為秘密密鑰或者單密鑰算法，常見的對稱加密有DES(Data Encryption Standard)泽铛、AES(Advanced Encryption Standard)秕噪、RC4、IDEA。
• 2戴涝、非對稱加密掸鹅，是指和甲酸算法不同，非對稱加密算法有兩個密鑰：公開密鑰(public key）和私有密鑰(private key)森缠；并且加密密鑰和解密密鑰是成對出現(xiàn)的。非對稱加密算法在加密和解密過程使用了不同的密鑰，非對稱加密也稱公鑰加密撵幽，在密鑰對中，其中一個密鑰是對外公開的礁击，所有都可以獲取到盐杂，稱為公鑰逗载，其中一個密鑰是不公開的稱為私鑰。非對稱加密算法對加密內(nèi)容的長度有限制链烈，不能超過公鑰長度厉斟。常見的非對稱加密RSA、DSA/DSS等强衡。

2擦秽、數(shù)字摘要

數(shù)字摘要是采用單項Hash函數(shù)將需要加密的明文"摘要"成一串固定長度(128位)的密文，這一串密文又稱為數(shù)字指紋漩勤，它有固定的長度感挥，而且不同的明文摘要成密文，其結(jié)果總是不同的越败，而同樣的明文摘要必定一定触幼。“數(shù)字摘要”是https能確保數(shù)據(jù)完整性和防篡改的根本原因究飞。常用的摘要主要有MD5置谦、SHA1、SHA256等噪猾。

3霉祸、數(shù)字簽名

數(shù)字簽名技術(shù)就是對"非對稱密鑰加解密"和"數(shù)字摘要"兩項技術(shù)的應(yīng)用，它將摘要信息用發(fā)送者的私鑰加密袱蜡，與原文一起傳送給接受者丝蹭。接受者只有用發(fā)送者的公鑰才能解密被加密的摘要信息，然后用HASH函數(shù)對收到的原因產(chǎn)生一個摘要信息坪蚁，與解密的摘要信息對比奔穿。如果相同，則說明收到的信息是完整的敏晤，在傳輸?shù)倪^程中沒有被修改贱田，否則說明信息被修改過，因此數(shù)字簽名能夠驗證信息的完整性嘴脾。
數(shù)字簽名的過程：

明文——>hash運算——>摘要——>私鑰加密——>數(shù)字簽名

數(shù)字簽名的兩種功效：

• 1男摧、能確定消息確實由發(fā)送方簽名并發(fā)出來的，因為別人假冒不了發(fā)送方的簽名译打。
• 2耗拓、數(shù)字簽名能確定消息的完整性。

注意:
數(shù)字簽名只能驗證數(shù)據(jù)的完整性奏司，數(shù)據(jù)本身是否加密不屬于數(shù)字簽名的控制范圍

4乔询、數(shù)字證書

對于請求方來說，它怎么能確定它所得到的公鑰一定是從目標(biāo)主機哪里發(fā)送的韵洋，
而且沒有被篡改過呢?亦或者請求的目標(biāo)主機本身就是從事竊取用戶信息的不正當(dāng)行為呢竿刁？這時候黄锤，我們需要一個權(quán)威的值得信賴的第三方機構(gòu)(一般是由政府機構(gòu)審核并授權(quán)的機構(gòu))來統(tǒng)一對外發(fā)送主機機構(gòu)的公鑰，只要請求方這種機構(gòu)獲取公鑰食拜，就避免了上述問題

(1)數(shù)字證書的頒發(fā)過程:
用戶首先產(chǎn)生自己的密鑰對鸵熟，并將公共密鑰及部分個人身份信息傳送給認(rèn)證中心。認(rèn)證中心在核實身份后监婶，將執(zhí)行一些必要的步驟旅赢，以確信請求確實由用戶發(fā)送而來，然后惑惶，認(rèn)證中心將發(fā)送給用戶一個數(shù)字證書煮盼，該證書內(nèi)包含用戶的人信息和他的公鑰信息，同時還附有認(rèn)證中心的簽名信息(根證書私鑰)簽名带污。用戶就可以使用自己的數(shù)字證書進行相關(guān)的各種活動僵控。數(shù)字證書由獨立的證書發(fā)行機構(gòu)發(fā)布，數(shù)字證書各不相同鱼冀，每種證書可提供不同級別的可信度报破。
(2)證書包含哪些內(nèi)容

• 1、證書頒發(fā)機構(gòu)的名稱
• 2千绪、證書本身的數(shù)字簽名
• 3充易、證書持有者的公鑰
• 4、證書簽名用到的Hash算法

(3)驗證證書的有效性
瀏覽器默認(rèn)都是會內(nèi)置CA跟證書荸型，其中根證書包含了CA的公鑰

• 防偽造證書1:如果證書頒發(fā)機構(gòu)是偽造的盹靴，瀏覽器不認(rèn)識，直接認(rèn)為是危險證書
• 防偽造證書2:證書頒發(fā)機構(gòu)是的確存在的瑞妇，于是根據(jù)CA名稿静，找到對應(yīng)內(nèi)置的CA根證書、CA的公鑰辕狰。用CA的公鑰改备，對偽造的證書的摘要進行解密，發(fā)現(xiàn)解密不了蔓倍，認(rèn)為是危險證書
• 防篡改:對于篡改的證書悬钳，使用CA的公鑰對數(shù)字簽名進行解密得到摘要A，然后再根據(jù)簽名的Hash算法計算出證書的摘要B偶翅，對比A與B他去，若相等則正常，若不相等則是被篡改過的倒堕。
• 防過期失效驗證:正式課在其過期前輩吊銷，通常情況是該證書的私鑰已經(jīng)失密爆价。較新的瀏覽器如果Chrome垦巴、Firefox媳搪、Opera和Internet Explored 都實現(xiàn)了在線證書的狀態(tài)協(xié)議(OCSP)以排除這種情況:瀏覽器將網(wǎng)站提供的證書序列號通過OCSP發(fā)送給證書頒發(fā)機構(gòu)，后者會告訴瀏覽器證書是否還是有效的骤宣。

證書.png

(六)那么咱們來看下HTTPS的結(jié)構(gòu)圖

https結(jié)構(gòu).png

由上圖可以看到秦爆，HTTP是直接建立在TCP之上的，而HTTPS則又經(jīng)過了TLS一系列協(xié)議憔披。所以等限，https協(xié)議在建立連接之前，首先要和雙方握手芬膝，身份認(rèn)證望门，傳輸數(shù)據(jù)之前要進行加密

(七)SSL和TLS

1、SSL(Secure Sokcet Layer锰霜，安全套接字層)

SSL是Netscape(網(wǎng)景公司)所研發(fā)筹误，用于保障在Internet上數(shù)據(jù)傳輸至安全，利用數(shù)據(jù)加密(Entryption)技術(shù)癣缅，可確保數(shù)據(jù)在網(wǎng)絡(luò)值傳輸過程中不會被截取厨剪，當(dāng)前版本為3.0。

SSL協(xié)議可分為兩層:

• 1友存、SSL記錄協(xié)議(SSL Record Protocol):它建立在可靠的傳輸協(xié)議(如TCP)之上祷膳，為高層協(xié)議提供數(shù)據(jù)封裝、壓縮屡立、加密等基本功能的支持直晨。
• 2、SSL握手協(xié)議(SSL Handshake Protocol):它建立在SSL記錄協(xié)議之上侠驯，用于在實際的數(shù)據(jù)傳輸開始前抡秆，通訊雙方進行身份認(rèn)證、協(xié)商加密算法吟策、交換加密密鑰等儒士。

2、TLS(Transport Layer Security,傳輸層安全協(xié)議)

用于兩個應(yīng)用程序之間提供保密性和數(shù)據(jù)完整性檩坚。
TLS1.0是IETF(Internet Engineering Task Force,Internet工程任務(wù)組)制定的一種新的協(xié)議着撩，它建立在SSL3.0協(xié)議規(guī)范之上，是SSL3.0的后續(xù)版本匾委，可以理解為SSL3.1拖叙，它是寫入RFC的，該協(xié)議由兩層組成：TLS記錄協(xié)議(TLS Record)和TLS握手協(xié)議(TLS Handshake)赂乐。較低的層為TLS記錄協(xié)議薯鳍，位于某個可靠的傳輸協(xié)議(例如TCP)上面

TLS 1.0是IETF（Internet Engineering Task Force，Internet工程任務(wù)組）制定的一種新的協(xié)議挨措，它建立在SSL 3.0協(xié)議規(guī)范之上挖滤，是SSL 3.0的后續(xù)版本崩溪，可以理解為SSL 3.1，它是寫入了 RFC 的斩松。該協(xié)議由兩層組成： TLS 記錄協(xié)議（TLS Record）和 TLS 握手協(xié)議（TLS Handshake）伶唯。較低的層為 TLS 記錄協(xié)議，位于某個可靠的傳輸協(xié)議（例如 TCP）上面惧盹。

3乳幸、SSL/TLS協(xié)議作用：

• 認(rèn)證用戶和服務(wù)器，確保數(shù)據(jù)發(fā)送到正確的客戶端和服務(wù)器
• 加密數(shù)據(jù)以防止數(shù)據(jù)中途被竊取
• 維護數(shù)據(jù)的完整性钧椰，確保數(shù)據(jù)在傳輸過程中不被改變粹断。

4、TLS比SSL的優(yōu)勢

• 1演侯、對于消息認(rèn)證使用密鑰散列發(fā)：TLS使用"消息認(rèn)證代碼的密鑰散列法"(HMAC),當(dāng)記錄在開放的網(wǎng)絡(luò)(如因特網(wǎng))上傳時姿染，該代碼確保記錄不會被變更。SSLv3.0還提供鍵控消息認(rèn)證秒际，但HMAC比SSLv3.0使用的(消息認(rèn)證代碼)MAC功能更安全
• 2悬赏、增強的偽隨機功能(PRF):PRF生成密鑰數(shù)據(jù)。在TLS中娄徊，HMAC定義PRF闽颇。PRF使用兩種散列算法保證其安全性，如果任一算法暴露了寄锐，只要第二種算法未暴露兵多，則數(shù)據(jù)仍然是安全的。
• 3橄仆、改進的已完成消息驗證：TLS和SSLv3.0都對兩個端點提供已完成的消息剩膘，該消息認(rèn)證交換的消息沒有被變更。然而盆顾，TLS將此已完成消息基于PRF和
• 4怠褐、一致證書處理：與SSLv3.0不同，TLS試圖制定必須在TLS之間實現(xiàn)交互的證書類型您宪。
• 5奈懒、特定警報消息：TLS提供更多的特定和附加警報，以指示任一會話端點檢測到的問題宪巨。TLS還對核實應(yīng)該發(fā)送某些警報進行記錄磷杏。

(八)HTTPS握手的過程

HTTP握手是有“3次握手的”，HTTPS是有"8次握手的"捏卓，大體分為以下幾個步驟：
1 驗證證書的有效性(是否被更改极祸，是否合法)
2 握手生成會話密鑰
3 利用會話密鑰進行內(nèi)容傳輸
先上圖

握手.png

我去，都是英文的啊，不過自己看了以下遥金，貌似還能看得懂峦椰，咱們就先詳細(xì)說下：

1、客戶端首次發(fā)出請求

由于客戶端(如瀏覽器)對一些加解密算的支持程度不一樣汰规，但是在TLS協(xié)議傳輸過程中必須使用同一套加解密算法才能保證數(shù)據(jù)能夠正常的加解密。在TLS握手階段物邑，客戶端要首先告知服務(wù)器溜哮，自己支持哪些加密算法，所以客戶端需要將本地支持的加密套件(Cipher Suit)的列表傳送給服務(wù)器色解。除此之外茂嗓，客戶端還要產(chǎn)生一個隨機數(shù)，這個隨機數(shù)一方面需要在客戶端保存科阎，另一方面需要傳給服務(wù)器述吸，客戶端的隨機數(shù)需要跟服務(wù)器的隨機數(shù)結(jié)合起來產(chǎn)生后面將要的Master Secret.
客戶端需要提供如下信息:

• 1、支持的協(xié)議版本锣笨，比如TLS 1.0版本
• 2蝌矛、一個客戶端生成的隨機數(shù)，稍后用于生成"對話密鑰"
• 3错英、支持的加密方法入撒，比如RSA公鑰加密
• 4、支持的壓縮方法
  PS：客戶端發(fā)送的信息之中不包括服務(wù)器的域名椭岩，也就是說茅逮，理論上服務(wù)器只能包含一個網(wǎng)站，否則會分不清應(yīng)該向客戶端提供哪一個網(wǎng)站的提供的數(shù)字證書判哥。這就是為什么通常一臺服務(wù)器只能由一張數(shù)字證書的原因
  對于虛擬主機的用戶來說献雅，這當(dāng)然很不方便。2006年塌计，TLS協(xié)議加入了Server Name Indication擴展挺身，允許客戶端向服務(wù)器提供它所請求的域名。

2夺荒、服務(wù)器的配置

采用HTTPS協(xié)議的服務(wù)器必須要有一套數(shù)字證書瞒渠，可以是自己制作或者CA證書。區(qū)別就是自己辦法的證書需要客戶端驗證通過技扼，才可以繼續(xù)訪問伍玖，而使用CA證書則不會彈出提示頁面。這套證書其實就是一堆公鑰和私鑰剿吻。公鑰給別人加密使用窍箍，私鑰給自己解密使用。服務(wù)器在接收到客戶端的請求后，服務(wù)器需要確定加密協(xié)議的版本椰棘，以及加密的算法纺棺，然后也生成一個隨機數(shù)。

3邪狞、服務(wù)器首次回應(yīng)

把上個階段生成的加密協(xié)議的版本祷蝌，加密的算法，隨機數(shù)以及自己的證書一起發(fā)送給客戶端帆卓。這個隨機數(shù)是整個過程的第二個隨機數(shù)巨朦。
返回的信息包括:

• 1、協(xié)議的版本剑令，比如TLS1.0版本糊啡，如果瀏覽器與服務(wù)器支持的版本不一致，服務(wù)器關(guān)閉加密通信
• 2吁津、加密的算法
• 3棚蓄、隨機數(shù)
• 4、服務(wù)器證書

除了上面這些信息碍脏，如果服務(wù)器需要確認(rèn)客戶端身份梭依，就會再包含一項請求，要求客戶端提供"客戶端證書"潮酒。比如睛挚，金融機構(gòu)往往只允許認(rèn)證客戶進入自己的網(wǎng)絡(luò)，就會向正式客戶提供USB密鑰急黎，里面包含了一張客戶端證書扎狱。

4、客戶端驗證證書

客戶端收到服務(wù)器回應(yīng)以后勃教，首先驗證服務(wù)器證書淤击。如果證書不是可信任機構(gòu)頒布、或者證書中的域名和實際域名不一致故源、或者證書已經(jīng)過期污抬，就會向訪問者顯示一個警告，由其選擇是否還要繼續(xù)通信绳军。
PS:驗證證書主要根據(jù)服務(wù)端發(fā)過來的證書名稱印机，在本地尋找其低級證書，并一級一級直到根證書门驾，驗證各級證書的合法性射赛。

5、客戶端傳送加密信息

驗證證書通過后奶是，客戶端再次產(chǎn)生一個隨機數(shù)(第三個隨機數(shù))楣责，然后使用證書中的公鑰進行加密竣灌，以及放一個ChangCipherSpec消息即編碼改變的消息，還有整個前面所有消息的hash值秆麸，進行服務(wù)器驗證初嘹，然后用新密鑰加密一段數(shù)據(jù)一并發(fā)送到服務(wù)器，確保正式通信前無誤沮趣。
客戶端使用前面的兩個隨機數(shù)以及剛剛新生成的新隨機數(shù)(又稱”pre-master key”)屯烦。
簡單的說下ChangeCipherSpec:
ChangeCipherSpec是一個獨立的協(xié)議，體現(xiàn)在數(shù)據(jù)包中就是一個字節(jié)的數(shù)據(jù)房铭，用于告知服務(wù)器漫贞，客戶端已經(jīng)切換到之前協(xié)商好的加密套件(Cipher Suite)的狀態(tài)，準(zhǔn)備使用之前協(xié)商好的加密套件加密數(shù)據(jù)并傳輸了育叁。
這部分傳送的是用證書加密后的隨機值，目的就是讓服務(wù)器得到這個隨機值芍殖，以后客戶端和服務(wù)其的通信就可以通過這個隨機值來進行加密解密了豪嗽。服務(wù)器與客戶端之前的數(shù)據(jù)傳輸過程中是庸才對稱加密方式加密的。

注意：
此外豌骏，如果前一步龟梦，服務(wù)器要求客戶端證書，客戶端會在這一步發(fā)送證書及相關(guān)信息窃躲。

6计贰、生成會話密鑰

上面產(chǎn)生的隨機數(shù)，是整個握手階段的出現(xiàn)的第三個隨機數(shù)蒂窒，又稱"pre-master key"躁倒。有了它之后，客戶端和服務(wù)器同時有了三個隨機數(shù)洒琢，接著雙方就用事先協(xié)商的加密方法秧秉，各自生成本地會話所用的同一把"會話密鑰"。
PS:為什么一定要用三個隨機數(shù)衰抑，來生成"會話密鑰"象迎？

答：不管是客戶端還是服務(wù)器，都是下需要隨機數(shù)呛踊，這樣生成的密鑰才不會每次都一樣砾淌，由于SSL協(xié)議中證書是靜態(tài)的，因此十分有必要引入一種隨機因素來保證協(xié)商出的密鑰的隨機性谭网。
對于RSA密鑰交換算法來說汪厨，pre-master-key本身就是一個隨機數(shù)，再加上第一步蜻底、第三步消息中的隨機數(shù)骄崩，三個隨機數(shù)通過一個密鑰導(dǎo)出器最終導(dǎo)出一個對稱密鑰聘鳞。pre master 的存在在于SSL協(xié)議不信任每一個主機都能產(chǎn)生完全的隨機數(shù)，如果隨機數(shù)不隨機要拂，那么pre master secret就可能被猜出來抠璃，那么僅適用于pre master secret作為密鑰就不合適了，因此必須引入新的隨機因素脱惰，那么客戶端和服務(wù)器加上pre master secret三個隨機數(shù)一同生成的密鑰就不容易被猜出了搏嗡，一個偽隨機數(shù)可能完全不隨機，但是三個偽隨機就十分接近隨機了拉一，每增加一個自由度采盒，隨機性增加的可不是一。

7蔚润、服務(wù)器最后的回應(yīng)

服務(wù)器生成"會話密鑰"后磅氨，向客戶端最后發(fā)送下面信息：

• 1、編碼改變通知嫡纠，表示隨后的信息都將用雙方商定的加密方法和密鑰發(fā)送烦租。
• 2、服務(wù)器握手結(jié)束通知除盏，表示服務(wù)器握手階段已經(jīng)結(jié)束叉橱。這一項同時也是前面所有內(nèi)容的hash值，用來供客戶端校驗者蠕。

8 客戶端解密

客戶端用之前生成的私鑰解密服務(wù)器傳過來的信息窃祝，于是獲取了解密后的內(nèi)容

至此，整個握手階段全部結(jié)束了踱侣。接下來粪小，客戶端與服務(wù)器進入加密通信，就完全是使用普通HTTP協(xié)議抡句，只不過用"會話密鑰"加密內(nèi)容糕再。

注意事項

SSL協(xié)議在握手階段使用的是非對稱加密，在傳輸階段使用的是對稱加密,也就是在說在SSL上傳送數(shù)據(jù)是使用對稱加密加密的!因為非對稱加密的速度緩慢玉转，耗費資源突想。其實當(dāng)客戶端和服務(wù)器使用非對稱加密方式建立連接后，客戶端和主機已經(jīng)決定好了在傳輸過程使用的對稱加密算法和關(guān)鍵的對稱加密密鑰究抓，由于這個過程本身是安全可靠的猾担，也即對稱加密密鑰是不可能被竊取盜用的，因此刺下，保證了在傳輸過程中對數(shù)據(jù)進行對稱加密也是阿安全可靠的绑嘹！如果有人竊聽通信，他可以知道雙方選擇的加密方法橘茉，以及三個隨機數(shù)中的兩個工腋。整個通話的安全姨丈，只取決于第三個隨機數(shù)(pre master secret)能不能被破解枯怖。

(九)HTTPS與代理

2.4 如何使用代理（charles）
我們知道從HTTPS的整個原理可以知道扬虚，客戶端和服務(wù)器進行通信的成果，客戶端是能拿到數(shù)據(jù)的涡尘，代理也一定能拿到趁冈，包括公共密鑰歼争，證書，算法等渗勘，但代理無法獲取服務(wù)器的私鑰沐绒，所以無法獲取5/6/7/8的會話密鑰，也就無法得到數(shù)據(jù)傳輸?shù)拿魑耐梗阅J(rèn)的情況下乔遮，charles是無法抓https的。那如何讓charles轉(zhuǎn)包并獲取明文取刃？也就是讓charles獲取私鑰申眼，獲取服務(wù)器的是不可能的，那只能在通信過程中使用charles自己的證書蝉衣，并在通信的過程中主動為請求的域名發(fā)放證書，流程如下：

image.png

從上面可以看出巷蚪，一旦信任代理的證書病毡，代理在中間就做一個轉(zhuǎn)換的角色，即擔(dān)任客戶端的服務(wù)器屁柏，又擔(dān)任服務(wù)器的客戶端啦膜，在中間傳輸?shù)倪^程中做了加密解密轉(zhuǎn)換。也就是說一旦信任代理淌喻，大力就可以干任何事僧家。

四、SPDY

2012年google如一聲驚雷提出了SPDY的方案裸删，大家猜開始從正面看待和解決老版本HTTP協(xié)議本身的問題八拱，SPDY可以說是綜合了HTTPS和HTTP兩者有點于一體的傳輸協(xié)議，主要解決：

• 1涯塔、降低延遲:：針對HTTP高延遲的問題肌稻，SPDY優(yōu)雅的采取了多路復(fù)用(multiplexing)。多路復(fù)用通過多個請求stream共享一個TCP連接的方式匕荸，解決了HOL blocking的問題爹谭，降低了延遲同事提高了帶寬的利用率。
• 2榛搔、請求優(yōu)先級：多路復(fù)用帶來的一個新的問題是诺凡，在連接共享的基礎(chǔ)上有可能會導(dǎo)致關(guān)鍵請求被阻塞东揣。SPDY允許給每個request設(shè)置優(yōu)先級，這樣重要的請求就會優(yōu)先得到相應(yīng)腹泌。比如瀏覽器加載首頁嘶卧，首頁的html內(nèi)容應(yīng)該優(yōu)先展示，之后才是各種靜態(tài)資源文件真屯，腳本文件等加載脸候，這樣保證用戶第一時間看到網(wǎng)頁的內(nèi)容。
• 3绑蔫、header壓縮：HTTP1.x的header很多時候都是重復(fù)多余的运沦。選擇和是的壓縮算法可以減少包的大小和數(shù)量。
• 4配深、基于HTTPS的加密協(xié)議傳輸携添，大大提高了傳輸數(shù)據(jù)的可靠性。
• 5篓叶、服務(wù)端推送(server push)烈掠，采用SPDY的網(wǎng)頁，例如一個網(wǎng)頁有一個style.css請求缸托，客戶端在收到style.css數(shù)據(jù)的同事左敌，服務(wù)端會將style.js文件推送給客戶端，當(dāng)客戶端再次嘗試獲取style.js時就可以直接從緩存中獲取到俐镐，不用再次發(fā)送請求了矫限。SPDY構(gòu)成圖:

SPDY結(jié)構(gòu)圖.png

SPDY位于HTTP之下，TPC和SSL之上佩抹，這樣可以輕松兼容老版本的HTTP協(xié)議叼风，同時也可以使用已有的SSL功能。
大家來看下SPDY的兼容性：

SPDY兼容.png

五棍苹、HTTP2.0

(一)无宿、HTTP2.0的前世今生

顧名思義有了HTTPS1.x，那么HTTP2.0也就順理成章的出現(xiàn)了枢里。
在HTTP/1.x中孽鸡，如果客戶端想發(fā)起多個并行請求必須建立多個TCP連接，這無疑增大了網(wǎng)絡(luò)開銷栏豺。另外HTTP/1.x不會壓縮請求和響應(yīng)頭梭灿，導(dǎo)致了不必要的網(wǎng)絡(luò)流量，HTTP/1.x不支持資源優(yōu)先級導(dǎo)致底層TCP連接利用率低下冰悠。而這些問題都是HTTP/2要著力解決的堡妒。HTTP2.0可以說是SPDY的升級版(其實也是基于SPDY設(shè)計的)，但是HTTP2.0跟SPDY仍有不同的地方溉卓，主要有以下兩點：

• 1皮迟、HTTP2.0支持明文HTTP傳輸搬泥，而SPDY輕質(zhì)使用HTTPS
• 2、HTTP2.0消息頭的壓縮算法采用HPACK伏尼，而非SPDY采用的DEFLATE

(二)忿檩、 HTTP2.0的新特性

• 1、新的二進制格式(Binary Format)：HTTP 1.x的解析是基于文本爆阶≡锿福基于文本洗衣的格式解析存在天然缺陷，文本的表現(xiàn)形式有多樣性辨图，要做到健壯性考慮的場景必然很多班套，二進制則不同，只認(rèn)0和1的組合故河，基于這種考慮HTTP2.0的協(xié)議解析決定采用二進制分幀格式吱韭，實現(xiàn)方便且健壯。
• 2鱼的、多路復(fù)用(multiPlexing)：即連接共享理盆，即每一個request都是用作連接共享機制的。一個request對應(yīng)一個id凑阶，這樣一個連接上可以有多個requst猿规，每個連接的request可以隨機的混雜在一起，接受方可以根據(jù)request的id將request再歸屬到各自不同的服務(wù)端請求里面宙橱，后面有一張多路復(fù)用原理圖
• 3姨俩、請求優(yōu)先級：把HTTP消息分解為很多獨立的幀后，就可以通過優(yōu)化這些幀的交錯和傳輸順序养匈，進一步提供性能。為了做到這一點都伪，每個流都有一個帶有31比特的的優(yōu)先值
• 4呕乎、header壓縮：HTTP1.x的header帶有大量的信息，而且每次都要重復(fù)發(fā)送陨晶，HTTP2.0使用encoder來減少需要傳輸?shù)膆eader大小猬仁，通訊雙方各自cache一個header field表，既避免了重復(fù)的header傳輸先誉，又減少了需要傳輸?shù)拇笮　?/li>
• 5湿刽、服務(wù)端推送(server push)：同SPDY一樣，HTTP2.0也具有server push功能褐耳。

HTTP2.0性能增強的核心诈闺，全在于新增的二進制分幀層，它定義了如何封裝HTTP消息并在客戶端與服務(wù)器之間傳輸

二進制分幀層.png

所以HTTP/2引入了三個新的概念：

• 1铃芦、數(shù)據(jù)流：基于TCP連接之上的邏輯雙向字節(jié)流雅镊，對應(yīng)一個請求及響應(yīng)襟雷。客戶端每發(fā)起一個請求就建立一個數(shù)據(jù)量就仁烹，后續(xù)該請求及其響應(yīng)的所有數(shù)據(jù)都通過該數(shù)據(jù)流傳輸耸弄。
• 2、消息：一個請求或者響應(yīng)對應(yīng)的一系列數(shù)據(jù)幀
• 3卓缰、幀”：HTTP/2的最小數(shù)據(jù)切片單位计呈，每個幀包含幀首部，至少也會標(biāo)示出當(dāng)前幀所屬的流征唬。

上述概念之間的邏輯關(guān)系：

• 1捌显、所有通信都在一個TCP連接上完成，此連接可以承載任意數(shù)量的雙向數(shù)據(jù)流鳍鸵。
• 2苇瓣、每個數(shù)據(jù)流都有一個唯一的標(biāo)識符和可選的優(yōu)先級信息，用于承載雙向消息偿乖。
• 3击罪、每條消息都是一條邏輯HTTP消息(例如請求或者響應(yīng))，包含一個或多個幀贪薪。
• 4媳禁、幀是最小的通信單位，承載著特定類型的數(shù)據(jù)画切，例如HTTP標(biāo)頭竣稽、消息負(fù)載等等。來自不同數(shù)據(jù)流的幀可以交錯發(fā)送霍弹，然后再根據(jù)每個幀頭的數(shù)據(jù)流標(biāo)識符重新組裝毫别。
• 5、每個HTTP消息分分解為多個獨立的幀后可以交錯發(fā)送典格，從而在宏觀上實現(xiàn)了多個請求或者響應(yīng)并行傳輸?shù)男Ч夯隆＿@類似于多進程環(huán)境下的時間分片機制。

所有HTTP 2.0通信都在一個連接上完成耍缴，這個連接可以承載任意數(shù)量的雙向數(shù)據(jù)流砾肺。每個數(shù)據(jù)流以消息的形式發(fā)送。而消息由一或多個幀組成防嗡，而這些幀可以亂序發(fā)送变汪，然后再根據(jù)每個幀首部流標(biāo)識符重新組裝。

image.png

簡而言之蚁趁，HTTP2.0把HTTP協(xié)議通信的基本單位縮小為一個一個的幀裙盾，這些幀對應(yīng)著邏輯流中的消息。相應(yīng)地，很多流可以并行地在同一個TCP連接上交換消息闷煤。

在HTTP/1.1中童芹，如果客戶端想發(fā)送多個平行的請求以及改進性能，必須使用多個TCP連接鲤拿。HTTP2.0的二進制分幀層突破了限制假褪；客戶端和服務(wù)器可以把HTTP消息分解為互不依賴的幀，然后亂序發(fā)送近顷，最后再把另一端把它們重新組合起來生音。如下圖

HTTP2.png

下面這個圖更形些

多路復(fù)用圖.png

在HTTP/1.x中，頭部的數(shù)據(jù)都是純文本格式窒升。通常會增加500-800字節(jié)的負(fù)荷缀遍。為了減少開銷提高性能，HTTP/2壓縮頭部數(shù)據(jù)饱须，由于HTTP2.0連接的兩端都知道已經(jīng)發(fā)送了哪些頭部域醇，這些頭部的值是什么，從而可以針對之前的數(shù)據(jù)編碼發(fā)送差異數(shù)據(jù)蓉媳。如下圖：

首部壓縮圖.png

(三)HTTP2.0與HTTP1.1的區(qū)別

區(qū)別.png

六譬挚、隧道

Web隧道(Web tunnel)是HTTP的另一種用法，可以通過HTTP應(yīng)用程序訪問非HTTP協(xié)議的應(yīng)用程序酪呻，Web隧道允許用戶允許用戶通過HTTP連接發(fā)送非HTTP流量减宣，這樣就可以在HTTP上捎帶其他協(xié)議數(shù)據(jù)了。使用Web隧道最常見的原因就是要在HTTP連接中嵌入非HTTP流量玩荠。這樣這類流量就可以穿過只允許Web流量通過的防火墻了漆腌。

(一) 建立隧道

Web隧道是用HTTP的CONNECT方法建立起來的。CONNECT方法請求隧道網(wǎng)管創(chuàng)建一條到達任一目的服務(wù)器和端口的TCP連接阶冈，并對客戶端和服務(wù)器職期間的后續(xù)數(shù)據(jù)進行盲轉(zhuǎn)發(fā)闷尿。
下圖顯示了CONNECT方法如何建立起一條到達網(wǎng)管的隧道，來自《HTTP 權(quán)威指南》

如何建立隧道.png

• 1女坑、(a)是客戶端相互發(fā)送了額一條CONNECT請求給隧道網(wǎng)關(guān)填具。客戶端的CONNECT方法請求隧道網(wǎng)關(guān)打開一條TCP連接(在這里堂飞，打開的是到主機orders.joes-hardware.com的標(biāo)準(zhǔn)SSL端口443的連接)灌旧；
• 2绑咱、(b)和(c)中創(chuàng)建了TCP連接绰筛，一旦建立了TCP連接，網(wǎng)管就會發(fā)送一條HTTP200 Connection Established響應(yīng)來通知客戶端描融，此時铝噩，隧道就建立起來了×耍客戶端通過HTTP隧道發(fā)送的所有數(shù)據(jù)都會被直接轉(zhuǎn)發(fā)給輸出TCP連接骏庸，服務(wù)器發(fā)送的所有數(shù)據(jù)都會通過HTTP隧道轉(zhuǎn)發(fā)給客戶端毛甲。

上圖中的例子描述了一條SSL隧道，其中的SSL流量是在一條HTTP連接上發(fā)送的具被，但是通過CONNECT方法可以與使用任意協(xié)議的任意服務(wù)器建立TCP連接玻募。

1、CONNECT請求
除了起始行之外一姿，CONNECT的語言與其他HTTP方法類似七咧。一個后面跟著冒號和端口號的主機名取代了請求的URL。主機和端口都必須制定:

CONNECT home.netscape.com：443 HTTP/1.0
User-agent： Mozilla/4.0

和其他HTTP報文一樣叮叹，起始行之后艾栋，有零個或多個HTTP請求首部字段。這些行照例以CRLF結(jié)尾蛉顽，首部列表以一個空的CRLF結(jié)束蝗砾。
2、CONNECT響應(yīng)
發(fā)送了請求之后携冤，客戶端會等待來網(wǎng)管的響應(yīng)悼粮，和普通HTTP報文一樣，響應(yīng)碼表示成功噪叙。按照慣例矮锈，響應(yīng)中的原因短語通常設(shè)為"Connection Established"。

HTTP/1.0 200 Connection Established
Proxy-agent: Netscape-Proxy/1.1

與普通HTTP響應(yīng)不同睁蕾，這個響應(yīng)并不需要包含Content-Type首部苞笨。此時連接只是對原始字節(jié)進行轉(zhuǎn)接，不再是報文的承載者子眶，所以不需要使用內(nèi)容類型瀑凝。

管道化數(shù)據(jù)對網(wǎng)管是不透明的，所以網(wǎng)管不能對分組的順序和分組流做任何假設(shè)臭杰。一旦隧道建立起來了粤咪，數(shù)據(jù)就可以在任意時間流向任意方向了。

作為一種性能優(yōu)化方法渴杆，允許客戶端在發(fā)送了CONNECT請求之后寥枝，接受響應(yīng)之前，發(fā)送隧道數(shù)據(jù)磁奖。這樣可以更快的將數(shù)據(jù)發(fā)送給服務(wù)器囊拜，但這就意味著網(wǎng)管必須能夠正確處理跟在請求之后的數(shù)據(jù)。尤其是比搭，網(wǎng)管不能假設(shè)網(wǎng)絡(luò)I/O請求只會返回首部數(shù)據(jù)冠跷，網(wǎng)管必須確保在連接準(zhǔn)備就緒時，將與首部一同讀進來的數(shù)據(jù)發(fā)送給服務(wù)器。在請求之后蜜托，或者其他非200但不致命的錯誤狀態(tài)抄囚，就必須做好重發(fā)請求數(shù)據(jù)的準(zhǔn)備。如果在任意時刻橄务，隧道的任意一個端點斷開連接幔托，那個端點發(fā)出的所有未傳輸數(shù)據(jù)都會被傳送給另一個端點，之后到另一個端點的鏈接也會被代理終止蜂挪。如果還有數(shù)據(jù)要傳輸給關(guān)閉連接的端點柑司，數(shù)據(jù)會被丟棄。

(二)SSL隧道

最初開發(fā)Web隧道是為了通過防火墻來傳輸加密的SSL流量锅劝。很多組織都會將所有流量通過分組過濾路由器和代理服務(wù)器以隧道方式傳輸攒驰，以提升安全性。但有些協(xié)議故爵，比如加密SSL玻粪，其信息是加密的的，無法通過傳統(tǒng)的代理服務(wù)器轉(zhuǎn)發(fā)诬垂。隧道會通過一條HTTP連接來傳輸SSL流量劲室，以穿過端口80的HTTP防火墻。

防火墻與HTTP.png

為了讓SSL流量經(jīng)現(xiàn)存的代理防火墻進行傳輸结窘，HTTP中添加了一項隧道特性很洋，在此特性中，可以將原始的加密數(shù)據(jù)放在HTTP報文中隧枫，通過普通的HTTP信道傳送喉磁。

ssl隧道.png

• a圖代表一個SSL連接，SSL流量直接發(fā)給了一個(SSL端口443上的)安全Web服務(wù)器官脓。
• b圖代表了SSL流量被封裝到一條HTTP報文中协怒，并通過HTTP端口80的連接發(fā)送，最后解封裝為普通的SSL連接卑笨。

通常會用隧道將非HTTP流量傳過端口過濾防火墻孕暇。這一點可以得到很好的利用。比如赤兴，通過防火墻傳輸完全SSL流量妖滔。但是，這項特性可能會被濫用桶良，使得惡意協(xié)議通過HTTP隧道流入某個組織內(nèi)部座舍。
可以像其他協(xié)議一樣，對HTTPS協(xié)議(SSL上的HTTP)進行網(wǎng)管操作：由網(wǎng)關(guān)(而不是客戶端)初始化與遠(yuǎn)端HTTPS服務(wù)器的SSL會話艺普，然后代表客戶端執(zhí)行HTTPS事務(wù)簸州。響應(yīng)會由代理接受并解密，然后通過(不安全的)HTTP傳送給客戶端歧譬。這是網(wǎng)關(guān)處理FTP的方式岸浑。但這種方式有幾個缺點：

• 1、客戶端到網(wǎng)關(guān)之間的鏈接是普通的非安全HTTP瑰步；
• 2矢洲、盡管代理是已認(rèn)證主體，但客戶端無法對遠(yuǎn)端服務(wù)器執(zhí)行SSL客戶端認(rèn)證(基于X509證書的認(rèn)證)缩焦；網(wǎng)關(guān)要支持完整的SSL實現(xiàn)

可以像其他協(xié)議一樣读虏，對HTTPS協(xié)議(SSL上的HTTP)進行網(wǎng)關(guān)操作：由網(wǎng)關(guān)(而不是客戶端)初始化與遠(yuǎn)端HTTPS服務(wù)器的SSL會話，然后代表客戶端執(zhí)行 HTTPS事務(wù)袁滥。響應(yīng)會由代理接收并解密盖桥，然后通過(不安全的)HTTP傳送給客戶端。這是網(wǎng)關(guān)處理FTP的方式题翻。但這種方式有幾個缺點：客戶端到網(wǎng)關(guān)之間的連接是普通的非安全HTTP揩徊；盡管代理是已認(rèn)證主體，但客戶端無法對遠(yuǎn)端服務(wù)器執(zhí)行SSL客戶端認(rèn)證(基于X509證書的認(rèn)證)嵌赠；網(wǎng)關(guān)要支持完整的SSL實現(xiàn)塑荒。

對于SSL隧道機制來說，無需在代理中實現(xiàn)SSL姜挺。SSL會話是建立在產(chǎn)生請求的客戶端和目的(安全的)Web服務(wù)器之間的齿税，中間的代理服務(wù)器只是將加密數(shù)據(jù)經(jīng)過隧道傳輸，并不會在安全事務(wù)中扮演其他的角色炊豪。

在適當(dāng)?shù)那闆r下凌箕，也可以將HTTP的其他特性與隧道配合使用。尤其是词渤，可以將代理的認(rèn)證支持與隧道配合使用陌知，對客戶端使用隧道的權(quán)利進行認(rèn)證。

隧道.png

總的來說掖肋，隧道網(wǎng)管無法驗證目前使用的協(xié)議是否就是它原本打算經(jīng)過的隧道的協(xié)議仆葡。因此，比如說志笼，一些修換搗亂的用戶可能會通過本打算用于SSL的隧道沿盅，越過公司防火墻傳遞因特網(wǎng)的游戲流量，而惡意用戶可能會用隧道打開Telnet會話纫溃，或用隧道繞過公司的E-mail掃描器來發(fā)送E-mail腰涧。為了降低對隧道的濫用，網(wǎng)關(guān)應(yīng)該只為特定的知名端口紊浩，比如HTTPS端口443打開隧道窖铡。

七疗锐、代理

Web代理是一種存在于網(wǎng)絡(luò)中間的實體，提供各式各樣的功能》驯耍現(xiàn)在網(wǎng)絡(luò)系統(tǒng)中滑臊，Web代理無處不在。

(一)代理的作用

• 1箍铲、提高訪問速度雇卷。因為客戶端要求的數(shù)據(jù)存于代理服務(wù)器的硬盤中，因此下次這個客戶端或者其他要求相同的站點數(shù)據(jù)時颠猴，就會直接從代理服務(wù)器的硬盤中讀取关划，代理服務(wù)器起到了緩存的作用，對熱門站點有很多客戶訪問時翘瓮，代理服務(wù)器的優(yōu)勢更為明顯贮折。
• 2、Proxy可以起到防火墻的作用资盅，因為所有代理服務(wù)器的用戶都必須通過代理服務(wù)器訪問遠(yuǎn)程站點脱货，因此在代理服務(wù)器上就可以設(shè)置相應(yīng)的限制，以過濾或屏蔽掉某些信息律姨。這是局域網(wǎng)網(wǎng)管對局域網(wǎng)用戶訪問限制最常用的辦法振峻，也是局域網(wǎng)用戶為什么不能瀏覽某些網(wǎng)站的原因。撥號用戶如果使用代理服務(wù)器择份，同樣必須服從代理服務(wù)器的訪問限制扣孟，除非你不使用這個代理服務(wù)器。
• 3荣赶、通過代理服務(wù)器訪問一些不能直接訪問的網(wǎng)站凤价，互聯(lián)網(wǎng)上有許多開放的代理服務(wù)器，客戶在訪問權(quán)限受到限制時拔创，而這些代理服務(wù)器的訪問權(quán)限是不受限制的利诺，剛好代理服務(wù)器在客戶的訪問范圍之內(nèi)，那么客戶通過代理服務(wù)器訪問目標(biāo)網(wǎng)站就能成為可能剩燥。國內(nèi)高校的多使用教育網(wǎng)慢逾，不能出國，但通過代理服務(wù)器灭红，就能實現(xiàn)訪問因特網(wǎng)侣滩，這就是高校內(nèi)代理服務(wù)器熱的原因。
• 4变擒、安全性得到提高君珠。無論在上聊天室還是瀏覽網(wǎng)站，目標(biāo)網(wǎng)站只知道你來自代理服務(wù)器娇斑，而你的真實IP就無法預(yù)測策添，這就使得使用者的安全性得以提高

(二)材部、代理服務(wù)器工作流程

• 1、當(dāng)客戶端A對Web服務(wù)器請求時唯竹，A的請求會首先發(fā)送到代理服務(wù)器乐导。
• 2、代理服務(wù)器接收到客戶端請求后摩窃，會檢查緩存中是否存有客戶端所需要的數(shù)據(jù)。
• 3芬骄、如果代理沒有客戶端A請求的數(shù)據(jù)猾愿，它將會向Web服務(wù)器提交請求
• 4、Web服務(wù)器響應(yīng)請求的數(shù)據(jù)
• 5账阻、代理服務(wù)器向客戶端A轉(zhuǎn)發(fā)Web服務(wù)器的數(shù)據(jù)
• 6蒂秘、客戶端B訪問Web服務(wù)器，向代理服務(wù)發(fā)出請求淘太。
• 7姻僧、代理服務(wù)器查找緩存記錄，確認(rèn)已經(jīng)存在Web服務(wù)器相關(guān)數(shù)據(jù)蒲牧。
• 8撇贺、代理服務(wù)器直接回應(yīng)查詢的信息，而不需要再去服務(wù)器進行查詢冰抢，從而達到節(jié)約網(wǎng)絡(luò)流量和提高訪問速度的目的

(三)松嘶、代理的形式

HTTP代理存在兩種形式，分別如下：

• 第一種是RFC 7230 -HTTP/1.1：Message Syntax and Routing(即修訂后的RFC 2616挎扰，HTTP/1.1 協(xié)議的第一部分)描述的普通代理翠订。這種代理扮演的是"中間人“的角色，對于連接到它的客戶端來說遵倦，它是服務(wù)端尽超，對于要連接的服務(wù)器來說，它是客戶端梧躺。它就是負(fù)責(zé)在兩端之間來回傳送HTTP報文似谁。
• 第二種是Tunneling TCP basedprotocols through Web proxy servers (通過Web代理服務(wù)器用隧道方式傳輸基于TCP協(xié)議)描述的隧道代理溃槐。通過HTTP協(xié)議正文部分(Body)完成通訊挚歧，以HTTP方式實現(xiàn)任意基于TCP應(yīng)用層協(xié)議代理渺贤。這種代理使用HTTP的CONNECT方法建立連接轨功，但是CONNECT 最開始并不是RFC 2616 -HTTP/1.1的一部分寥裂，直到2014年發(fā)布的HTTP/1.1修訂版中必指，才增加了對CONNECT及隧道代理的描述萤厅，詳見RFC 7231- HTTP/1.1:Semantics andContent阎毅。實際上這種代理早就被廣泛實現(xiàn)目代。

PS:事實上屈梁，第一種代理嗤练，對應(yīng)<HTTP權(quán)威指南>一書中第六章"代理"，第二種代理在讶，對應(yīng)第八章"集成點：網(wǎng)關(guān)煞抬、隧道及中繼"中的8.5小節(jié)"隧道"。

1构哺、普通代理

原理：HTTP客戶端向代理服務(wù)器發(fā)送請求報文革答，代理服務(wù)器需要正確地處理請求和連接(例如正確處理(conntion:keep-alive)，同時向目標(biāo)服務(wù)器發(fā)送請求曙强，并將受到的響應(yīng)裝發(fā)給客戶端残拐。

• 假如我通過代理訪問A網(wǎng)站，對A來說碟嘴，它會把代理當(dāng)做客戶端溪食，完全察覺不到真正的客戶端的存在，這實現(xiàn)了隱藏客戶端IP的目的娜扇，當(dāng)然代理也可以修改HTTP請求頭部错沃，通過X-Forwarded-IP這楊的自定義頭部告訴服務(wù)器真正的客戶端IP。但服務(wù)器無法驗證這個自定義頭部真的是由代理添加雀瓢，還是客戶端修改了請求頭枢析，所以從HTTP頭部字段取IP時，需要格外小心刃麸。

• 給瀏覽器顯示的指定代理登疗，需要手動修改瀏覽器或相關(guān)設(shè)置，或者指定PAC(Proxy Auto-Configuration嫌蚤，自動配置代理)文件自動設(shè)置辐益，還有些瀏覽器支持WPAD(Web ProxyAutodiscovery Protocol ,Web代理自動發(fā)現(xiàn)協(xié)議)。顯示指定瀏覽器代理這種方式一般稱之為正向代理脱吱，瀏覽器齊總正向代理后智政，會對HTTP請求報文做一些修改，來規(guī)避老舊代理服務(wù)器的一些問題箱蝠。
• 還有一種情況是訪問A網(wǎng)站時续捂，實際上訪問的是代理，代理收到請求報文后宦搬，再向真正提供服務(wù)的服務(wù)器發(fā)起請求牙瓢，并將響應(yīng)轉(zhuǎn)發(fā)給瀏覽器。這種情況一般被稱為反向代理间校，它可以用來隱藏服務(wù)器IP及端口矾克，一般使用反向代理后，需要通過修改DNS讓域名解析到代理服務(wù)器IP憔足，這是瀏覽器無法察覺真正服務(wù)器的存在胁附，當(dāng)然也就不需要修改配置了酒繁。反向代理是Web系統(tǒng)最為常見的部署方式。

2控妻、隧道代理

原理：HTTP客戶端通過HTTP的CONNECT方法請求隧道代理州袒，創(chuàng)建一條到達任意目的服務(wù)器和端口的TCP連接，并對客戶端和服務(wù)器之間的后繼數(shù)據(jù)進行盲轉(zhuǎn)發(fā)弓候。
具體請查看本片文章第五部分

這里將HTTP隧道分為兩種：

• 1郎哭、不使用CONNECT的隧道
  不實用CONNECT的隧道，實現(xiàn)了數(shù)據(jù)包的重組和轉(zhuǎn)發(fā)菇存。在Proxy收到來自客戶端的HTTP請求后夸研，會重新創(chuàng)建Request請求，并發(fā)送到目標(biāo)服務(wù)器撰筷。當(dāng)目標(biāo)服務(wù)器返回Response給Proxy之后陈惰，Proxy會對Response進行解析畦徘，然后重新組裝Resposne毕籽，發(fā)送給客戶端。所以在不使用CONNECT方式建立的隧道井辆，Proxy有機會對客戶端與目標(biāo)服務(wù)器之間的通信數(shù)據(jù)進行窺探关筒，而且有機會對數(shù)據(jù)進行串改。
• 2杯缺、使用CONNECT的隧道:而對于使用CONNECT的隧道則不同蒸播。當(dāng)客戶端向Proxy發(fā)起HTTP CONNECT Method的時候，就是告訴Proxy萍肆，先在Proxy和目標(biāo)服務(wù)器之間先建立起連接袍榆，在這個連接建立起來之后，目標(biāo)服務(wù)器會返回一個回復(fù)給Proxy塘揣，Proxy將這個回復(fù)轉(zhuǎn)發(fā)給客戶端包雀，這個Response是Proxy跟目標(biāo)服務(wù)器連接建立的狀態(tài)回復(fù)，而不是請求數(shù)據(jù)的Response亲铡。在此之后才写，客戶端跟目標(biāo)服務(wù)器所有的通信豆?jié){使用值前簡建立來的連接。這種情況下的HTTP隧道奖蔓，Proxy僅僅實現(xiàn)轉(zhuǎn)發(fā)赞草，而不會關(guān)心轉(zhuǎn)發(fā)的數(shù)據(jù)，這也就是為什么在使用Proxy的時候吆鹤，HTTPS請求必須首先使用HTTP CONNECT建立隧道厨疙。因為HTTPS的數(shù)據(jù)都是經(jīng)過加密的，Proxy是無法對HTTPS的數(shù)據(jù)進行解密的疑务，所只能使用CONNECT轰异，僅僅對通信數(shù)據(jù)進行轉(zhuǎn)發(fā)岖沛。

3、與proxy有關(guān)的字段

• X-Forwarded-For(XFF):是用來識別通過HTTP代理或者負(fù)載均衡方法連接到Web服務(wù)器的客戶端最原始的IP地址的HTTP請求頭字段搭独。Squid:緩存代理服務(wù)器的開發(fā)人員最早引入了這一HTTP頭字段婴削，如果該沒有XFF或者另外一個種相似的技術(shù)，所有通過代理服務(wù)器的連接只會顯示代理服務(wù)器的IP地址(而非連接發(fā)起的原始IP地址)牙肝，這雅漾的代理服務(wù)器實際上充當(dāng)了匿名服務(wù)提供者的角色唉俗，如果連接的原始IP地址不可得，惡意訪問的檢查與預(yù)防的難度將大大增加
• X-Forwarded-Host和X-Forwarded-Proto分別記錄客戶端最原始的主機和協(xié)議
• Proxy-Authorization:連接到Proxy的身份驗證信息
• Proxy-connection:它不是標(biāo)準(zhǔn)協(xié)議的一部分配椭，標(biāo)準(zhǔn)些協(xié)議中已經(jīng)存在一種機制可以完成此協(xié)議頭的功能虫溜，這就是Connection頭域，與Proxy-Connection頭相比股缸，Connection協(xié)議頭幾乎提供了相同的功能衡楞，除了錯誤部分。而且敦姻，Connection協(xié)議頭可用于任意連接之間瘾境，包括HTTP服務(wù)器，代理镰惦，客戶端迷守，而不是像Proxy-Connection一樣，只能用于代理服務(wù)器和客戶端之間旺入。

八兑凿、InetAddress類和InetSocketAddress類

(一)、InetAddress(IP地址)

InetAddress是IP地址(也是主機地址)類封裝計算機的IP地址和DNS茵瘾，不包含端口礼华。

1、如何獲取對象:

創(chuàng)建主機地址對象要靠InetAddress類的幾個靜態(tài)工廠方法:

• InetAddress getByAddress(byte[] addr):僅根據(jù)IP地址的各個字節(jié)創(chuàng)建IP地址對象拗秘。
• InetAddress getLocalHost():返回本機IP地址對象
• InetAddress getByAddress(String host,byte[] addr): 根據(jù)主機名和IP地址的各個自己創(chuàng)建IP地址對象圣絮。要把IP地址的高字節(jié)放在addr的低索引處。
• InetAddress getByName(String host)：僅根據(jù)主機名創(chuàng)建IP地址對象聘殖。函數(shù)會訪問DNS服務(wù)器來獲取host對象的IP地址晨雳。

注：主機名既可以是域名，也可以是IP地址的字符串形式奸腺。例如餐禁，

InetAddress.getByName("www.163.com")
InetAddress.getByName("192.168.2.23")

2、方法

• String toString():返回"主機名/IP地址"字符串
• String getHostName() :返回此IP地址的主機名
• byte[] getAddress():返回此IP地址的各個字節(jié)突照，高字節(jié)放在地索引處
• String getHostAddress():返回此IP地址的字符串形式
• Boolea isReachable(int timeout):測試此IP地址的可達性帮非，最多等待timeout毫秒。
• Boolean equal(Object obj)：如果此IP地址的getAddress()結(jié)果與obj.getAddress()不僅數(shù)組長度相同且每個元素也相同，則返回true末盔。

(二)筑舅、InetSocketAddress類

InetSocketAddress是在InetAddress基礎(chǔ)上封裝了端口號。所以說InetSocketAddress是(IP地址+端口號)類型陨舱，也就是端口地址類型翠拣。
它的基類是SocketAddress類，SocketAddress類里面什么都沒有游盲。

1误墓、如何獲取對象:

• InetSocketAddress(int port):創(chuàng)建IP地址為通配符地址，端口號為port的端口地址益缎。
• InetSocketAddress(InetAddress addr,int port):創(chuàng)建IP地址addr谜慌，端口號為port的端口地址。
• InetSocketAddress(String host,int port)：根據(jù)主機名和端口號創(chuàng)建端口地址莺奔。函數(shù)會訪問DNS服務(wù)器來解析出host和IP地址的欣范，如果解析失敗，則標(biāo)記為"未解析"
• InetSocketAddress createUnresolved(String host,int port):同上令哟，但是不會訪問DNS服務(wù)器去解析主機名恼琼，而是直接標(biāo)記為"未解析"。

2励饵、方法

• boolean isUnsolved():如果尚未解析出IP地址驳癌，則返回true滑燃。
• String toString():返回"主機名/IP地址：端口地址"字符串
• InetAddress getAddress():返回此端口的IP地址役听。
• String getHostName():返回此端口的主機名。
• int getPort():返回此端口的端口號表窘。
• boolean equals(Object obj):如果此端口與obj端口的IP地址和端口號都相等典予，則返回true。

(三)乐严、兩者的卻別

關(guān)鍵就是在InetSocketAddress不基于任何協(xié)議瘤袖，一般用于socket編程。

• 表面看InetSocketAddress多了一個端口號昂验，端口的作用：一臺擁有IP地址的主機可以提供許多服務(wù)捂敌，比如Web服務(wù)、FTP服務(wù)既琴、SMTP服務(wù)等占婉，這些服務(wù)完全可以通過1個IP地址來實現(xiàn)。
• 那么主機怎么區(qū)分不同的網(wǎng)絡(luò)服務(wù)甫恩？顯然不能只靠IP地址逆济，因此IP地址與網(wǎng)絡(luò)服務(wù)的關(guān)系是一對多的關(guān)系。
• 實際上是通過"IP地址+端口號"來區(qū)分不同的服務(wù)的。