本文內容大部分轉載自：http://blog.csdn.net/whuslei/article/details/6667471/

原文獲得了54萬的閱讀量，說明改文章的質量很高

同時，博主在原文的基礎上也補充了一些內容

建立TCP需要三次握手才能建立，而斷開連線則需要四次握手。整個過程如下圖所示：

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

【更新於2017.01.04 】該部分內容配圖有誤，請大家見諒，正確的配圖如下，錯誤配圖也不刪了，大家可以比較下，對比理解效果更好。這麼久才來更新，抱歉！！

錯誤配圖如下：

首先Client端傳送連線請求報文，Server段接受連線後回覆ACK報文，併為這次連線分配資源。Client端接收到ACK報文後也向Server段發生ACK報文，並分配資源，這樣TCP連線就建立了。（注意：第二次客戶端的SYN標誌位為0

）

這裡補充一下，為什麼客戶機還要再發送一次確認呢？

答：這主要是為了防止以失效的連結請求報文段突然又傳送到了服務端，因而產生了錯誤。

所謂“已失效的連線請求報文段”是這樣產生的。

考慮一種情況。客戶端發出連線請求，但因為連線請求丟失而未收到確認。於是客戶端會再重傳一次連線請求。

後來收到了確認，建立了連線。

資料傳輸完畢後，就釋放了連線。客戶端一共傳送了兩個連線請求報文段，其中第一個丟失，第二個到達了服務端。沒有“已失效的連線請求報文段”。

現在假定一種異常情況，即客戶端發出的第一個連線請求報文段並沒有丟失，而是在某些網路節點長時間滯留了，以致延誤到連線釋放以後的某個時間才到達服務端。

本來這是一個早已失效的請求報文段。但服務端收到此失效的連線請求報文段後，就誤以為客戶端又發出了一次連線請求。

於是向A發出確認報文段，同意建立連線。

假定不採用三次握手，那麼只要服務端發出確認，新的連線就建立了。這顯然是不行的。

由於現在客戶端並沒有發出建立連線的請求，因此不會理睬服務端的確認，也不會向服務端傳送資料。

但是服務端卻以為新的傳輸連線已經建立，並一直等待客戶端發來的資料。服務端的許多資源就是這樣白白浪費了

那如何斷開連線呢？簡單的過程如下：

【注意】中斷連線端可以是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端所經歷的狀態如下：

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

【問題1】為什麼連線的時候是三次握手，關閉的時候卻是四次握手？
答：因為當Server端收到Client端的SYN連線請求報文後，可以直接傳送SYN+ACK報文。其中ACK報文是用來應答的，SYN報文是用來同步的。但是關閉連線時，當Server端收到FIN報文時，很可能並不會立即關閉SOCKET，所以只能先回復一個ACK報文，告訴Client端，"你發的FIN報文我收到了"。只有等到我Server端所有的報文都發送完了，我才能傳送FIN報文，因此不能一起傳送。故需要四步握手。

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

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