TCP 的三次握手 與 四次揮手詳解（轉載）

建立TCP需要3次握手才能建立，而斷開連接則需要4次握手。全部進程以下圖所示：

先來看看如何建立連接的。

首先Client端發送連接要求報文，Server段接受連接后回復ACK報文，并為這次連接分配資源。Client端接收到ACK報文后也向Server段產生ACK報文，并分配資源，這樣TCP連接就建立了。

那如何斷開連接呢？簡單的進程以下：

【注意】中斷連接端可以是Client端，也能夠是Server端。

假定Client端發起中斷連接要求，也就是發送FIN報文。Server端接到FIN報文后，意思是說"我Client端沒有數據要發給你了"，但是如果你還有數據沒有發送完成，則沒必要急著關閉Socket，可以繼續發送數據。所以你先發送ACK，"告知Client端，你的要求我收到了，但是我還沒準備好，請繼續你等我的消息"。這個時候Client端就進入FIN_WAIT狀態，繼續等待Server真個FIN報文。當Server端肯定數據已發送完成，則向Client端發送FIN報文，"告知Client端，好了，我這邊數據發完了，準備好關閉連接了"。Client端收到FIN報文后，"就知道可以關閉連接了，但是他還是不相信網絡，怕Server端不知道要關閉，所以發送ACK落后入TIME_WAIT狀態，如果Server端沒有收到ACK則可以重傳。“，Server端收到ACK后，"就知道可以斷開連接了"。Client端等待了2MSL后仍然沒有收到回復，則證明Server端已正常關閉，那好，我Client端也能夠關閉連接了。Ok，TCP連接就這樣關閉了！

全部進程Client端所經歷的狀態以下：

而Server端所經歷的進程以下：轉載請注明:blog.csdn.net/whuslei

【注意】 在TIME_WAIT狀態中，如果TCP client端最后1次發送的ACK丟失了，它將重新發送。TIME_WAIT狀態中所需要的時間是依賴于實現方法的。典型的值為30秒、1分鐘和2分鐘。等待以后連接正式關閉，并且所有的資源(包括端口號)都被釋放。

【問題1】為何連接的時候是3次握手，關閉的時候卻是4次握手？
答：由于當Server端收到Client真個SYN連接要求報文后，可以直接發送SYN+ACK報文。其中ACK報文是用來應對的，SYN報文是用來同步的。但是關閉連接時，當Server端收到FIN報文時，極可能其實不會立即關閉SOCKET，所以只能先回復1個ACK報文，告知Client端，"你發的FIN報文我收到了"。只有等到我Server端所有的報文都發送完了，我才能發送FIN報文，因此不能1起發送。故需要4步握手。

【問題2】為何TIME_WAIT狀態需要經過2MSL(最大報文段生存時間)才能返回到CLOSE狀態？

答：雖然按道理，4個報文都發送終了，我們可以直接進入CLOSE狀態了，但是我們必須假象網絡是不可靠的，有可以最后1個ACK丟失。所以TIME_WAIT狀態就是用來重發可能丟失的ACK報文。

3次握手又是甚么？

TCP是面向連接的，不管哪1方向另外一方發送數據之前，都必須先在雙方之間建立1條連接。在TCP/IP協議中，TCP協議提供可靠的連接服務，連接是通過3次握手進行初始化的。3次握手的目的是同步連接雙方的序列號和確認號并交換 TCP窗口大小信息。這就是面試中常常會被問到的TCP3次握手。只是了解TCP3次握手的概念，對你取得1份工作是沒有任何幫助的，你需要去了解TCP3次握手中的1些細節。先來看圖說話。多么清晰的1張圖，固然了，也不是我畫的，我也只是援用過來講明問題了。

1. 第1次握手：建立連接。客戶端發送連接要求報文段，將SYN位置為1，Sequence Number為x；然后，客戶端進入SYN_SEND狀態，等待服務器的確認；
2. 第2次握手：服務器收到SYN報文段。服務器收到客戶真個SYN報文段，需要對這個SYN報文段進行確認，設置Acknowledgment Number為x+1(Sequence Number+1)；同時，自己自己還要發送SYN要求信息，將SYN位置為1，Sequence Number為y；服務器端將上述所有信息放到1個報文段（即SYN+ACK報文段）中，1并發送給客戶端，此時服務器進入SYN_RECV狀態；
3. 第3次握手：客戶端收到服務器的SYN+ACK報文段。然后將Acknowledgment Number設置為y+1，向服務器發送ACK報文段，這個報文段發送終了以后，客戶端和服務器端都進入ESTABLISHED狀態，完成TCP3次握手。

完成了3次握手，客戶端和服務器端就能夠開始傳送數據。以上就是TCP3次握手的整體介紹。

那4次分手呢？

當客戶端和服務器通過3次握手建立了TCP連接以后，當數據傳送終了，肯定是要斷開TCP連接的啊。那對TCP的斷開連接，這里就有了神秘的“4次分手”。

1. 第1次分手：主機1（可使客戶端，也能夠是服務器端），設置Sequence Number和Acknowledgment Number，向主機2發送1個FIN報文段；此時，主機1進入FIN_WAIT_1狀態；這表示主機1沒有數據要發送給主機2了；
2. 第2次分手：主機2收到了主機1發送的FIN報文段，向主機1回1個ACK報文段，Acknowledgment Number為Sequence Number加1；主機1進入FIN_WAIT_2狀態；主機2告知主機1，我“同意”你的關閉要求；
3. 第3次分手：主機2向主機1發送FIN報文段，要求關閉連接，同時主機2進入CLOSE_WAIT狀態；
4. 第4次分手：主機1收到主機2發送的FIN報文段，向主機2發送ACK報文段，然后主機1進入TIME_WAIT狀態；主機2收到主機1的ACK報文段以后，就關閉連接；此時，主機1等待2MSL后仍然沒有收到回復，則證明Server端已正常關閉，那好，主機1也能夠關閉連接了。

至此，TCP的4次分手就這么愉快的完成了。當你看到這里，你的頭腦里會有很多的疑問，很多的不懂，感覺很混亂；沒事，我們繼續總結。

為何要3次握手

既然總結了TCP的3次握手，那為何非要3次呢？怎樣覺得兩次就能夠完成了。那TCP為何非要進行3次連接呢？在謝希仁的《計算機網絡》中是這樣說的：

為了避免已失效的連接要求報文段突然又傳送到了服務端，因此產生毛病。

在書中同時舉了1個例子，以下：

“已失效的連接要求報文段”的產生在這樣1種情況下：client發出的第1個連接要求報文段并沒有丟失，而是在某個網絡結點長時間的滯留了，以致延誤到連接釋放以后的某個時間才到達server。本來這是1個早已失效的報文段。但server收到此失效的連接要求報文段后，就誤認為是client再次發出的1個新的連接要求。因而就向client發出確認報文段，同意建立連接。假定不采取“3次握手”，那末只要server發出確認，新的連接就建立了。由于現在client并沒有發出建立連接的要求，因此不會理會server的確認，也不會向server發送數據。但server卻以為新的運輸連接已建立，并1直等待client發來數據。這樣，server的很多資源就白白浪費掉了。采取“3次握手”的辦法可以避免上述現象產生。例如剛才那種情況，client不會向server的確認發出確認。server由于收不到確認，就知道client并沒有要求建立連接。”

這就很明白了，避免了服務器真個1直等待而浪費資源。

為何要4次分手

那4次分手又是為什么呢？TCP協議是1種面向連接的、可靠的、基于字節流的運輸層通訊協議。TCP是全雙工模式，這就意味著，當主機1發出FIN報文段時，只是表示主機1已沒有數據要發送了，主機1告知主機2，它的數據已全部發送終了了；但是，這個時候主機1還是可以接受來自主機2的數據；當主機2返回ACK報文段時，表示它已知道主機1沒有數據發送了，但是主機2還是可以發送數據到主機1的；當主機2也發送了FIN報文段時，這個時候就表示主機2也沒有數據要發送了，就會告知主機1，我也沒有數據要發送了，以后彼此就會愉快的中斷這次TCP連接。如果要正確的理解4次分手的原理，就需要了解4次分手進程中的狀態變化。

• FIN_WAIT_1: 這個狀態要好好解釋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狀態1般是比較難見到的，而FIN_WAIT_2狀態還有經常常可以用netstat看到。（主動方）
• FIN_WAIT_2：上面已詳細解釋了這類狀態，實際上FIN_WAIT_2狀態下的SOCKET，表示半連接，也即有1方要求close連接，但另外還告知對方，我暫時還有點數據需要傳送給你(ACK信息)，稍后再關閉連接。（主動方）
• CLOSE_WAIT：這類狀態的含義實際上是表示在等待關閉。怎樣理解呢？當對方close1個SOCKET后發送FIN報文給自己，你系統毫無疑問地會回應1個ACK報文給對方，此時則進入到CLOSE_WAIT狀態。接下來呢，實際上你真正需要斟酌的事情是觀察你是不是還有數據發送給對方，如果沒有的話，那末你也就能夠 close這個SOCKET，發送FIN報文給對方，也即關閉連接。所以你在CLOSE_WAIT狀態下，需要完成的事情是等待你去關閉連接。（被動方）
• LAST_ACK: 這個狀態還是比較容易好理解的，它是被動關閉1方在發送FIN報文后，最后等待對方的ACK報文。當收到ACK報文后，也便可以進入到CLOSED可用狀態了。（被動方）
• TIME_WAIT: 表示收到了對方的FIN報文，并發送出了ACK報文，就等2MSL后便可回到CLOSED可用狀態了。如果FINWAIT1狀態下，收到了對方同時帶FIN標志和ACK標志的報文時，可以直接進入到TIME_WAIT狀態，而不必經過FIN_WAIT_2狀態。（主動方）
• CLOSED: 表示連接中斷

TCP協議3次握手進程分析

TCP頭部： 其中 ACK   SYN  序號  這3個部份在以下會用到，它們的介紹也在下面。

暫時需要的信息有：

ACK ： TCP協議規定，只有ACK=1時有效，也規定連接建立后所有發送的報文的ACK必須為1

SYN(SYNchronization) ： 在連接建立時用來同步序號。當SYN=1而ACK=0時，表明這是1個連接要求報文。對方若同意建立連接，則應在響應報文中使SYN=1和ACK=1. 因此,  SYN置1就表示這是1個連接要求或連接接受報文。

FIN （finis）即完，終結的意思， 用來釋放1個連接。當 FIN = 1 時，表明此報文段的發送方的數據已發送終了，并要求釋放連接。

3次握手的進程：

首先由Client發出要求連接即 SYN=1 ACK=0  (請看頭字段的介紹), TCP規定SYN=1時不能攜帶數據，但要消耗1個序號,因此聲明自己的序號是 seq=x

然后 Server 進行回復確認，即 SYN=1 ACK=1 seq=y, ack=x+1,

再然后 Client 再進行1次確認，但不用SYN 了，這時候即為 ACK=1, seq=x+1, ack=y+1.

然后連接建立，為何要進行3次握手呢（兩次確認）。

下面是釋放連接的進程：

當客戶A 沒有東西要發送時就要釋放 A 這邊的連接，A會發送1個報文（沒有數據），其中 FIN 設置為1,  服務器B收到后會給利用程序1個信，這時候A那邊的連接已關閉，即A不再發送信息（但仍可接收信息）。  A收到B的確認落后入等待狀態，等待B要求釋放連接， B數據發送完成后就向A要求連接釋放，也是用FIN=1 表示， 并且用 ack = u+1(如圖）， A收到后回復1個確認信息，并進入 TIME_WAIT 狀態， 等待 2MSL 時間。

為何要等待呢？

為了這類情況： B向A發送 FIN = 1 的釋放連接要求，但這個報文丟失了， A沒有接到不會發送確認信息， B 超時會重傳，這時候A在 WAIT_TIME 還能夠接收到這個要求，這時候再回復1個確認就好了。（A收到 FIN = 1 的要求后 WAIT_TIME會重新記時）

另外服務器B存在1個保活狀態，即如果A突然故障死機了，那B那邊的連接資源甚么時候能釋放呢？  就是保活時間到了后，B會發送探測信息， 以決定是不是釋放連接。

1、TCP報文格式
  TCP/IP協議的詳細信息參看《TCP/IP協議詳解》3卷本。下面是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：發起1個新連接。
  （F）FIN：釋放1個連接。

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

2、3次握手
  所謂3次握手（Three-Way Handshake）即建立TCP連接，就是指建立1個TCP連接時，需要客戶端和服務端總共發送3個包以確認連接的建立。在socket編程中，這1進程由客戶端履行connect來觸發，全部流程以下圖所示：

圖2 TCP3次握手
  （1）第1次握手：Client將標志位SYN置為1，隨機產生1個值seq=J，并將該數據包發送給Server，Client進入SYN_SENT狀態，等待Server確認。
  （2）第2次握手：Server收到數據包后由標志位SYN=1知道Client要求建立連接，Server將標志位SYN和ACK都置為1，ack=J+1，隨機產生1個值seq=K，并將該數據包發送給Client以確認連接要求，Server進入SYN_RCVD狀態。
  （3）第3次握手：Client收到確認后，檢查ack是不是為J+1，ACK是不是為1，如果正確則將標志位ACK置為1，ack=K+1，并將該數據包發送給Server，Server檢查ack是不是為K+1，ACK是不是為1，如果正確則連接建立成功，Client和Server進入ESTABLISHED狀態，完成3次握手，隨后Client與Server之間可以開始傳輸數據了。
 
  SYN攻擊：
  在3次握手進程中，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攻擊時1種典型的DDOS攻擊，檢測SYN攻擊的方式非常簡單，即當Server上有大量半連接狀態且源IP地址是隨機的，則可以判定遭到SYN攻擊了，使用以下命令可讓之現行：
  #netstat -nap | grep SYN_RECV

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

圖3 TCP4次揮手
  由于TCP連接時全雙工的，因此，每一個方向都必須要單獨進行關閉，這1原則是當1方完成數據發送任務后，發送1個FIN來終止這1方向的連接，收到1個FIN只是意味著這1方向上沒有數據活動了，即不會再收到數據了，但是在這個TCP連接上依然能夠發送數據，直到這1方向也發送了FIN。首先進行關閉的1方將履行主動關閉，而另外一方則履行被動關閉，上圖描寫的即是如此。
 （1）第1次揮手：Client發送1個FIN，用來關閉Client到Server的數據傳送，Client進入FIN_WAIT_1狀態。
  （2）第2次揮手：Server收到FIN后，發送1個ACK給Client，確認序號為收到序號+1（與SYN相同，1個FIN占用1個序號），Server進入CLOSE_WAIT狀態。
 （3）第3次揮手：Server發送1個FIN，用來關閉Server到Client的數據傳送，Server進入LAST_ACK狀態。
  （4）第4次揮手：Client收到FIN后，Client進入TIME_WAIT狀態，接著發送1個ACK給Server，確認序號為收到序號+1，Server進入CLOSED狀態，完成4次揮手。
  上面是1方主動關閉，另外一方被動關閉的情況，實際中還會出現同時發起主動關閉的情況，具體流程以下圖：

圖4 同時揮手
  流程和狀態在上圖中已很明了了，在此不再贅述，可以參考前面的4次揮手解析步驟。

4、附注
  關于3次握手與4次揮手通常都會有典型的面試題，在此提出供有需求的XDJM們參考：
  （1）3次握手是甚么或流程？4次握手呢？答案前面分析就是。
  （2）為何建立連接是3次握手，而關閉連接卻是4次揮手呢？
  這是由于服務端在LISTEN狀態下，收到建立連接要求的SYN報文后，把ACK和SYN放在1個報文里發送給客戶端。而關閉連接時，當收到對方的FIN報文時，僅僅表示對方不再發送數據了但是還能接收數據，己方也未必全部數據都發送給對方了，所以己方可以立即close，也能夠發送1些數據給對方后，再發送FIN報文給對方來表示同意現在關閉連接，因此，己方ACK和FIN1般都會分開發送。

生活不易，碼農辛苦
如果您覺得本網站對您的學習有所幫助,可以手機掃描二維碼進行捐贈