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的具體狀態圖可參考：