TCP協議三次握手、四次揮手

TCP的概述

TCP 把鏈接做爲最基本的對象，每一條 TCP 鏈接都有兩個端點，這種斷點咱們叫做套接字（socket），它的定義爲端口號拼接到 IP 地址即構成了套接字，例如，若 IP 地址爲 192.3.4.16  而端口號爲 80，那麼獲得的套接字爲 192.3.4.16:80 。

但凡是基於 TCP 協議通訊的，在通訊以前，客戶端與服務端之間都會在邏輯層面上創建一個雙向通路。注意這裏是邏輯層面上，在物理層面上僅僅只是一條通訊的介質。

假設在 A、B 之間修路，我如今在 A 點，我要告訴 B，「我要修一條到你那的路了」，B 贊成了，因而路修好了。但這隻能是 A 到 B，你不能逆向行駛，因此還要修一條從 B 到 A 的，這時就是 B 告訴 A，「我也要修一條到你那的路」，A 贊成了，這才修好了一個雙向通路。

上面就是四次請求或應答創建的鏈接，可是在網絡中，B的贊成和請求是做爲一條路線的。由於一個軟件的效率的高低取決於最慢的點，A 和 B 構成的軟件若是基於 TCP 通訊，衡量這個軟件的執行效率是A和B以及網絡整體的效率，而網絡偏偏是最慢的點。網絡延遲的時間受限於現有的物理水平沒法解決，而在程序開發中，網絡的傳輸次數必定是越少越好，次數越少，網絡延遲的總時間就越少。

其實 TCP 三次握手的目的就是爲了創建雙向通路從而傳輸數據，然而此時沒有真正的數據在傳輸，TCP 三次握手是在爲傳輸數據作準備，因此要快速創建一個雙向通路，於是中間的兩次能夠做爲一次（由於這時沒有傳輸數據），這纔是真正的三次握手，之因此這樣引入是爲四次揮手斷鏈接作理解。

TCP報文首部

1）源端口和目的端口，各佔 2 個字節，分別寫入源端口和目的端口；

2）序號，佔 4 個字節，TCP鏈接中傳送的字節流中的每一個字節都按順序編號。例如，一段報文的序號字段值是 301 ，而攜帶的數據共有 100 字段，顯然下一個報文段（若是還有的話）的數據序號應該從 401 開始；

3）確認號，佔 4 個字節，是指望收到對方下一個報文的第一個數據字節的序號。例如，B 收到了 A 發送過來的報文，其序列號字段是 501，而數據長度是 200 字節，這代表B正確的收到了A發送的到序號 700 爲止的數據。所以，B 指望收到A的下一個數據序號是 701，因而 B 在發送給 A 的確認報文段中把確認號置爲 701 ；

4）數據偏移，佔 4 位，它指出 TCP 報文的數據距離 TCP 報文段的起始處有多遠；

5）保留，佔 6 位，保留從此使用，但目前應都位 0；

6）緊急 URG，當 URG=1，代表緊急指針字段有效。告訴系統此報文段中有緊急數據；

7）確認 ACK，僅當 ACK=1 時，確認號字段纔有效。TCP 規定，在鏈接創建後全部報文的傳輸都必須把 ACK 置 1；

8）推送 PSH，當兩個應用進程進行交互式通訊時，有時在一端的應用進程但願在鍵入一個命令後當即就能收到對方的響應，這時候就將 PSH=1 ；

9）復位 RST，當 RST=1 ，代表 TCP 鏈接中出現嚴重差錯，必須釋放鏈接，而後再從新創建鏈接；

10）同步 SYN，在鏈接創建時用來同步序號。當 SYN=1，ACK=0，代表是鏈接請求報文，若贊成鏈接，則響應報文中應該使 SYN=1，ACK=1；

11）終止 FIN，用來釋放鏈接。當 FIN=1，代表此報文的發送方的數據已經發送完畢，而且要求釋放；

12）窗口，佔 2 字節，指的是通知接收方，發送本報文你須要有多大的空間來接受；

13）檢驗和，佔 2 字節，校驗首部和數據這兩部分；

14）緊急指針，佔 2 字節，指出本報文段中的緊急數據的字節數；

15）選項，長度可變，定義一些其餘的可選的參數。

TCP創建鏈接的三次握手

最開始的時候客戶端和服務器都是處於 CLOSED 狀態。主動打開鏈接的爲客戶端，被動打開鏈接的是服務器。

1）TCP 服務器進程先建立傳輸控制塊 TCB，時刻準備接受客戶進程的鏈接請求，此時服務器就進入了 LISTEN（監聽）狀態；

2）TCP 客戶進程也是先建立傳輸控制塊 TCB，而後向服務器發出鏈接請求報文，這是報文首部中的同步位 SYN=1，同時選擇一個初始序列號 seq=x 。TCP規定，SYN 報文段（SYN=1 的報文段）不能攜帶數據，但須要消耗掉一個序號。此時，TCP 客戶端進程進入了 SYN-SENT（同步已發送狀態）狀態。

3）TCP 服務器收到請求報文後，若是贊成鏈接，則發出確認報文。確認報文中應該 ACK=1，SYN=1，確認號是ack=x+1，同時也要爲本身初始化一個序列號 seq=y，此時，TCP服務器進程進入了 SYN-RCVD（同步收到）狀態。這個報文也不能攜帶數據，可是一樣要消耗一個序號。

4）TCP 客戶進程收到確認後，還要向服務器給出確認。確認報文的 ACK=1，ack=y+1，本身的序列號 seq=x+1，此時，TCP 鏈接創建，客戶端進入 ESTABLISHED（已創建鏈接）狀態。TCP規定，ACK報文段能夠攜帶數據，可是若是不攜帶數據則不消耗序號。

5）當服務器收到客戶端的確認後也進入 ESTABLISHED 狀態，此後雙方就能夠開始通訊了。 

爲何TCP客戶端最後還要發送一次確認呢？

這主要是爲了防止已失效的鏈接請求報文段忽然又傳送到了服務端，於是產生錯誤。

假定客戶端發出的某一個鏈接請求報文段在傳輸的過程當中並無丟失，而是在某個網絡節點長時間滯留了，以至延誤到鏈接釋放之後的某個時間纔到達服務端。原本這是一個早已失效的報文段。但服務端收到此失效的鏈接請求報文段後，就誤覺得客戶端又發了一次新的鏈接請求，因而向客戶端發出確認報文段，贊成創建鏈接。假如不採用三次握手，那麼只要服務端發出確認，新的鏈接就創建了。

因爲客戶端並未發出創建鏈接的請求，所以不會理睬服務端的確認，也不會向服務端發送數據。但服務端卻覺得新的運輸鏈接已經創建了，並一直等待客戶端發來數據，所以白白浪費了許多資源。

採用TCP三次握手的方法能夠防止上述現象發生。例如在剛纔的狀況下，因爲客戶端不會向服務端的確認發出確認，服務端因爲收不到確認，就知道客戶端並無要求創建鏈接。

TCP釋放鏈接的四次揮手

如今 A、B 之間的雙向通路已經修好通車了，過了十年八年，路面須要翻修，可是要確保兩條路上的車都已走掉才能堵住路口，在 A 點，工人說我要設置路障了，而後通知 B 點獲得 B 的確認後才能設置路障，但這不能保證逆向車道也沒有車了，只有等 B 通知 A，A 收到消息後迴應了 B 才能設置路障，因此一共是走四道流程。

TCP 三次握手的目的是爲了創建雙向通路從而傳輸數據，當數據傳輸完畢後，雙方均可釋放鏈接。最開始的時候，客戶端和服務器都是處於 ESTABLISHED 狀態，而後客戶端主動關閉，服務器被動關閉。

1）客戶端進程發出鏈接釋放報文，而且中止發送數據。釋放數據報文首部，FIN=1，其序列號爲 seq=u（等於前面已經傳送過來的數據的最後一個字節的序號加1），此時，客戶端進入 FIN-WAIT-1（終止等待1）狀態，等待服務端的確認。

2）服務器收到鏈接釋放報文，發出確認報文，ACK=1，ack=u+1，而且帶上本身的序列號 seq=v，此時，服務端就進入了 CLOSE-WAIT（關閉等待）狀態。TCP服務器通知高層的應用進程，客戶端向服務器的方向就釋放了，這時候處於半關閉狀態，即客戶端已經沒有數據要發送了，可是服務器若發送數據，客戶端依然要接受。這個狀態還要持續一段時間，也就是整個 CLOSE-WAIT 狀態持續的時間。

3）客戶端收到服務器的確認請求後，此時，客戶端就進入 FIN-WAIT-2（終止等待2）狀態，等待服務器發送鏈接釋放報文（在這以前還須要接受服務器發送的最後的數據）。

4）服務器將最後的數據發送完畢後，就向客戶端發送鏈接釋放報文，FIN=1，ack=u+1，因爲在半關閉狀態，服務器極可能又發送了一些數據，假定此時的序列號爲 seq=w，此時，服務器就進入了 LAST-ACK（最後確認）狀態，等待客戶端的確認。

5）客戶端收到服務器的鏈接釋放報文後，必須發出確認，ACK=1，ack=w+1，而本身的序列號是 seq=u+1，此時，客戶端就進入了 TIME-WAIT（時間等待）狀態。注意此時 TCP 鏈接尚未釋放，必須通過 2MSL（最長報文段壽命）的時間後，當客戶端撤銷相應的 TCB 後，才進入 CLOSED 狀態。

6）服務器只要收到了客戶端發出的確認，當即進入 CLOSED 狀態。一樣，撤銷 TCB 後，就結束了此次的 TCP 鏈接。至此完成了 TCP 四次揮手斷開鏈接全過程。能夠看到，服務器結束 TCP 鏈接的時間要比客戶端早一些。

 爲何客戶端最後還要等待 2MSL ？

MSL（Maximum Segment Lifetime），TCP 容許不一樣的實現能夠設置不一樣的MSL值。

第一，保證客戶端發送的最後一個 ACK 報文可以到達服務器，由於這個 ACK 報文可能丟失，站在服務器的角度看來，我已經發送了 FIN+ACK 報文請求斷開了，客戶端尚未給我回應，應該是我發送的請求斷開報文它沒有收到，因而服務器又會從新發送一次，而客戶端就能在這個 2MSL 時間段內收到這個重傳的報文，接着給出迴應報文，而且會重啓2MSL計時器。

第二，防止相似與 「三次握手」 中提到了的 「已經失效的鏈接請求報文段」 出如今本鏈接中。客戶端發送完最後一個確認報文後，在這個 2MSL 時間中，就可使本鏈接持續的時間內所產生的全部報文段都從網絡中消失。這樣新的鏈接中不會出現舊鏈接的請求報文。

爲何創建鏈接是三次握手，關閉鏈接確是四次揮手呢？

創建鏈接的時候，服務器在 LISTEN 狀態下，收到創建鏈接請求的 SYN 報文後，把 ACK 和 SYN 放在一個報文裏發送給客戶端。
而關閉鏈接時，服務器收到對方的 FIN 報文時，僅僅表示對方再也不發送數據了可是還能接收數據，而本身也未必所有數據都發送給對方了，因此己方能夠當即關閉，也能夠發送一些數據給對方後，再發送 FIN 報文給對方來表示贊成如今關閉鏈接，所以，己方 ACK 和 FIN 通常都會分開發送，從而致使多了一次。

若是已經創建了鏈接，可是客戶端忽然出現故障了怎麼辦？

TCP 還設有一個保活計時器，顯然，客戶端若是出現故障，服務器不能一直等下去，白白浪費資源。服務器每收到一次客戶端的請求後都會從新復位這個計時器，時間一般是設置爲 2 小時，若兩小時尚未收到客戶端的任何數據，服務器就會發送一個探測報文段，之後每隔 75 分鐘發送一次。若一連發送 10 個探測報文仍然沒反應，服務器就認爲客戶端出了故障，接着就關閉鏈接。