HTTPS 工作原理和?TCP 握手機制

1、HTTPS的工作原理

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

1.瀏覽器將自己支持的一套加密規則發送給網站。

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

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

a) 驗證證書的合法性（頒發證書的機構是否合法，證書中包含的網站地址是否與正在訪問的地址一致等），如果證書受信任，則瀏覽器欄里面會顯示一個小鎖頭，否則會給出證書不受信的提示。

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

c) 使用約定好的HASH算法計算握手消息，并使用生成的隨機數對消息進行加密，最后將之前生成的所有信息發送給網站。

4.網站接收瀏覽器發來的數據之后要做以下的操作：

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

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

5.瀏覽器解密并計算握手消息的HASH，如果與服務端發來的HASH一致，此時握手過程結束，之后所有的通信數據將由之前瀏覽器生成的隨機密碼并利用對稱加密算法進行加密。

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

非對稱加密算法：RSA，DSA/DSS

對稱加密算法：AES，RC4，3DES

HASH算法：MD5，SHA1，SHA256

HTTPS對應的通信時序圖如下：

HTTPS協議和HTTP協議的區別： （具體HTTP協議的介紹可見參考資料2）

• https協議需要到ca申請證書，一般免費證書很少，需要交費。

• http是超文本傳輸協議，信息是明文傳輸，https 則是具有安全性的ssl加密傳輸協議。

• http和https使用的是完全不同的連接方式用的端口也不一樣,前者是80,后者是443。

• http的連接很簡單,是無狀態的 。

• HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網絡協議， 要比http協議安全。

2、TCP3次握手，4次揮手過程

1、建立連接協議（三次握手）

（1）客戶端發送一個帶SYN標志的TCP報文到服務器。這是三次握手過程中的報文1。

（2）服務器端回應客戶端的，這是三次握手中的第2個報文，這個報文同時帶ACK標志和SYN標志。因此它表示對剛才客戶端SYN報文的回應；同時又標志SYN給客戶端，詢問客戶端是否準備好進行數據通訊。

（3）客戶必須再次回應服務段一個ACK報文，這是報文段3。

為什么需要“三次握手”

在謝希仁著《計算機網絡》第四版中講“三次握手”的目的是“為了防止已失效的連接請求報文段突然又傳送到了服務端，因而產生錯誤”。在另一部經典的《計算機網絡》一書中講“三次握手”的目的是為了解決“網絡中存在延遲的重復分組”的問題。這兩種不用的表述其實闡明的是同一個問題。

謝希仁版《計算機網絡》中的例子是這樣的，“已失效的連接請求報文段”的產生在這樣一種情況下：client發出的第一個連接請求報文段并沒有丟失，而是在某個網絡結點長時間的滯留了，以致延誤到連接釋放以后的某個時間才到達server。本來這是一個早已失效的報文段。但server收到此失效的連接請求報文段后，就誤認為是client再次發出的一個新的連接請求。于是就向client發出確認報文段，同意建立連接。假設不采用“三次握手”，那么只要server發出確認，新的連接就建立了。由于現在client并沒有發出建立連接的請求，因此不會理睬server的確認，也不會向server發送數據。但server卻以為新的運輸連接已經建立，并一直等待client發來數據。這樣，server的很多資源就白白浪費掉了。采用“三次握手”的辦法可以防止上述現象發生。例如剛才那種情況，client不會向server的確認發出確認。server由于收不到確認，就知道client并沒有要求建立連接。”。 主要目的防止server端一直等待，浪費資源。

2、連接終止協議（四次揮手）

由于TCP連接是全雙工的，因此每個方向都必須單獨進行關閉。這原則是當一方完成它的數據發送任務后就能發送一個FIN來終止這個方向的連接。收到一個 FIN只意味著這一方向上沒有數據流動，一個TCP連接在收到一個FIN后仍能發送數據。首先進行關閉的一方將執行主動關閉，而另一方執行被動關閉。

（1） TCP客戶端發送一個FIN，用來關閉客戶到服務器的數據傳送（報文段4）。

（2） 服務器收到這個FIN，它發回一個ACK，確認序號為收到的序號加1（報文段5）。和SYN一樣，一個FIN將占用一個序號。

（3） 服務器關閉客戶端的連接，發送一個FIN給客戶端（報文段6）。

（4） 客戶段發回ACK報文確認，并將確認序號設置為收到序號加1（報文段7）。

為什么需要“四次揮手”

那可能有人會有疑問，在tcp連接握手時為何ACK是和SYN一起發送，這里ACK卻沒有和FIN一起發送呢。原因是因為tcp是全雙工模式，接收到FIN時意味將沒有數據再發來，但是還是可以繼續發送數據。

握手，揮手過程中各狀態介紹（詳見wiki：TCP）

3次握手過程狀態：

LISTEN: 這個也是非常容易理解的一個狀態，表示服務器端的某個SOCKET處于監聽狀態，可以接受連接了。

SYN_SENT: 當客戶端SOCKET執行CONNECT連接時，它首先發送SYN報文，因此也隨即它會進入到了SYN_SENT狀態，并等待服務端的發送三次握手中的第2個報文。SYN_SENT狀態表示客戶端已發送SYN報文。（發送端）

SYN_RCVD: 這個狀態與SYN_SENT遙想呼應這個狀態表示接受到了SYN報文，在正常情況下，這個狀態是服務器端的SOCKET在建立TCP連接時的三次握手會話過程中的一個中間狀態，很短暫，基本上用netstat你是很難看到這種狀態的，除非你特意寫了一個客戶端測試程序，故意將三次TCP握手過程中最后一個ACK報文不予發送。因此這種狀態時，當收到客戶端的ACK報文后，它會進入到ESTABLISHED狀態。（服務器端）

ESTABLISHED：這個容易理解了，表示連接已經建立了。

4次揮手過程狀態：（可參考上圖）

FIN_WAIT_1: 這個狀態要好好解釋一下，其實FIN_WAIT_1和FIN_WAIT_2狀態的真正含義都是表示等待對方的FIN報文。而這兩種狀態的區別是：FIN_WAIT_1狀態實際上是當SOCKET在ESTABLISHED狀態時，它想主動關閉連接，向對方發送了FIN報文，此時該SOCKET即進入到FIN_WAIT_1狀態。而當對方回應ACK報文后，則進入到FIN_WAIT_2狀態，當然在實際的正常情況下，無論對方何種情況下，都應該馬上回應ACK報文，所以FIN_WAIT_1狀態一般是比較難見到的，而FIN_WAIT_2狀態還有時常常可以用netstat看到。（主動方）

FIN_WAIT_2：上面已經詳細解釋了這種狀態，實際上FIN_WAIT_2狀態下的SOCKET，表示半連接，也即有一方要求close連接，但另外還告訴對方，我暫時還有點數據需要傳送給你(ACK信息)，稍后再關閉連接。（主動方）

TIME_WAIT: 表示收到了對方的FIN報文，并發送出了ACK報文，就等2MSL后即可回到CLOSED可用狀態了。如果FIN_WAIT_1狀態下，收到了對方同時帶FIN標志和ACK標志的報文時，可以直接進入到TIME_WAIT狀態，而無須經過FIN_WAIT_2狀態。（主動方）

CLOSING（比較少見）: 這種狀態比較特殊，實際情況中應該是很少見，屬于一種比較罕見的例外狀態。正常情況下，當你發送FIN報文后，按理來說是應該先收到（或同時收到）對方的ACK報文，再收到對方的FIN報文。但是CLOSING狀態表示你發送FIN報文后，并沒有收到對方的ACK報文，反而卻也收到了對方的FIN報文。什么情況下會出現此種情況呢？其實細想一下，也不難得出結論：那就是如果雙方幾乎在同時close一個SOCKET的話，那么就出現了雙方同時發送FIN報文的情況，也即會出現CLOSING狀態，表示雙方都正在關閉SOCKET連接。

CLOSE_WAIT: 這種狀態的含義其實是表示在等待關閉。怎么理解呢？當對方close一個SOCKET后發送FIN報文給自己，你系統毫無疑問地會回應一個ACK報文給對方，此時則進入到CLOSE_WAIT狀態。接下來呢，實際上你真正需要考慮的事情是察看你是否還有數據發送給對方，如果沒有的話，那么你也就可以close這個SOCKET，發送FIN報文給對方，也即關閉連接。所以你在CLOSE_WAIT狀態下，需要完成的事情是等待你去關閉連接。（被動方）

LAST_ACK: 這個狀態還是比較容易好理解的，它是被動關閉一方在發送FIN報文后，最后等待對方的ACK報文。當收到ACK報文后，也即可以進入到CLOSED可用狀態了。（被動方）

CLOSED: 表示連接中斷。

TCP的具體狀態圖可參考：

 

 

來自：https://mp.weixin.qq.com/s?__biz=MzAxODI5ODMwOA==&mid=2666539650&idx=1&sn=199de4bad945a618b101be1d1ca0338f&chksm=80dcee29b7ab673f81cf9ebe59e1015508265efc55ddd11f7d9e0bc4aee19300d39ac3f3ea0a&scene=0&key=&ascene=7&uin=&devicetype=android-23&version=26031933&nettype=WIFI