在之前對TCP協議的介紹中，說到了其中它的一個特點是面向連接。今天就來介紹一下它的連接和斷開過程。
面向連接指的是采用TCP協議通訊，在數據傳輸之前必須先建立連接，通訊完成之后，必須關閉連接。
建立連接的過程為三次握手過程，其作用是：
1、使得通訊雙發都做好通訊的准備
2、告訴對端本端通訊所選用的報文標識號
3、防止已失效的連接請求報文段又突然傳遞到了服務端，從而產生錯誤
關閉連接的過程為四次揮手，由於TCP的全雙工的通訊。所以每個方向都必須單獨進行關閉。當一方完成它的數據發送任務后就能發送一個FIN來終止這個方向的連接。收到一個FIN只意味着這一方向上沒有數據流動，一個TCP連接在收到一個FIN后仍能繼續發送數據。首先進行關閉的一方將執行主動關閉，而另一方執行被動關閉。
TCP三次握手和四次揮手過程：
當客戶連接收到服務器發送的結束報文段（報文段6）之后，並沒有直接進入CLOSED狀態，而是轉移到TIME_WAIT狀態。在這個狀態，客戶端連接要等待一段長為2MSL(MSL：報文段最大生存時間)的時間，才能完全關閉。
TIME_WAIT狀態存在的原因：
1、可靠的終止連接。 假設圖中用於確認服務器報文段6的TCP報文段7丟失，那么服務器將重發結束報文段。因此客戶端需要停留在某個狀態處理重復收到的結束報文段（即向服務器發送確認報文段）。否則，客戶端將以復位報文段來回應服務器，服務器則認為只是一個錯誤，因為它期望收到的是一個像報文段7那樣的確認報文段。
2、保證讓遲來的TCP報文段有足夠的時間識別並丟棄。 在Linux系統上，一個TCP端口不能被同時打開兩次及以上。當一個TCP連接處於TIME_WAIT狀態時，我們無法立即使用該連接占用的端口號來建立一個新連接。因此，如果沒有TIME_WAIT狀態，則應用程序能夠立即建立一個和剛關閉的連接相似的連接（相似是指它們具有相同的IP地址和端口號）。這個新的和原來相似的連接被稱為原來的連接的化身。新的化身可能接收到屬於原來的連接的、攜帶應用程序的TCP報文段（即遲到的報文段），這顯然是不應該發生的，這是存在的第二個原因。
另外，因為TCP報文段的最大生存時間是MSL，所以堅持2MSL時間的TIME_WAIT狀態能夠確保網絡上兩個傳輸方向上尚未被接受到的、遲到的報文段都已經消失（被中轉路由器丟棄）。因此，一個連接的新的化身可以再2MSL時間之后安全的建立，而絕對不會接收到屬於原來連接的應用程序數據，這就是TIME_WAIT要持續2MSL時間的原因。
那么TCP為什么要進行三次握手和四次揮手呢？
“三次握手”的目的是“為了防止已失效的連接請求報文段突然又傳送到了服務端，因而產生錯誤”。
謝希仁版《計算機網絡》中的例子是這樣的，“已失效的連接請求報文段”的產生在這樣一種情況下：client發出的第一個連接請求報文段並沒有丟失，而是在某個網絡結點長時間的滯留了，以致延誤到連接釋放以后的某個時間才到達server“。
本來這是一個早已失效的報文段。但server收到此失效的連接請求報文段后，就誤認為是client再次發出的一個新的連接請求。於是就向client發出確認報文段，同意建立連接。假設不采用“三次握手”，那么只要server發出確認，新的連接就建立了。由於現在client並沒有發出建立連接的請求，因此不會理睬server的確認，也不會向server發送數據。但server卻以為新的運輸連接已經建立，並一直等待client發來數據。這樣，server的很多資源就白白浪費掉了。采用“三次握手”的辦法可以防止上述現象發生。例如剛才那種情況，client不會向server的確認發出確認。server由於收不到確認，就知道client並沒有要求建立連接。”。主要目的防止server端一直等待，浪費資源。
四次揮手的原因：在四次揮手過程中，報文段6中也包含了確認信息，為什么還用報文段5單獨先發一遍，那么這個報文段5可以背省略么？
實際上，僅用於確認目的的確認報文段5是可以省略的，因為報文段6中也攜帶了該確認信息。確認報文段5是否出現在連接斷開的過程中，取決於TCP的延遲確認特性。
TCP連接是全雙工的，所以它允許兩個方向的數據傳輸被獨立關閉。即，通信的一方可以發結束報文段給對方，告訴它本端已經完成了數據的發送，但允許繼續接收來自對方的數據，直到對方也發送報文段結束。所以當客戶端發送結束報文段后，服務器那里可能還有數據要發送，就先發送一個確認報文段表示已經接收到客戶端發送過來的結束報文段，直到將數據發送完畢后再結束連接。
延遲確認：即服務器不馬上確認上次收到的數據，而是在一段延遲時間后查看本端是否有數據需要發送，如果有，則和確認信息一起發出。因為服務器對客戶的請求處理很快，所以他發送確認報文段的時候總是有數據一起發送。延遲確認可以減少發送TCP報文段的數量。而由於用戶的輸入速度明顯慢於客戶端程序的處理速度，所以客戶端的確認報文段總是不攜帶任何應用程序。