本文目的：熟悉TCP三次握手及四次揮手的整體過程及一些設計思想

TCP建立連線需要進行三次握手；斷開連線需要四次揮手，下面說說握手及揮手的過程

整個過程如下：

三次握手

1、TCP連線建立------ 三次握手

建立連線舉個簡單的例子，方便理解：
A : 你好我是A，你聽得到我在說話嗎？
B : 聽到了，我是B，你聽到我在說話嗎？
A : 嗯，聽到了，開始說吧。
連線建立，開始聊天！

最初兩端的TCP程序都處於CLOSED關閉狀態，A先建立傳輸控制塊TCB開啟連線，B被動開啟連線，LISTEN（監聽）狀態

第一次握手：客戶端向服務端發出連線請求報文段(同步位SYN=1,初始序號seq=x)，並進入SYN_SEND狀態等待服務端確認，服務端由SYN=1知道客戶端要建立連線

第二次握手：服務端接收到SYN包，如果同意連線，必須確認客戶端SYN（ack=x+1），同時自己也傳送一個SYN包（SYN=1,ACK=1,初始序列號seq=y）,及SYN+ACK包，同時服務端進入SYN_RECV狀態

第三次握手：客戶端收到服務端SYN+ACK包，檢查ack是否正確，正確向服務端傳送確認包ACK（ACK=1,seq=x+1,ack=y+1），此包傳送完畢，客戶端和服務端進入ESTABLISHED狀態，完成三次握手。

為什麼不兩次握手，而要三次握手呢？

主要防止已經失效的連線請求報文突然又傳送到了伺服器，從而產生錯誤。

    如果使用的是兩次握手建立連線，假設有這樣一種場景，

    如果採用的是三次握手，就算是那一次失效的報文傳送過來了，服務端接受到了那條失效報文並且回覆了確認報文，但是客戶端不會再次發出確認。由於伺服器收不到確認，就知道客戶端並沒有請求連線。

四次揮手

建立連線舉個簡單的例子，方便理解：

A:“喂，我不說了。”A->FIN_WAIT1

B:“我知道了。等下，上一句還沒說完。Balabala…..”B->CLOSE_WAIT | A->FIN_WAIT2

B:”好了，說完了，我也不說了。”B->LAST_ACK

A:”我知道了。”A->TIME_WAIT | B->CLOSED

A等待2MSL,保證B收到了訊息,否則重說一次”我知道了”,A->CLOSED

四次揮手過程：

1、客戶端發出連線釋放報文，並且停止傳送資料。FIN=1,序列號seq=u（前面已經傳過來的資料的最後一個位元組的序號+1），此時，客戶端進入FIN-WAIT1狀態。

2、服務端接收到釋放報文，發出確認報文，ACK=1，ack=u+1,並且帶上自己的序列號seq=v，此時，服務端就進入了CLOSE-WAIT狀態，如果此時服務端要傳送資料，客戶端依然要接收，所以這個狀態需要持續一段時間，也就是整個CLOSE-WAIT狀態持續的時間；客戶端接收到服務端的確認請求後，此時，客戶端進入FIN-WAIT2狀態，等到服務端傳送連線釋放報文(在這之前還需要接收服務端傳送的最後的資料)

3、伺服器將最後的資料傳送完畢後，就向客戶端傳送連線釋放報文，FIN=1，ack=u+1，由於在半關閉狀態，伺服器很可能又傳送了一些資料，假定此時的序列號為seq=w，此時，伺服器就進入了LAST-ACK（最後確認）狀態，等待客戶端的確認。

4、客戶端收到伺服器的連線釋放報文後，必須發出確認，ACK=1，ack=w+1，而自己的序列號是seq=u+1，此時，客戶端就進入了TIME-WAIT狀態，注意此時TCP連線還沒有釋放，必須經過2
∗ MSL（最長報文段壽命）的時間後，當客戶端撤銷相應的TCB後，才進入CLOSED狀態。伺服器只要收到了客戶端發出的確認，立即進入CLOSED狀態。同樣，撤銷TCB後，就結束了這次的TCP連線。可以看到，伺服器結束TCP連線的時間要比客戶端早一些。

為什麼建立連線是三次握手，關閉連線確是四次揮手呢？
        建立連線的時候， 伺服器在LISTEN狀態下，收到建立連線請求的SYN報文後，把ACK和SYN放在一個報文裡傳送給客戶端。 
        而關閉連線時，伺服器收到對方的FIN報文時，僅僅表示對方不再發送資料了但是還能接收資料，而自己也未必全部資料都發送給對方了，所以己方可以立即關閉，也可以傳送一些資料給對方後，再發送FIN報文給對方來表示同意現在關閉連線，因此，己方ACK和FIN一般都會分開發送，從而導致多了一次。

為什麼客戶端最後還要等待2MSL？

MSL（Maximum Segment Lifetime），TCP允許不同的實現可以設定不同的MSL值。

        第一，保證客戶端傳送的最後一個ACK報文能夠到達伺服器，因為這個ACK報文可能丟失，站在伺服器的角度看來，我已經發送了FIN+ACK報文請求斷開了，客戶端還沒有給我回應，應該是我傳送的請求斷開報文它沒有收到，於是伺服器又會重新發送一次，而客戶端就能在這個2MSL時間段內收到這個重傳的報文，接著給出迴應報文，並且會重啟2MSL計時器。
        第二，防止類似與“三次握手”中提到了的“已經失效的連線請求報文段”出現在本連線中。客戶端傳送完最後一個確認報文後，在這個2MSL時間中，就可以使本連線持續的時間內所產生的所有報文段都從網路中消失。這樣新的連線中不會出現舊連線的請求報文。