• 1.OkHttp源碼解析(一):OKHttp初階
• 2 OkHttp源碼解析(二):OkHttp連接的"前戲"——HTTP的那些事
• 3 OkHttp源碼解析(三):OKHttp中階之線程池和消息隊(duì)列
• 4 OkHttp源碼解析(四):OKHttp中階之?dāng)r截器及調(diào)用鏈
• 5 OkHttp源碼解析(五):OKHttp中階之OKio簡介
• 6 OkHttp源碼解析(六):OKHttp中階之緩存基礎(chǔ)
• 7 OkHttp源碼解析(七):OKHttp中階之緩存機(jī)制
• 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ā)下來，會在每一層都加上頭部信息，進(jìn)行封裝，然后再發(fā)送到數(shù)據(jù)接收端。這個基本的流程你需要知道，就是每個數(shù)據(jù)都會經(jīng)過數(shù)據(jù)的封裝和解封裝的過程。在OSI七層模型中，每一層的作用對應(yīng)的協(xié)議如下：

協(xié)議.png

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

tcp.png

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

• Source Port和Destination Port:分別占用16位，表示源端口號和目的端口號；用于區(qū)別主機(jī)中的不同進(jìn)程，IP地址用來區(qū)分不同主機(jī)的，源端口號和目的端口號配合上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ù)目，需要這個值是因?yàn)槿芜x字段的長度是可變的。這個字段占4bit(最多能表示15個32bit的字，即4*15=60個字節(jié)的首部長度)，因此TCP最多有60個字節(jié)的首部。然而，沒有任選字段，正常的長度是20字節(jié)。
• TCP Flags:TCP首部中有6個比特，它們總的多個可同時被設(shè)置為1，主要是用于操控TCP的狀態(tài)機(jī)，依次為URG，ACK，PSH，RST，SYN，F(xiàn)IN。
• Window:窗口大小，也就是有名的滑動窗口，用來進(jìn)行流量控制；這是一個復(fù)雜的問題

TCP是主機(jī)對主機(jī)層的傳輸控制協(xié)議，提供可靠的連接服務(wù)，采用三次握手確認(rèn)建立一個連接:位碼即tcp標(biāo)志位,有6種標(biāo)示:SYN(synchronous建立聯(lián)機(jī)) 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ù)包到達(dá)接受端以后，立即傳送給應(yīng)用程序，而不是在緩沖區(qū)排隊(duì)。
• 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ù)包常常被用來進(jìn)行端口掃描。掃描者發(fā)送一個只有SYN的數(shù)據(jù)包，如果對方主機(jī)響應(yīng)了一個數(shù)據(jù)包回來，就表明這臺主機(jī)存在這個端口，但是由于這種掃描只是進(jìn)行TCP三次握手的第一次握手，因此這種掃描的成功表明被掃描的機(jī)器很不安全，一臺安全的主機(jī)將會強(qiáng)制要求一個連接嚴(yán)格的進(jìn)行TCP的三次握手。
• FIN:表示發(fā)送端已經(jīng)達(dá)到數(shù)據(jù)末尾，也就是說雙方數(shù)據(jù)傳送完成，沒有數(shù)據(jù)可以傳送了，發(fā)送FIN標(biāo)志位的TCP數(shù)據(jù)包后，連接將斷開。這個表示的數(shù)據(jù)包也經(jīng)常被用于進(jìn)行端口掃描。

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

二、TCP3次握手和4次揮手

(一)、3次握手

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

image.png

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

• 1、第一次握手:建立連接，客戶端先發(fā)送連接請求報文，將SYN位置為1，Sequence Number為X;然后，客戶端進(jìn)入SYN+SEND狀態(tài)，等待服務(wù)器的確認(rèn)；
• 2、第二次握手：服務(wù)器收到SYN報文。服務(wù)器收到客戶端的SYN報文，需要對這個SYN報文進(jìn)行確認(rèn)，設(shè)置Acknowledgment Number為x+1(Sequence+1)；同時，自己還要送法SYN消息，將SYN位置為1，Sequence Number為y；服務(wù)器將上述所有信息放到一個報文段(即SYN+ACK報文段)中，一并發(fā)送給客戶端，此時服務(wù)器進(jìn)入SYN+RECV狀態(tài)。
• 3、第三次握手；客戶端收到服務(wù)器的 SYN+ACK報文段。然后將Acknowlegment Number設(shè)為y+1,向服務(wù)器發(fā)送ACK報文段，這個報文段發(fā)送完畢后，客戶端端服務(wù)器都進(jìn)入ESTABLISHED狀態(tài)，完成TCP三次握手。

實(shí)例:

• IP 192.168.1.116.3337 > 192.168.1.123.7788: S 3626544836
  第一次握手：192.168.1.116發(fā)送位碼syn＝1,隨機(jī)產(chǎn)生seq number=3626544836的數(shù)據(jù)包到192.168.1.123,由SYN=1知道192.168.1.116要求建立聯(lián)機(jī);
• IP 192.168.1.123.7788 > 192.168.1.116.3337: S 1739326486: ack 3626544837
  第二次握手：192.168.1.123收到請求后要確認(rèn)聯(lián)機(jī)信息，向192.168.1.116發(fā)送ack number=3626544837,syn=1,ack=1,隨機(jī)產(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ù)器進(jìn)行三次握手簡歷TCP連接以后，當(dāng)數(shù)據(jù)傳送完畢，肯定要斷開TCP連接。那對于TCP的斷開，就是"4次揮手"。

• 1、客戶端(也可以是服務(wù)器)，設(shè)置Sequence Number和Acknowledgment Number，向服務(wù)器發(fā)送一個FIN報文段。此時客戶端進(jìn)入FIN_WAIT_1狀態(tài)；這表示客戶端沒有數(shù)據(jù)發(fā)送給主機(jī)了。
• 2、服務(wù)器收到客戶端發(fā)來的FIN報文段，向客戶端回一個ACK報文段，Acknowledgement Number為Sequence Number加1；客戶端進(jìn)入FIN_WAIT_2狀態(tài)，服務(wù)器進(jìn)入CLOSE_WAIT狀態(tài)；服務(wù)器告訴客戶端，我同意你的"關(guān)閉"請求。
• 3、服務(wù)器向客戶端發(fā)送FIN報文段，請求關(guān)閉連接，同時服務(wù)器進(jìn)入LAST_ACK狀態(tài)。
• 4、客戶端收到服務(wù)器發(fā)送的FIN報文段，向主機(jī)發(fā)送ACK報文段，然后客戶端進(jìn)入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次就可以了。在謝希仁的<計(jì)算機(jī)網(wǎng)絡(luò)>中是這樣說的

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

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

“已失效的連接請求報文段”的產(chǎn)生在這樣一種情況下：client發(fā)出的第一個連接請求報文段并沒有丟失，而是在某個網(wǎng)絡(luò)結(jié)點(diǎn)長時間的滯留了，以致延誤到連接釋放以后的某個時間才到達(dá)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卻以為新的運(yùn)輸連接已經(jīng)建立，并一直等待client發(fā)來數(shù)據(jù)。這樣，server的很多資源就白白浪費(fèi)掉了。采用“三次握手”的辦法可以防止上述現(xiàn)象發(fā)生。例如剛才那種情況，client不會向server的確認(rèn)發(fā)出確認(rèn)。server由于收不到確認(rèn)，就知道client并沒有要求建立連接。”

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

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

TCP協(xié)議是一種面向連接的、可靠的、基于字節(jié)流的運(yùn)輸層通信協(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)要好好解釋一下，其實(shí)FIN_WAIT_1和FIN_WAIT_2狀態(tài)的真正含義都是表示等待對方的FIN報文。而這兩種狀態(tài)的區(qū)別：FIN_WAIT_1狀態(tài)實(shí)際上是當(dāng)SOCKET在ESTABLISHED狀態(tài)時，它想主動關(guān)閉連接，向?qū)Ψ桨l(fā)送了FIN報文，此時該SOCKET即進(jìn)入FIN_WAIT_1狀態(tài)。而當(dāng)對方回應(yīng)ACK報文后，則進(jìn)入FIN_WAIT_2狀態(tài)，當(dāng)然在實(shí)際的正常情況下，無論對方何種情況下，都應(yīng)該馬上回應(yīng)ACK報文，所以FIN_WAIT_1狀態(tài)一般是比較難見到的，而FIN_WAIT_2狀態(tài)還有時常?？煽吹?。
• 2、FIN_WAIT_2:上面已經(jīng)詳細(xì)解釋了這種狀態(tài)，實(shí)際上 FIN_WAIT_2狀態(tài)下的SOCKET，表示半連接，既有一方要求close連接，但另外還告訴對方，我暫時還有點(diǎn)數(shù)據(jù)需要傳送給你(ACK信息)，稍后再關(guān)閉連接
• 3、CLOSE_WAIT_2:這種狀態(tài)的含義其實(shí)表示在等待關(guān)閉。怎么理解？當(dāng)對方close一個SOCKET后發(fā)送一個FIN報文給自己，服務(wù)器系統(tǒng)毫無疑問會回應(yīng)一個ACK報文給對方，此時則進(jìn)入到CLOSE_WAIT狀態(tài)。接下來呢，實(shí)際上你真正需要考慮的事情是查看你是否還有數(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報文后，也可以進(jìn)入CLOSED狀態(tài)了。
• 5、CLOSED:表示連接中斷
• 6、TIME_WAIT:表示收到對方的FIN報文，并發(fā)出了ACK報文就等2MSL后即可會到CLOSED可用狀態(tài)了。如果FIN_WAIT_1下，收到了對方同時帶FIN標(biāo)志和ACK標(biāo)志的報文時，可以直接進(jìn)入到TIME_WAIT狀態(tài)，而無須經(jīng)過FIN_WAIT_2狀態(tài)。

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

雖然按道理，四個報文都發(fā)送完畢，我們可以直接進(jìn)入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肯定是彌補(bǔ)的HTTP的安全缺陷，那么咱們來看下HTTP協(xié)議的那些安全缺點(diǎn)：
1、通信使用明文(不加密)，內(nèi)容可能被竊聽(抓包工具可以獲取請求和響應(yīng)內(nèi)容)如下圖：

缺陷1.png

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

缺陷2.png

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

缺陷3.png

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

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

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

(三)、HTTPS的缺點(diǎn)

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

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

1、HTTP與HTTPS的相同點(diǎn)：
大多數(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的不同點(diǎn)：

• 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)建的，可進(jìn)行加密傳輸、身份認(rèn)證的網(wǎng)絡(luò)協(xié)議，比HTTP協(xié)議安全。

(五)、簡單說點(diǎn)加密和證書的事

再詳細(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ù)字摘要是采用單項(xiàng)Hash函數(shù)將需要加密的明文"摘要"成一串固定長度(128位)的密文，這一串密文又稱為數(shù)字指紋，它有固定的長度，而且不同的明文摘要成密文，其結(jié)果總是不同的，而同樣的明文摘要必定一定?！皵?shù)字摘要”是https能確保數(shù)據(jù)完整性和防篡改的根本原因。常用的摘要主要有MD5、SHA1、SHA256等。

3、數(shù)字簽名

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

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

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

• 1、能確定消息確實(shí)由發(fā)送方簽名并發(fā)出來的，因?yàn)閯e人假冒不了發(fā)送方的簽名。
• 2、數(shù)字簽名能確定消息的完整性。

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

4、數(shù)字證書

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

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

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

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

• 防偽造證書1:如果證書頒發(fā)機(jī)構(gòu)是偽造的，瀏覽器不認(rèn)識，直接認(rèn)為是危險證書
• 防偽造證書2:證書頒發(fā)機(jī)構(gòu)是的確存在的，于是根據(jù)CA名，找到對應(yīng)內(nèi)置的CA根證書、CA的公鑰。用CA的公鑰，對偽造的證書的摘要進(jìn)行解密，發(fā)現(xiàn)解密不了，認(rèn)為是危險證書
• 防篡改:對于篡改的證書，使用CA的公鑰對數(shù)字簽名進(jìn)行解密得到摘要A，然后再根據(jù)簽名的Hash算法計(jì)算出證書的摘要B，對比A與B，若相等則正常，若不相等則是被篡改過的。
• 防過期失效驗(yàn)證:正式課在其過期前輩吊銷，通常情況是該證書的私鑰已經(jīng)失密。較新的瀏覽器如果Chrome、Firefox、Opera和Internet Explored 都實(shí)現(xiàn)了在線證書的狀態(tài)協(xié)議(OCSP)以排除這種情況:瀏覽器將網(wǎng)站提供的證書序列號通過OCSP發(fā)送給證書頒發(fā)機(jī)構(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ù)之前要進(jìn)行加密

(七)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í)際的數(shù)據(jù)傳輸開始前，通訊雙方進(jìn)行身份認(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ù)中途被竊取
• 維護(hù)數(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、增強(qiáng)的偽隨機(jī)功能(PRF):PRF生成密鑰數(shù)據(jù)。在TLS中，HMAC定義PRF。PRF使用兩種散列算法保證其安全性，如果任一算法暴露了，只要第二種算法未暴露，則數(shù)據(jù)仍然是安全的。
• 3、改進(jìn)的已完成消息驗(yàn)證：TLS和SSLv3.0都對兩個端點(diǎn)提供已完成的消息，該消息認(rèn)證交換的消息沒有被變更。然而，TLS將此已完成消息基于PRF和
• 4、一致證書處理：與SSLv3.0不同，TLS試圖制定必須在TLS之間實(shí)現(xiàn)交互的證書類型。
• 5、特定警報消息：TLS提供更多的特定和附加警報，以指示任一會話端點(diǎn)檢測到的問題。TLS還對核實(shí)應(yīng)該發(fā)送某些警報進(jìn)行記錄。

(八)HTTPS握手的過程

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

握手.png

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

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

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

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

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

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

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

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

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

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

4、客戶端驗(yàn)證證書

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

5、客戶端傳送加密信息

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

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

6、生成會話密鑰

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

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

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

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

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

8 客戶端解密

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

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

注意事項(xiàng)

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

(九)HTTPS與代理

2.4 如何使用代理（charles）
我們知道從HTTPS的整個原理可以知道，客戶端和服務(wù)器進(jìn)行通信的成果，客戶端是能拿到數(shù)據(jù)的，代理也一定能拿到，包括公共密鑰，證書，算法等，但代理無法獲取服務(wù)器的私鑰，所以無法獲取5/6/7/8的會話密鑰，也就無法得到數(shù)據(jù)傳輸?shù)拿魑?，所以默認(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兩者有點(diǎn)于一體的傳輸協(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的升級版(其實(shí)也是基于SPDY設(shè)計(jì)的)，但是HTTP2.0跟SPDY仍有不同的地方，主要有以下兩點(diǎn)：

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

(二)、 HTTP2.0的新特性

• 1、新的二進(jìn)制格式(Binary Format)：HTTP 1.x的解析是基于文本?；谖谋鞠匆碌母袷浇馕龃嬖谔烊蝗毕?，文本的表現(xiàn)形式有多樣性，要做到健壯性考慮的場景必然很多，二進(jìn)制則不同，只認(rèn)0和1的組合，基于這種考慮HTTP2.0的協(xié)議解析決定采用二進(jìn)制分幀格式，實(shí)現(xiàn)方便且健壯。
• 2、多路復(fù)用(multiPlexing)：即連接共享，即每一個request都是用作連接共享機(jī)制的。一個request對應(yīng)一個id，這樣一個連接上可以有多個requst，每個連接的request可以隨機(jī)的混雜在一起，接受方可以根據(jù)request的id將request再歸屬到各自不同的服務(wù)端請求里面，后面有一張多路復(fù)用原理圖
• 3、請求優(yōu)先級：把HTTP消息分解為很多獨(dú)立的幀后，就可以通過優(yōu)化這些幀的交錯和傳輸順序，進(jìn)一步提供性能。為了做到這一點(diǎn)，每個流都有一個帶有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性能增強(qiáng)的核心，全在于新增的二進(jìn)制分幀層，它定義了如何封裝HTTP消息并在客戶端與服務(wù)器之間傳輸

二進(jìn)制分幀層.png

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

• 1、數(shù)據(jù)流：基于TCP連接之上的邏輯雙向字節(jié)流，對應(yīng)一個請求及響應(yīng)?？蛻舳嗣堪l(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消息分分解為多個獨(dú)立的幀后可以交錯發(fā)送，從而在宏觀上實(shí)現(xiàn)了多個請求或者響應(yīng)并行傳輸?shù)男Ч＿@類似于多進(jìn)程環(huán)境下的時間分片機(jī)制。

所有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ā)送多個平行的請求以及改進(jìn)性能，必須使用多個TCP連接。HTTP2.0的二進(jìn)制分幀層突破了限制；客戶端和服務(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)建一條到達(dá)任一目的服務(wù)器和端口的TCP連接，并對客戶端和服務(wù)器職期間的后續(xù)數(shù)據(jù)進(jìn)行盲轉(zhuǎn)發(fā)。
下圖顯示了CONNECT方法如何建立起一條到達(dá)網(wǎng)管的隧道，來自《HTTP 權(quán)威指南》

如何建立隧道.png

• 1、(a)是客戶端相互發(fā)送了額一條CONNECT請求給隧道網(wǎng)關(guān)?？蛻舳说腃ONNECT方法請求隧道網(wǎng)關(guān)打開一條TCP連接(在這里，打開的是到主機(jī)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方法類似。一個后面跟著冒號和端口號的主機(jī)名取代了請求的URL。主機(jī)和端口都必須制定:

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é)進(jìn)行轉(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)備就緒時，將與首部一同讀進(jìn)來的數(shù)據(jù)發(fā)送給服務(wù)器。在請求之后，或者其他非200但不致命的錯誤狀態(tài)，就必須做好重發(fā)請求數(shù)據(jù)的準(zhǔn)備。如果在任意時刻，隧道的任意一個端點(diǎn)斷開連接，那個端點(diǎn)發(fā)出的所有未傳輸數(shù)據(jù)都會被傳送給另一個端點(diǎn)，之后到另一個端點(diǎn)的鏈接也會被代理終止。如果還有數(shù)據(jù)要傳輸給關(guān)閉連接的端點(diǎ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)存的代理防火墻進(jìn)行傳輸，HTTP中添加了一項(xiàng)隧道特性，在此特性中，可以將原始的加密數(shù)據(jù)放在HTTP報文中，通過普通的HTTP信道傳送。

ssl隧道.png

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

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

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

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

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

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

隧道.png

總的來說，隧道網(wǎng)管無法驗(yàn)證目前使用的協(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ò)中間的實(shí)體，提供各式各樣的功能。現(xiàn)在網(wǎng)絡(luò)系統(tǒng)中，Web代理無處不在。

(一)代理的作用

• 1、提高訪問速度。因?yàn)榭蛻舳艘蟮臄?shù)據(jù)存于代理服務(wù)器的硬盤中，因此下次這個客戶端或者其他要求相同的站點(diǎn)數(shù)據(jù)時，就會直接從代理服務(wù)器的硬盤中讀取，代理服務(wù)器起到了緩存的作用，對熱門站點(diǎn)有很多客戶訪問時，代理服務(wù)器的優(yōu)勢更為明顯。
• 2、Proxy可以起到防火墻的作用，因?yàn)樗写矸?wù)器的用戶都必須通過代理服務(wù)器訪問遠(yuǎn)程站點(diǎ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ù)器，就能實(shí)現(xiàn)訪問因特網(wǎng)，這就是高校內(nèi)代理服務(wù)器熱的原因。
• 4、安全性得到提高。無論在上聊天室還是瀏覽網(wǎng)站，目標(biāo)網(wǎng)站只知道你來自代理服務(wù)器，而你的真實(shí)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ù)器進(jìn)行查詢，從而達(dá)到節(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方式實(shí)現(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。實(shí)際上這種代理早就被廣泛實(shí)現(xiàn)。

PS:事實(shí)上，第一種代理，對應(yīng)<HTTP權(quán)威指南>一書中第六章"代理"，第二種代理，對應(yīng)第八章"集成點(diǎn)：網(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)做客戶端，完全察覺不到真正的客戶端的存在，這實(shí)現(xiàn)了隱藏客戶端IP的目的，當(dāng)然代理也可以修改HTTP請求頭部，通過X-Forwarded-IP這楊的自定義頭部告訴服務(wù)器真正的客戶端IP。但服務(wù)器無法驗(yàn)證這個自定義頭部真的是由代理添加，還是客戶端修改了請求頭，所以從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)站時，實(shí)際上訪問的是代理，代理收到請求報文后，再向真正提供服務(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)建一條到達(dá)任意目的服務(wù)器和端口的TCP連接，并對客戶端和服務(wù)器之間的后繼數(shù)據(jù)進(jìn)行盲轉(zhuǎn)發(fā)。
具體請查看本片文章第五部分

這里將HTTP隧道分為兩種：

• 1、不使用CONNECT的隧道
  不實(shí)用CONNECT的隧道，實(shí)現(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進(jìn)行解析，然后重新組裝Resposne，發(fā)送給客戶端。所以在不使用CONNECT方式建立的隧道，Proxy有機(jī)會對客戶端與目標(biāo)服務(wù)器之間的通信數(shù)據(jù)進(jìn)行窺探，而且有機(jī)會對數(shù)據(jù)進(jìn)行串改。
• 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僅僅實(shí)現(xiàn)轉(zhuǎn)發(fā)，而不會關(guān)心轉(zhuǎn)發(fā)的數(shù)據(jù)，這也就是為什么在使用Proxy的時候，HTTPS請求必須首先使用HTTP CONNECT建立隧道。因?yàn)镠TTPS的數(shù)據(jù)都是經(jīng)過加密的，Proxy是無法對HTTPS的數(shù)據(jù)進(jìn)行解密的，所只能使用CONNECT，僅僅對通信數(shù)據(jù)進(jìn)行轉(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ù)器實(shí)際上充當(dāng)了匿名服務(wù)提供者的角色，如果連接的原始IP地址不可得，惡意訪問的檢查與預(yù)防的難度將大大增加
• X-Forwarded-Host和X-Forwarded-Proto分別記錄客戶端最原始的主機(jī)和協(xié)議
• Proxy-Authorization:連接到Proxy的身份驗(yàn)證信息
• Proxy-connection:它不是標(biāo)準(zhǔn)協(xié)議的一部分，標(biāo)準(zhǔn)些協(xié)議中已經(jīng)存在一種機(jī)制可以完成此協(xié)議頭的功能，這就是Connection頭域，與Proxy-Connection頭相比，Connection協(xié)議頭幾乎提供了相同的功能，除了錯誤部分。而且，Connection協(xié)議頭可用于任意連接之間，包括HTTP服務(wù)器，代理，客戶端，而不是像Proxy-Connection一樣，只能用于代理服務(wù)器和客戶端之間。

八、InetAddress類和InetSocketAddress類

(一)、InetAddress(IP地址)

InetAddress是IP地址(也是主機(jī)地址)類封裝計(jì)算機(jī)的IP地址和DNS，不包含端口。

1、如何獲取對象:

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

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

注：主機(jī)名既可以是域名，也可以是IP地址的字符串形式。例如，

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

2、方法

• String toString():返回"主機(jī)名/IP地址"字符串
• String getHostName() :返回此IP地址的主機(jī)名
• byte[] getAddress():返回此IP地址的各個字節(jié)，高字節(jié)放在地索引處
• String getHostAddress():返回此IP地址的字符串形式
• Boolea isReachable(int timeout):測試此IP地址的可達(dá)性，最多等待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ù)主機(jī)名和端口號創(chuàng)建端口地址。函數(shù)會訪問DNS服務(wù)器來解析出host和IP地址的，如果解析失敗，則標(biāo)記為"未解析"
• InetSocketAddress createUnresolved(String host,int port):同上，但是不會訪問DNS服務(wù)器去解析主機(jī)名，而是直接標(biāo)記為"未解析"。

2、方法

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

(三)、兩者的卻別

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

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