TCP的三次握手和四次揮手實質(zhì)就是TCP通信的連接和斷開。

三次握手：為了對每次發(fā)送的數(shù)據(jù)量進行跟蹤與協(xié)商，確保數(shù)據(jù)段的發(fā)送和接收同步，根據(jù)所接收到的數(shù)據(jù)量而確認數(shù)據(jù)發(fā)送、接收完畢后何時撤消聯(lián)系，并建立虛連接。

四次揮手：即終止TCP連接，就是指斷開一個TCP連接時，需要客戶端和服務端總共發(fā)送4個包以確認連接的斷開。

首先，要明白握手的目的是什么
可以將TCP雙向通信的過程，看成兩個單向通信過程的組合：
一次 “請求連接——確認”操作，可以確保一方做好了發(fā)送準備，另一方做好了接收準備，因此可以建議一個單向的連接；
一次 “請求關(guān)閉——確認”操作，可以確保一方發(fā)完了數(shù)據(jù)希望關(guān)閉發(fā)送，另一方收到請求關(guān)閉接收，最后關(guān)閉掉一個單向的連接。

在建立連接時，是為了判斷雙方是否能夠正常建立連接，即客戶端—>服務端、服務端->客戶端兩個單向的收發(fā)都是正常的。

而在關(guān)閉連接時，是為了判斷雙方是否應該關(guān)閉連接，即客戶端—>服務端、服務端->客戶端兩個單向的收發(fā)是否應該關(guān)閉。

在握手過程中，每一端自己當然清楚自己這邊的狀態(tài)，關(guān)鍵是從過程中判斷對方的狀態(tài)。

一、建立TCP連接：三次握手協(xié)議

客戶端：我要對你講話，你能聽到嗎；
服務端：我能聽到；而且我也要對你講話，你能聽到嗎；
客戶端：我也能聽到。
…….
互相開始通話

過程分析：
第一步，客戶端向服務端發(fā)送請求；
               服務端收到了客戶端請求，因此服務端可以判斷： 客戶端—>服務端單向收發(fā)正常。
第二步，服務端向客戶端發(fā)送確認；
               客戶端收到了確認，因此客戶端可以判斷：
                    服務端正常收到了自己剛才的請求，所以， 客戶端—>服務端單向收發(fā)正常、服務端—>客戶端單向收發(fā)正常。
               于是客戶端為連接分配相關(guān)資源，開始監(jiān)聽端口。     
第三步，客戶端針對剛才收到的包發(fā)送確認；
               服務端收到了這個確認包，因此服務端可以判斷： 客戶端—>服務端單向收發(fā)正常、服務端—>客戶端單向收發(fā)正常     
               于是服務端未連接分配相關(guān)資源，開始監(jiān)聽端口。

為何要分三步握手，而不能是兩步握手？

其實在理想的網(wǎng)絡環(huán)境下，只需要兩次握手就行了，在上面第二步之后，客戶端已經(jīng)知道兩個方向收到都是正常的了，它的確可以發(fā)送數(shù)據(jù)了。
但問題在于，網(wǎng)絡環(huán)境并不總是理想的，在第一步客戶端發(fā)送請求的過程有可能出現(xiàn)發(fā)送后遲遲收不到確認包而重發(fā)請求，如果之前已經(jīng)過時的這個請求包真得徹底消散在網(wǎng)絡傳輸中倒也罷了，但有時候它只是因為網(wǎng)絡延遲到達服務端比較晚，過了一陣子時間后，可能又到達服務端了。如果這個舊的請求包到達的時間是在正常請求包到達之前，或者是在整個連接關(guān)閉之后才到達，那么服務端是無法判斷這是過時請求的，服務端會正常發(fā)送確認，需要客戶端來驗明其過期的身份，然后告知服務端。
那么，如果是兩次握手的話，一旦出現(xiàn)這種情況，服務端在第一步就會為連接分配資源，開始監(jiān)聽端口。但這是個過時的無效請求，客戶端會拋棄掉，不會做對應的連接處理，也不會去發(fā)送數(shù)據(jù)。服務端會一直耗費資源傻等著。
如果是三次連接的話，多了客戶端驗證這一步，服務端能判斷出這是一個無效請求，因此不會去做對應的資源分配。

SYN:該字段被設(shè)置為1（即true），表示請求建立連接
FIN：該字段被設(shè)置為1（即true），表示請求關(guān)閉連接
seq:該字段為請求序列號，譬如為seq=x, 能夠標示一個請求包，在眾多包種區(qū)分其身份
ack:該字段為確認字段，譬如ack=x+1，表示已經(jīng)收到對方發(fā)來的seq=x的請求包。
客戶端通過ack可以判斷，當前確認包是針對哪個請求包在做確認。

二：關(guān)閉TCP連接：四次握手協(xié)議
客戶端：我說完了，我要閉嘴了；
服務端：我收到請求，我要閉耳朵了；
（客戶端收到這個確認，于是安心地閉嘴了。）
…….
服務端還沒傾訴完自己的故事，于是繼續(xù)嘮嘮叨叨向客戶端說了半天，直到說完為止
…….
服務端：我說完了，我也要閉嘴了；
客戶端：我收到請求，我要閉耳朵了；（事實上，客戶端為了保證這個確認包成功送達，等待了兩個最大報文生命周期后，才閉上耳朵。）
（服務端收到這個確認，于是安心地閉嘴了。）
（發(fā)送方之所以要收到確認后才關(guān)閉發(fā)送，是怕接收方?jīng)]收到自己的請求，避免自己關(guān)閉了發(fā)送，而接收方還一直傻等著去接收。）

客戶端收到請求包后，為什么要等待兩個最大報文生命周期后，才閉上耳朵呢？
為了以防萬一，因為最后一個發(fā)往服務端B的確認包有可能丟失，等待兩個最大報文生命周期是為了盡可能保障服務端能夠收到一次確認包，避免服務單始終處在等待關(guān)閉發(fā)送的狀態(tài)。
分析：
一個“最大報文時長”是TCP數(shù)據(jù)包在網(wǎng)絡中存在的最長時間，超過這個時間報文會被丟棄掉。
客戶端每次在收到服務端的“關(guān)閉請求”后開始計時，服務端一旦超時收不到客戶端的確認包就會重發(fā)請求，而TCP協(xié)議中的確認超時時長應該不會超過“最大報文周期”，而重發(fā)的網(wǎng)絡請求的傳輸時間也不超過“最大報文周期”，這樣正常情況下，重發(fā)的請求在兩個“最大報文周期”內(nèi)應該能夠到達客戶端，客戶端每次在收到服務端的“關(guān)閉請求”后又會重新開始計時兩個“最大報文周期”，又會重復前面的過程。
這樣，可以很大限度上保障服務端能收到一次確認包。（當然會有收不到的情況，所以應該會有別的超時機制來兜底。）文章來源地址http://www.zghlxwxcb.cn/news/detail-634093.html

到了這里，關(guān)于TCP三次握手、四次握手過程，以及原因分析的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！