TCP的傳輸連接管理
運輸連接的三個階段：連接建立、數據傳送、連接釋放。
TCP的連接建立（“三次握手”）
B的TCP服務器進程先創建傳輸控制模塊TCB（包含一些重要信息，如：TCP鏈接表，到發送和接收緩存的指針，到重傳隊列的指針，當前的發送和接收序號，等等），準備接收客戶進程的連接請求。然後服務器進程就一直處於LISTEN（收聽）狀態，等到客戶的連接請求。
A的TCP客戶進程也是首先創建傳輸控制模塊TCB，然後向B發出連接請求報文段，這時首部中的同步位SYN = 1，同時選擇一個初始序號seq = x。TCP規定，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狀態。
爲什麼A還要再發送一次確認呢？
這主要是爲了防止已經失效的連接請求報文段突然又傳送到了B，B收到這個失效的連接請求報文段之後，誤以爲是A又發出一次新的連接請求，於是就向A發出確認報文段，同意建立連接。嘉定不採用三次握手，那麼只要B發出發出確認，新的連接就建立了。由於A並沒有發出連接i請求，因此不會理睬B的確認，也不會向B發送數據。但B卻以爲新的運輸 連接已經開始了，並一直等待A發來數據。B的許多資源就因此浪費了。
TCP的連接釋放 （“四次揮手”）
數據傳輸結束後，通信的雙方都可釋放連接。現在A和B都處於ESTABLISHED狀態。A的應用進程先向其TCP發出連接釋放報文段，並停止再發送數據，主動關閉TCP連接。A把連接釋放報文段首部的FIN置1，其序號seq = u，它等於前面已傳送過的數據的最後一個字節的序號加1，這時A進入FIN-WAIT-1（終止等待1）狀態，等待B的確認。請注意，TCP規定，FIN報文段即使不懈怠數據，它也消耗掉一個序號。
B收到連接釋放報文段後即發出確認，確認號是ack = u+1，而這個報文段自己的序號是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，然後進入TIME-WAIT（時間等待）狀態。請注意，現在TCP連接還沒有釋放掉。必須經過時間等待計時器（TIME-WAIT timer）設置的時間2MSL後，A才進入到CLOSED（關閉）。時間MSL叫做最長報文段壽命。當A撤銷響應的傳輸控制塊TCB後，就結束了這次的TCP連接。
爲什麼A在TIME-WAIT狀態必須等待2MSL的時間呢？
第一，爲了保證A發送的最後一個ACK報文段能夠到達B。
第二，防止之前提到的“已失效的連接請求報文段”出現在本連接中。A在發送完最後一個ACK報文段小時候，再經過2MSL，就可以使本連接持續的時間內所產生的所有報文段都從網絡中消失。
B只要收到A發出的確認，就進入CLOSED狀態，同樣，B再撤銷響應的傳輸控制塊TCB後，就結束了這次的TCP連接。可以注意到，B結束TCP連接的時間要比A早一些。