HTTPS工做原理和TCP握手機制

轉自http://blog.jobbole.com/105633/

原文出處：http://www.cnblogs.com/ttltry-air/archive/2012/08/20/2647898.html

一、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協議安全。

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

一、創建鏈接協議（三次握手）

（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端一直等待，浪費資源。

二、鏈接終止協議（四次揮手）

因爲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那些事（一）HTTPS原理
• 二、HTTP協議詳解
• 三、Wiki：TCP
• 四、HTTP協議及其POST與GET操做差別