1、HTTPS的工作原理

?

HTTPS在傳輸數(shù)據(jù)之前需要客戶端（瀏覽器）與服務(wù)端（網(wǎng)站）之間進(jìn)行一次握手，在握手過(guò)程中將確立雙方加密傳輸數(shù)據(jù)的密碼信息。TLS/SSL協(xié)議不僅僅是一套加密傳輸?shù)膮f(xié)議，更是一件經(jīng)過(guò)藝術(shù)家精心設(shè)計(jì)的藝術(shù)品，TLS/SSL中使用了非對(duì)稱加密，對(duì)稱加密以及HASH算法。握手過(guò)程的具體描述如下：

?

1.瀏覽器將自己支持的一套加密規(guī)則發(fā)送給網(wǎng)站。

?

2.網(wǎng)站從中選出一組加密算法與HASH算法，并將自己的身份信息以證書的形式發(fā)回給瀏覽器。證書里面包含了網(wǎng)站地址，加密公鑰，以及證書的頒發(fā)機(jī)構(gòu)等信息。

?

3.瀏覽器獲得網(wǎng)站證書之后瀏覽器要做以下工作：

?

a) 驗(yàn)證證書的合法性（頒發(fā)證書的機(jī)構(gòu)是否合法，證書中包含的網(wǎng)站地址是否與正在訪問(wèn)的地址一致等），如果證書受信任，則瀏覽器欄里面會(huì)顯示一個(gè)小鎖頭，否則會(huì)給出證書不受信的提示。

b) 如果證書受信任，或者是用戶接受了不受信的證書，瀏覽器會(huì)生成一串隨機(jī)數(shù)的密碼，并用證書中提供的公鑰加密。

c) 使用約定好的HASH算法計(jì)算握手消息，并使用生成的隨機(jī)數(shù)對(duì)消息進(jìn)行加密，最后將之前生成的所有信息發(fā)送給網(wǎng)站。

?

4.網(wǎng)站接收瀏覽器發(fā)來(lái)的數(shù)據(jù)之后要做以下的操作：

?

a) 使用自己的私鑰將信息解密取出密碼，使用密碼解密瀏覽器發(fā)來(lái)的握手消息，并驗(yàn)證HASH是否與瀏覽器發(fā)來(lái)的一致。

b) 使用密碼加密一段握手消息，發(fā)送給瀏覽器。

?

5.瀏覽器解密并計(jì)算握手消息的HASH，如果與服務(wù)端發(fā)來(lái)的HASH一致，此時(shí)握手過(guò)程結(jié)束，之后所有的通信數(shù)據(jù)將由之前瀏覽器生成的隨機(jī)密碼并利用對(duì)稱加密算法進(jìn)行加密。

?

這里瀏覽器與網(wǎng)站互相發(fā)送加密的握手消息并驗(yàn)證，目的是為了保證雙方都獲得了一致的密碼，并且可以正常的加密解密數(shù)據(jù)，為后續(xù)真正數(shù)據(jù)的傳輸做一次測(cè)試。另外，HTTPS一般使用的加密與HASH算法如下：

?

非對(duì)稱加密算法：RSA，DSA/DSS

對(duì)稱加密算法：AES，RC4，3DES

HASH算法：MD5，SHA1，SHA256

?

HTTPS對(duì)應(yīng)的通信時(shí)序圖如下：

?

?

HTTPS協(xié)議和HTTP協(xié)議的區(qū)別： （具體HTTP協(xié)議的介紹可見參考資料2）

?

• https協(xié)議需要到ca申請(qǐng)證書，一般免費(fèi)證書很少，需要交費(fèi)。
• http是超文本傳輸協(xié)議，信息是明文傳輸，https 則是具有安全性的ssl加密傳輸協(xié)議。
• http和https使用的是完全不同的連接方式用的端口也不一樣,前者是80,后者是443。
• http的連接很簡(jiǎn)單,是無(wú)狀態(tài)的 。
• HTTPS協(xié)議是由SSL+HTTP協(xié)議構(gòu)建的可進(jìn)行加密傳輸、身份認(rèn)證的網(wǎng)絡(luò)協(xié)議， 要比http協(xié)議安全。

2、TCP3次握手，4次揮手過(guò)程

?

1、建立連接協(xié)議（三次握手）

?

（1）客戶端發(fā)送一個(gè)帶SYN標(biāo)志的TCP報(bào)文到服務(wù)器。這是三次握手過(guò)程中的報(bào)文1。

?

（2）服務(wù)器端回應(yīng)客戶端的，這是三次握手中的第2個(gè)報(bào)文，這個(gè)報(bào)文同時(shí)帶ACK標(biāo)志和SYN標(biāo)志。因此它表示對(duì)剛才客戶端SYN報(bào)文的回應(yīng)；同時(shí)又標(biāo)志SYN給客戶端，詢問(wèn)客戶端是否準(zhǔn)備好進(jìn)行數(shù)據(jù)通訊。

?

（3）客戶必須再次回應(yīng)服務(wù)段一個(gè)ACK報(bào)文，這是報(bào)文段3。

?

為什么需要“三次握手”

?

在謝希仁著《計(jì)算機(jī)網(wǎng)絡(luò)》第四版中講“三次握手”的目的是“為了防止已失效的連接請(qǐng)求報(bào)文段突然又傳送到了服務(wù)端，因而產(chǎn)生錯(cuò)誤”。在另一部經(jīng)典的《計(jì)算機(jī)網(wǎng)絡(luò)》一書中講“三次握手”的目的是為了解決“網(wǎng)絡(luò)中存在延遲的重復(fù)分組”的問(wèn)題。這兩種不用的表述其實(shí)闡明的是同一個(gè)問(wèn)題。

?

謝希仁版《計(jì)算機(jī)網(wǎng)絡(luò)》中的例子是這樣的，“已失效的連接請(qǐng)求報(bào)文段”的產(chǎn)生在這樣一種情況下：client發(fā)出的第一個(gè)連接請(qǐng)求報(bào)文段并沒(méi)有丟失，而是在某個(gè)網(wǎng)絡(luò)結(jié)點(diǎn)長(zhǎng)時(shí)間的滯留了，以致延誤到連接釋放以后的某個(gè)時(shí)間才到達(dá)server。本來(lái)這是一個(gè)早已失效的報(bào)文段。但server收到此失效的連接請(qǐng)求報(bào)文段后，就誤認(rèn)為是client再次發(fā)出的一個(gè)新的連接請(qǐng)求。于是就向client發(fā)出確認(rèn)報(bào)文段，同意建立連接。假設(shè)不采用“三次握手”，那么只要server發(fā)出確認(rèn)，新的連接就建立了。由于現(xiàn)在client并沒(méi)有發(fā)出建立連接的請(qǐng)求，因此不會(huì)理睬server的確認(rèn)，也不會(huì)向server發(fā)送數(shù)據(jù)。但server卻以為新的運(yùn)輸連接已經(jīng)建立，并一直等待client發(fā)來(lái)數(shù)據(jù)。這樣，server的很多資源就白白浪費(fèi)掉了。采用“三次握手”的辦法可以防止上述現(xiàn)象發(fā)生。例如剛才那種情況，client不會(huì)向server的確認(rèn)發(fā)出確認(rèn)。server由于收不到確認(rèn)，就知道client并沒(méi)有要求建立連接。”。 主要目的防止server端一直等待，浪費(fèi)資源。

?

2、連接終止協(xié)議（四次揮手）

?

由于TCP連接是全雙工的，因此每個(gè)方向都必須單獨(dú)進(jìn)行關(guān)閉。這原則是當(dāng)一方完成它的數(shù)據(jù)發(fā)送任務(wù)后就能發(fā)送一個(gè)FIN來(lái)終止這個(gè)方向的連接。收到一個(gè) FIN只意味著這一方向上沒(méi)有數(shù)據(jù)流動(dòng)，一個(gè)TCP連接在收到一個(gè)FIN后仍能發(fā)送數(shù)據(jù)。首先進(jìn)行關(guān)閉的一方將執(zhí)行主動(dòng)關(guān)閉，而另一方執(zhí)行被動(dòng)關(guān)閉。

?

（1） TCP客戶端發(fā)送一個(gè)FIN，用來(lái)關(guān)閉客戶到服務(wù)器的數(shù)據(jù)傳送（報(bào)文段4）。

?

（2） 服務(wù)器收到這個(gè)FIN，它發(fā)回一個(gè)ACK，確認(rèn)序號(hào)為收到的序號(hào)加1（報(bào)文段5）。和SYN一樣，一個(gè)FIN將占用一個(gè)序號(hào)。

?

（3） 服務(wù)器關(guān)閉客戶端的連接，發(fā)送一個(gè)FIN給客戶端（報(bào)文段6）。

?

（4） 客戶段發(fā)回ACK報(bào)文確認(rèn)，并將確認(rèn)序號(hào)設(shè)置為收到序號(hào)加1（報(bào)文段7）。

?

?

為什么需要“四次揮手”

?

那可能有人會(huì)有疑問(wèn)，在tcp連接握手時(shí)為何ACK是和SYN一起發(fā)送，這里ACK卻沒(méi)有和FIN一起發(fā)送呢。原因是因?yàn)閠cp是全雙工模式，接收到FIN時(shí)意味將沒(méi)有數(shù)據(jù)再發(fā)來(lái)，但是還是可以繼續(xù)發(fā)送數(shù)據(jù)。

?

握手，揮手過(guò)程中各狀態(tài)介紹（詳見wiki：TCP）

?

3次握手過(guò)程狀態(tài)：

?

LISTEN: 這個(gè)也是非常容易理解的一個(gè)狀態(tài)，表示服務(wù)器端的某個(gè)SOCKET處于監(jiān)聽狀態(tài)，可以接受連接了。

?

SYN_SENT: 當(dāng)客戶端SOCKET執(zhí)行CONNECT連接時(shí)，它首先發(fā)送SYN報(bào)文，因此也隨即它會(huì)進(jìn)入到了SYN_SENT狀態(tài)，并等待服務(wù)端的發(fā)送三次握手中的第2個(gè)報(bào)文。SYN_SENT狀態(tài)表示客戶端已發(fā)送SYN報(bào)文。（發(fā)送端）

?

SYN_RCVD: 這個(gè)狀態(tài)與SYN_SENT遙想呼應(yīng)這個(gè)狀態(tài)表示接受到了SYN報(bào)文，在正常情況下，這個(gè)狀態(tài)是服務(wù)器端的SOCKET在建立TCP連接時(shí)的三次握手會(huì)話過(guò)程中的一個(gè)中間狀態(tài)，很短暫，基本上用netstat你是很難看到這種狀態(tài)的，除非你特意寫了一個(gè)客戶端測(cè)試程序，故意將三次TCP握手過(guò)程中最后一個(gè)ACK報(bào)文不予發(fā)送。因此這種狀態(tài)時(shí)，當(dāng)收到客戶端的ACK報(bào)文后，它會(huì)進(jìn)入到ESTABLISHED狀態(tài)。（服務(wù)器端）

?

ESTABLISHED：這個(gè)容易理解了，表示連接已經(jīng)建立了。

?

4次揮手過(guò)程狀態(tài)：（可參考上圖）

?

FIN_WAIT_1: 這個(gè)狀態(tài)要好好解釋一下，其實(shí)FIN_WAIT_1和FIN_WAIT_2狀態(tài)的真正含義都是表示等待對(duì)方的FIN報(bào)文。而這兩種狀態(tài)的區(qū)別是：FIN_WAIT_1狀態(tài)實(shí)際上是當(dāng)SOCKET在ESTABLISHED狀態(tài)時(shí)，它想主動(dòng)關(guān)閉連接，向?qū)Ψ桨l(fā)送了FIN報(bào)文，此時(shí)該SOCKET即進(jìn)入到FIN_WAIT_1狀態(tài)。而當(dāng)對(duì)方回應(yīng)ACK報(bào)文后，則進(jìn)入到FIN_WAIT_2狀態(tài)，當(dāng)然在實(shí)際的正常情況下，無(wú)論對(duì)方何種情況下，都應(yīng)該馬上回應(yīng)ACK報(bào)文，所以FIN_WAIT_1狀態(tài)一般是比較難見到的，而FIN_WAIT_2狀態(tài)還有時(shí)常常可以用netstat看到。（主動(dòng)方）

?

FIN_WAIT_2：上面已經(jīng)詳細(xì)解釋了這種狀態(tài)，實(shí)際上FIN_WAIT_2狀態(tài)下的SOCKET，表示半連接，也即有一方要求close連接，但另外還告訴對(duì)方，我暫時(shí)還有點(diǎn)數(shù)據(jù)需要傳送給你(ACK信息)，稍后再關(guān)閉連接。（主動(dòng)方）

TIME_WAIT: 表示收到了對(duì)方的FIN報(bào)文，并發(fā)送出了ACK報(bào)文，就等2MSL后即可回到CLOSED可用狀態(tài)了。如果FIN_WAIT_1狀態(tài)下，收到了對(duì)方同時(shí)帶FIN標(biāo)志和ACK標(biāo)志的報(bào)文時(shí)，可以直接進(jìn)入到TIME_WAIT狀態(tài)，而無(wú)須經(jīng)過(guò)FIN_WAIT_2狀態(tài)。（主動(dòng)方）

?

CLOSING（比較少見）: 這種狀態(tài)比較特殊，實(shí)際情況中應(yīng)該是很少見，屬于一種比較罕見的例外狀態(tài)。正常情況下，當(dāng)你發(fā)送FIN報(bào)文后，按理來(lái)說(shuō)是應(yīng)該先收到（或同時(shí)收到）對(duì)方的ACK報(bào)文，再收到對(duì)方的FIN報(bào)文。但是CLOSING狀態(tài)表示你發(fā)送FIN報(bào)文后，并沒(méi)有收到對(duì)方的ACK報(bào)文，反而卻也收到了對(duì)方的FIN報(bào)文。什么情況下會(huì)出現(xiàn)此種情況呢？其實(shí)細(xì)想一下，也不難得出結(jié)論：那就是如果雙方幾乎在同時(shí)close一個(gè)SOCKET的話，那么就出現(xiàn)了雙方同時(shí)發(fā)送FIN報(bào)文的情況，也即會(huì)出現(xiàn)CLOSING狀態(tài)，表示雙方都正在關(guān)閉SOCKET連接。

?

CLOSE_WAIT: 這種狀態(tài)的含義其實(shí)是表示在等待關(guān)閉。怎么理解呢？當(dāng)對(duì)方close一個(gè)SOCKET后發(fā)送FIN報(bào)文給自己，你系統(tǒng)毫無(wú)疑問(wèn)地會(huì)回應(yīng)一個(gè)ACK報(bào)文給對(duì)方，此時(shí)則進(jìn)入到CLOSE_WAIT狀態(tài)。接下來(lái)呢，實(shí)際上你真正需要考慮的事情是察看你是否還有數(shù)據(jù)發(fā)送給對(duì)方，如果沒(méi)有的話，那么你也就可以close這個(gè)SOCKET，發(fā)送FIN報(bào)文給對(duì)方，也即關(guān)閉連接。所以你在CLOSE_WAIT狀態(tài)下，需要完成的事情是等待你去關(guān)閉連接。（被動(dòng)方）

?

LAST_ACK: 這個(gè)狀態(tài)還是比較容易好理解的，它是被動(dòng)關(guān)閉一方在發(fā)送FIN報(bào)文后，最后等待對(duì)方的ACK報(bào)文。當(dāng)收到ACK報(bào)文后，也即可以進(jìn)入到CLOSED可用狀態(tài)了。（被動(dòng)方）

?

CLOSED: 表示連接中斷。

?

TCP的具體狀態(tài)圖可參考：

?

總結(jié)

以上是生活随笔為你收集整理的HTTPS 工作原理和 TCP 握手机制的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。