上圖畫出了TCP的建立連接的過程。假定主機A運行的是TCP客戶程序，而B運行TCP服務程序。最初兩端的TCP進程都處於 CLOSED（關閉）狀態。圖中在主機下面的方框分別是TCP進程所處的狀態。請注意，A主動打開連接，而B被動打開連接。
B的TCP服務器進程先創建傳輸控制塊TCB（Transmission Control Block），準備接受客戶進程的連接請求。然後服務器進程就處於LISTEN（監聽）狀態，等待客戶的連接請求。如有，即做出響應。
A的TCP客戶進程也是首先創建傳輸控制塊TCB，然後向B發出連接請求報文段，這時首部中的同步位SYN = 1，同時選擇一個初始序號seq = x。TCP規定，SYN報文段（即SYN = 1的報文段）不能攜帶數據，但要消耗掉一個序號。這時，TCP客戶進程進入SYN-SENT（同步已發送）狀態。
B收到連接請求報文後，如果同意建立連接，則向A發送確認。在確認報文段中應把SYN位和ACK位都置1，確認號ack = x + 1，同時也爲自己選擇一個初始序號seq = y。請注意，這個報文段也不能攜帶數據，但同樣要消耗掉一個序號。這時TCP服務器進程進入SYN-RCVD（同步收到）狀態。
TCP客戶進程收到B的確認後，還要向B給出確認。確認報文段的ACK置1，確認號ack = y + 1，而自己的序號seq = x + 1。TCP的標準規定，ACK報文段可以攜帶數據。但如果不攜帶數據則不消耗序號，在這種情況下，下一個數據報文段的序號仍是seq = x + 1。這時，TCP連接已經建立，A進入ESTABLISHED（已建立連接）狀態。
當B收到A的確認後，也進入ESTABLISHED狀態。
上面給出的連接建立過程叫做三次握手（three-way handshake）。
爲什麼A還要發送一次確認呢？這主要是爲了防止已失效的連接請求報文突然又送到了B，因而產生錯誤。
下面再看看TCP四次揮手（釋放連接）
現在A和B都處於ESTABLISHED狀態。A的應用進程先向其TCP發出連接釋放報文段，並停止再發送數據，主動關閉TCP連接。
A把連接釋放報文段首部的終止控制位置1，其序號seq = u，u等於前面已傳送過的數據的最後一個字節加上1。這時A進入FIN-WAIT-1（終止等待1）狀態，等待B的確認。請注意，FIN報文段即使不攜帶數據，他也要消耗掉一個序號。
B收到連接釋放報文段後即發送出確認，確認號ack = u + 1,而這個報文段自己的序號是seq = v，v等於B前面已傳送過的數據的最後一個字節的序號加1.然後B進入CLOSE-WAIT（關閉等待）狀態。TCP服務器進程這時應通知高層應用進程，因而從A到B這個方向的連接就釋放了，這時的TCP連接處於半關閉（half-close）狀態，即A已經沒有時間要發送了，但B若發送數據，A仍要接收。也就是說，從B到A這個方向的連接並未關閉，這個狀態可能會持續一些時間。
A收到來自B的確認後，就進入FIN-WAIT-2（終止等待2）狀態，等待B發出的連接釋放報文段。
若B已經沒有要向A發送的數據，其應用進程就通知TCP釋放連接。這時B發出的連接釋放報文段必須使FIN = 1。現假定B的序號爲w（在半關閉狀態B可能又發送了一些數據）。B還必須重複上次已經發送過的確認號ack = u + 1。這時B就進入了LAST-ACK（最後確認）狀態，等待A的確認。
A在收到B的連接釋放確認後們必須對此發出確認。在確認報文段中把ACK置1，確認號ack = w + 1,而自己的序號seq = u + 1（根據TCP標準，前面發送過的FIN報文段要消耗一個序號）。然後進入到TIME-WAIT（時間等待）狀態。請注意，現在TCP連接還沒有釋放掉，必須經過時間等待計時器（TIME-WAIT timer）設置的時間2MSL後，A才進入CLOSED狀態。MSL叫做最長報文段壽命（Maximum Segment Lifetime），建議時間爲2分鐘，也可以使用更小的值。因此，從A進入到TIME-WAIT狀態後，要經過4分鐘才能進入到CLOSED狀態，才能開始建立下一個新的連接。當A撤銷相應的傳輸控制塊TCB後，就結束了這次的TCP連接。
B只要收到了A發出的確認，就進入CLOSED狀態。同樣，B在撤銷相應的傳輸控制塊TCB後，就結束了這次的TCP連接。我們注意到，B結束TCP連接的時間要比A早一些。
上述了連接釋放過程就是四次揮手。
爲什麼A在TIME-WAIT狀態必須等待2MSL的時間呢？
- 爲了保證A發送了最後一個ACK報文段能夠到達B。
- 防止已經失效的連接請求報文段出現在本連接中。
除了時間等待計時器外，TCP還設有一個保活計時器（keepalive timer）來防止客戶端的主機出現故障而導致的資源浪費。