TCP和IP的三次握手和第四次揮手

TCP握手協議 
在TCP/IP協議中,TCP協議提供可靠的鏈接服務,採用三次握手創建一個鏈接.
第一次握手：創建鏈接時,客戶端發送syn包(syn=j)到服務器,並進入SYN_SEND狀態,等待服務器確認； 
SYN：同步序列編號(Synchronize Sequence Numbers)
第二次握手：服務器收到syn包,必須確認客戶的SYN（ack=j+1）,同時本身也發送一個SYN包（syn=k）,即SYN+ACK包,此時服務器進入SYN_RECV狀態； 
第三次握手：客戶端收到服務器的SYN＋ACK包,向服務器發送確認包ACK(ack=k+1),此包發送完畢,客戶端和服務器進入ESTABLISHED狀態,完成三次握手.

完成三次握手,客戶端與服務器開始傳送數據

 

 

A與B創建TCP鏈接時：首先A向B發SYN（同步請求），而後B回覆SYN+ACK（同步請求應答），最後A回覆ACK確認，這樣TCP的一次鏈接（三次握手）的過程就創建了！

 

 

 

 

1、TCP報文格式

        TCP/IP協議的詳細信息參看《TCP/IP協議詳解》三卷本。下面是TCP報文格式圖：

圖1 TCP報文格式

        上圖中有幾個字段須要重點介紹下：
        （1）序號：Seq序號，佔32位，用來標識從TCP源端向目的端發送的字節流，發起方發送數據時對此進行標記。
        （2）確認序號：Ack序號，佔32位，只有ACK標誌位爲1時，確認序號字段纔有效，Ack=Seq+1。
        （3）標誌位：共6個，即URG、ACK、PSH、RST、SYN、FIN等，具體含義以下：
                （A）URG：緊急指針（urgent pointer）有效。
                （B）ACK：確認序號有效。
                （C）PSH：接收方應該儘快將這個報文交給應用層。
                （D）RST：重置鏈接。
                （E）SYN：發起一個新鏈接。
                （F）FIN：釋放一個鏈接。

        須要注意的是：
                （A）不要將確認序號Ack與標誌位中的ACK搞混了。
                （B）確認方Ack=發起方Req+1，兩端配對。 

2、三次握手
        所謂三次握手（Three-Way Handshake）即創建TCP鏈接，就是指創建一個TCP鏈接時，須要客戶端和服務端總共發送3個包以確認鏈接的創建。在socket編程中，這一過程由客戶端執行connect來觸發，整個流程以下圖所示：

圖2 TCP三次握手

        （1）第一次握手：Client將標誌位SYN置爲1，隨機產生一個值seq=J，並將該數據包發送給Server，Client進入SYN_SENT狀態，等待Server確認。
        （2）第二次握手：Server收到數據包後由標誌位SYN=1知道Client請求創建鏈接，Server將標誌位SYN和ACK都置爲1，ack=J+1，隨機產生一個值seq=K，並將該數據包發送給Client以確認鏈接請求，Server進入SYN_RCVD狀態。
        （3）第三次握手：Client收到確認後，檢查ack是否爲J+1，ACK是否爲1，若是正確則將標誌位ACK置爲1，ack=K+1，並將該數據包發送給Server，Server檢查ack是否爲K+1，ACK是否爲1，若是正確則鏈接創建成功，Client和Server進入ESTABLISHED狀態，完成三次握手，隨後Client與Server之間能夠開始傳輸數據了。
        
        SYN攻擊：
                在三次握手過程當中，Server發送SYN-ACK以後，收到Client的ACK以前的TCP鏈接稱爲半鏈接（half-open connect），此時Server處於SYN_RCVD狀態，當收到ACK後，Server轉入ESTABLISHED狀態。SYN攻擊就是Client在短期內僞造大量不存在的IP地址，並向Server不斷地發送SYN包，Server回覆確認包，並等待Client的確認，因爲源地址是不存在的，所以，Server須要不斷重發直至超時，這些僞造的SYN包將產時間佔用未鏈接隊列，致使正常的SYN請求由於隊列滿而被丟棄，從而引發網絡堵塞甚至系統癱瘓。SYN攻擊時一種典型的DDOS攻擊，檢測SYN攻擊的方式很是簡單，即當Server上有大量半鏈接狀態且源IP地址是隨機的，則能夠判定遭到SYN攻擊了，使用以下命令可讓之現行：
                #netstat -nap | grep SYN_RECV

3、四次揮手
         三次握手耳熟能詳，四次揮手估計就，所謂四次揮手（Four-Way Wavehand）即終止TCP鏈接，就是指斷開一個TCP鏈接時，須要客戶端和服務端總共發送4個包以確認鏈接的斷開。在socket編程中，這一過程由客戶端或服務端任一方執行close來觸發，整個流程以下圖所示：

圖3 TCP四次揮手

        因爲TCP鏈接時全雙工的，所以，每一個方向都必需要單獨進行關閉，這一原則是當一方完成數據發送任務後，發送一個FIN來終止這一方向的鏈接，收到一個FIN只是意味着這一方向上沒有數據流動了，即不會再收到數據了，可是在這個TCP鏈接上仍然可以發送數據，直到這一方向也發送了FIN。首先進行關閉的一方將執行主動關閉，而另外一方則執行被動關閉，上圖描述的便是如此。
        （1）第一次揮手：Client發送一個FIN，用來關閉Client到Server的數據傳送，Client進入FIN_WAIT_1狀態。
        （2）第二次揮手：Server收到FIN後，發送一個ACK給Client，確認序號爲收到序號+1（與SYN相同，一個FIN佔用一個序號），Server進入CLOSE_WAIT狀態。
        （3）第三次揮手：Server發送一個FIN，用來關閉Server到Client的數據傳送，Server進入LAST_ACK狀態。
        （4）第四次揮手：Client收到FIN後，Client進入TIME_WAIT狀態，接着發送一個ACK給Server，確認序號爲收到序號+1，Server進入CLOSED狀態，完成四次揮手。
        上面是一方主動關閉，另外一方被動關閉的狀況，實際中還會出現同時發起主動關閉的狀況，具體流程以下圖：

圖4 同時揮手

        流程和狀態在上圖中已經很明瞭了，在此再也不贅述，能夠參考前面的四次揮手解析步驟。

4、附註
        關於三次握手與四次揮手一般都會有典型的面試題，在此提出供有需求的XDJM們參考：
        （1）三次握手是什麼或者流程？四次握手呢？答案前面分析就是。
        （2）爲何創建鏈接是三次握手，而關閉鏈接倒是四次揮手呢？
        這是由於服務端在LISTEN狀態下，收到創建鏈接請求的SYN報文後，把ACK和SYN放在一個報文裏發送給客戶端。而關閉鏈接時，當收到對方的FIN報文時，僅僅表示對方再也不發送數據了可是還能接收數據，己方也未必所有數據都發送給對方了，因此己方能夠當即close，也能夠發送一些數據給對方後，再發送FIN報文給對方來表示贊成如今關閉鏈接，所以，己方ACK和FIN通常都會分開發送

 

 

複雜點說

TCP(Transmission Control Protocol)　傳輸控制協議

TCP是主機對主機層的傳輸控制協議，提供可靠的鏈接服務，採用三次握手確認創建一個鏈接:

位碼即tcp標誌位,

有6種標示:

SYN(synchronous創建聯機)

ACK(acknowledgement 確認)

PSH(push傳送)

FIN(finish結束)

RST(reset重置)

URG(urgent緊急)

Sequence number(順序號碼)

Acknowledge number(確認號碼)

第一次握手：主機A發送位碼爲syn＝1,隨機產生seq number=1234567的數據包到服務器，主機B由SYN=1知道，A要求創建聯機；

第二次握手：主機B收到請求後要確認聯機信息，向A發送ack number=(主機A的seq+1),syn=1,ack=1,隨機產生seq=7654321的包

第三次握手：主機A收到後檢查ack number是否正確，即第一次發送的seq number+1,以及位碼ack是否爲1，若正確，主機A會再發送ack number=(主機B的seq+1),ack=1，主機B收到後確認seq值與ack=1則鏈接創建成功。

完成三次握手，主機A與主機B開始傳送數據。

在TCP/IP協議中，TCP協議提供可靠的鏈接服務，採用三次握手創建一個鏈接。

第一次握手：創建鏈接時，客戶端發送syn包(syn=j)到服務器，並進入SYN_SEND狀態，等待服務器確認；

第二次握手：服務器收到syn包，必須確認客戶的SYN（ack=j+1），同時本身也發送一個SYN包（syn=k），即SYN+ACK包，此時服務器 進入SYN_RECV狀態；

第三次握手：客戶端收到服務器的SYN＋ACK包，向服務器發送確認包ACK(ack=k+1)，此包發送完畢，客戶端和服務器進入 ESTABLISHED狀態，完成三次握手。 完成三次握手，客戶端與服務器開始傳送數據.

 

 

實例:

IP 192.168.1.116.3337 > 192.168.1.123.7788: S 3626544836:3626544836

IP 192.168.1.123.7788 > 192.168.1.116.3337: S 1739326486:1739326486 ack 3626544837

IP 192.168.1.116.3337 > 192.168.1.123.7788: ack 1739326487,ack 1

第一次握手：192.168.1.116發送位碼syn＝1,隨機產生seq number=3626544836的數據包到192.168.1.123,192.168.1.123由SYN=1知道192.168.1.116要求創建聯機;

第二次握手：192.168.1.123收到請求後要確認聯機信息，向192.168.1.116發送ack number=3626544837,syn=1,ack=1,隨機產生seq=1739326486的包;

第三次握手：192.168.1.116收到後檢查ack number是否正確，即第一次發送的seq number+1,以及位碼ack是否爲1，若正確，192.168.1.116會再發送ack number=1739326487,ack=1，192.168.1.123收到後確認seq=seq+1,ack=1則鏈接創建成功。

一個完整的三次握手也就是 請求---應答---再次確認

四次分手：

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

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

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

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

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

 

 

1．爲何創建鏈接協議是三次握手，而關閉鏈接倒是四次握手呢？

這是由於服務端的LISTEN狀態下的SOCKET當收到SYN報文的建連請求後，它能夠把ACK和SYN（ACK起應答做用，而SYN起同步做用）放在一個報文裏來發送。但關閉鏈接時，當收到對方的FIN報文通知時，它僅僅表示對方沒有數據發送給你了；但未必你全部的數據都所有發送給對方了，因此你能夠未必會立刻會關閉SOCKET,也即你可能還須要發送一些數據給對方以後，再發送FIN報文給對方來表示你贊成如今能夠關閉鏈接了，因此它這裏的ACK報文和FIN報文多數狀況下都是分開發送的。

2．爲何TIME_WAIT狀態還須要等2MSL後才能返回到CLOSED狀態？

這是由於雖然雙方都贊成關閉鏈接了，並且握手的4個報文也都協調和發送完畢，按理能夠直接回到CLOSED狀態（就比如從SYN_SEND狀態到ESTABLISH狀態那樣）；可是由於咱們必需要假想網絡是不可靠的，你沒法保證你最後發送的ACK報文會必定被對方收到，所以對方處於LAST_ACK狀態下的SOCKET可能會由於超時未收到ACK報文，而重發FIN報文，因此這個TIME_WAIT狀態的做用就是用來重發可能丟失的ACK報文。

簡單點說：

在TCP/IP協議中,TCP協議提供可靠的鏈接服務,採用三次握手創建一個鏈接.

第一次握手：創建鏈接時,客戶端發送syn包(syn=j)到服務器,並進入SYN_SEND狀態,等待服務器確認；

SYN：同步序列編號(Synchronize Sequence Numbers)

第二次握手：服務器收到syn包,必須確認客戶的SYN（ack=j+1）,同時本身也發送一個SYN包（syn=k）,即SYN+ACK包,此時服務器進入SYN_RECV狀態；

第三次握手：客戶端收到服務器的SYN＋ACK包,向服務器發送確認包ACK(ack=k+1),此包發送完畢,客戶端和服務器進入ESTABLISHED狀態,完成三次握手.

完成三次握手,客戶端與服務器開始傳送數據

再簡單點說：

A與B創建TCP鏈接時：首先A向B發SYN（同步請求），而後B回覆SYN+ACK（同步請求應答），最後A回覆ACK確認，這樣TCP的一次鏈接（三次握手）的過程就創建了！

做者：Levan_li 連接：https://www.jianshu.com/p/092705233d37 來源：簡書 簡書著做權歸做者全部，任何形式的轉載都請聯繫做者得到受權並註明出處。