TCP握手與釋放
3次握手與4次揮手
#第一次握手：主機A發送握手信號syn＝1和seq=x（隨機產生的序列號）的數據包到服務器，主機B由SYN=1知道，A要求建立聯機；
#第二次握手：主機B收到請求後要確認聯機信息，向A發送syn=1，ack=x（x是主機A的Seq）+1，以及隨機產生的確認端序列號
seq=y的包；
#第三次握手：主機A收到後檢查ack是否正確（ack=x+1），即第一次發送的seq+1，若正確，主機A會再發送ack=y+1，以及隨機序
列號seq=z，主機B收到後確認ack值則連接建立成功；
#完成三次握手，主機A與主機B開始傳送數據。
注：上述步驟中，第二和第三次確認包中都還包含一個標誌位未予以說明，該標誌位爲1表示正常應答；
具體可見圖片：
爲什麼需要“三次握手”？
“三次握手”的目的是“爲了防止已失效的連接請求報文段突然又傳送到了服務端，因而產生錯誤”。具體例如：client發出的第一個連接請求報文段並沒有丟失，而是在某個網絡結點長時間的滯留了，以致延誤到連接釋放以後的某個時間纔到達server。本來這是一個早已失效的報文段。但server收到此失效的連接請求報文段後，就誤認爲是client再次發出的一個新的連接請求。於是就向client發出確認報文段，同意建立連接。假設不採用“三次握手”，那麼只要server發出確認，新的連接就建立了。由於現在client並沒有發出建立連接的請求，因此不會理睬server的確認，也不會向server發送數據。但server卻以爲新的運輸連接已經建立，並一直等待client發來數據。這樣，server的很多資源就白白浪費掉了。採用“三次握手”的辦法可以防止上述現象發生。例如剛纔那種情況，client不會向server的確認發出確認。server由於收不到確認，就知道client並沒有要求建立連接。主要目的防止server端一直等待，浪費資源。
（2）揮手
由於TCP連接是全雙工的，因此每個方向都必須單獨進行關閉。這原則是當一方完成它的數據發送任務後就能發送一個FIN來終止這個方向的連接。收到一個 FIN只意味着這一方向上沒有數據流動，一個TCP連接在收到一個FIN後仍能發送數據。首先進行關閉的一方將執行主動關閉，而另一方執行被動關閉。
(1) TCP客戶端發送一個FIN，用來關閉客戶到服務器的數據傳送(報文段4)；
(2) 服務器收到這個FIN，發回一個ACK，確認序號爲收到的序號加1(報文段5)。和SYN一樣，一個FIN將佔用一個序號；
(3) 服務器關閉客戶端的連接後，再發送一個FIN給客戶端(報文段6)；
(4) 客戶段收到服務端的FIN後，發回ACK報文確認，並將確認序號設置爲收到序號加1(報文段7)；
注意：TCP連接的任何一方都可以發起揮手操作，上述步驟只是兩種之一；
具體過程見圖：
爲什麼是“四次揮手”？
因爲當收到對方的FIN報文通知時，它僅僅表示對方沒有數據發送給你了；但未必你所有的數據都全部發送給對方了，所以你可能還需要發送一些數據給對方，再發送FIN報文給對方來表示你同意現在可以關閉連接了，故這裏的ACK報文和FIN報文多數情況下都是分開發送的，也就造成了4次揮手。
握手，揮手過程中各狀態介紹：
（1）3次握手過程狀態：
#LISTEN: 這個也是非常容易理解的一個狀態，表示服務器端的某個SOCKET處於監聽狀態，可以接受連接了。
#SYN_SENT: 當客戶端SOCKET執行CONNECT連接時，它首先發送SYN報文，因此也隨即它會進入到了SYN_SENT狀態，並等待服務端的發送三次握手中的第2個報文。SYN_SENT狀態表示客戶端已發送SYN報文。(發送端)
#SYN_RCVD: 這個狀態與SYN_SENT遙想呼應這個狀態表示接受到了SYN報文，在正常情況下，這個狀態是服務器端的SOCKET在建立TCP連接時的三次握手會話過程中的一箇中間狀態，很短暫，基本上用netstat你是很難看到這種狀態的，除非你特意寫了一個客戶端測試程序，故意將三次TCP握手過程中最後一個ACK報文不予發送。因此這種狀態時，當收到客戶端的ACK報文後，它會進入到ESTABLISHED狀態。(服務器端)
#ESTABLISHED：這個容易理解了，表示連接已經建立了。
（2）4次揮手過程狀態：
#FIN_WAIT_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狀態一般是比較難見到的，而FIN_WAIT_2狀態還有時常常可以用netstat看到。(主動方)
#FIN_WAIT_2：上面已經詳細解釋了這種狀態，實際上FIN_WAIT_2狀態下的SOCKET，表示半連接，也即有一方要求close連接，但另外還告訴對方，我暫時還有點數據需要傳送給你(ACK信息)，稍後再關閉連接。(主動方)
#TIME_WAIT: 表示收到了對方的FIN報文，併發送出了ACK報文，就等2MSL後即可回到CLOSED可用狀態了。如果FIN_WAIT_1狀態下，收到了對方同時帶FIN標誌和ACK標誌的報文時，可以直接進入到TIME_WAIT狀態，而無須經過FIN_WAIT_2狀態。(主動方)
#CLOSING(比較少見): 這種狀態比較特殊，實際情況中應該是很少見，屬於一種比較罕見的例外狀態。正常情況下，當你發送FIN報文後，按理來說是應該先收到(或同時收到)對方的ACK報文，再收到對方的FIN報文。但是CLOSING狀態表示你發送FIN報文後，並沒有收到對方的ACK報文，反而卻也收到了對方的FIN報文。什麼情況下會出現此種情況呢?其實細想一下，也不難得出結論：那就是如果雙方幾乎在同時close一個SOCKET的話，那麼就出現了雙方同時發送FIN報文的情況，也即會出現CLOSING狀態，表示雙方都正在關閉SOCKET連接。
#CLOSE_WAIT: 這種狀態的含義其實是表示在等待關閉。怎麼理解呢?當對方close一個SOCKET後發送FIN報文給自己，你係統毫無疑問地會迴應一個ACK報文給對方，此時則進入到CLOSE_WAIT狀態。接下來呢，實際上你真正需要考慮的事情是察看你是否還有數據發送給對方，如果沒有的話，那麼你也就可以close這個SOCKET，發送FIN報文給對方，也即關閉連接。所以你在CLOSE_WAIT狀態下，需要完成的事情是等待你去關閉連接。(被動方)
#LAST_ACK: 這個狀態還是比較容易好理解的，它是被動關閉一方在發送FIN報文後，最後等待對方的ACK報文。當收到ACK報文後，也即可以進入到CLOSED可用狀態了。(被動方)