TCP是因特網中的傳輸層協議，使用三次握手協議建立連接，下面是TCP建立連接的全過程。
上圖畫出了TCP建立連接的過程。假定主機A運行的是TCP客戶程序，B運行的是TCP服務器程序。最初兩端的TCP進程都處於CLOSED狀態。圖中在主機下面的是TCP進程所處的狀態。A是主動打開連接，B是被動打開連接。
B的TCP服務器進程先創建傳輸控制模塊TCB，准備接受客戶進程的連接請求，然后服務器進程就處於LISTEN(監聽)狀態，等待客戶的連接請求
首先A的TCP客戶進程向B發出連接請求報文段，這時首部中的同步位SYN=1，同時選擇一個初始序號seq=x。TCP規定，SYN報文段(即SYN=1的報文段)不能攜帶數據，但要消耗掉一個序號。這時，A的客戶進程就進入SYN-SENT(同步已發送)狀態。
B收到連接請求報文段后，向A發送確認。在確認報文段中把SYN和ACK位都置為1，確認號是ack=x+1,同時也為自己選擇一個初始序號seq=y。請注意，這個報文段也不能攜帶數據，但同樣要消耗掉一個序號。這時B的TCP服務器進程就進入SYN-RCVD(同步已收到)狀態。
A的TCP客戶進程收到B的確認后，還要向B給出確認。確認報文段的ACK置為1，確認號ack=y+1，而自己的序號seq=x+1。這時，TCP連接已經建立，A進入ESTABLISHED(已建立連接)狀態，
當B收到A的確認后，也會進入ESTABLISHED狀態。
以上給出的連接建立過程就是常說的TCP三次握手。
為什么A還要發送一次確認呢?這主要是為了防止已失效的連接請求報文段突然又傳送到了B，因而產生錯誤。
假定A發出的某一個連接請求報文段在傳輸的過程中並沒有丟失，而是在某個網絡節點長時間滯留了，以致延誤到連接釋放以后的某個時間才到達B。本來這是一個早已失效的報文段。但B收到此失效的連接請求報文段后，就誤以為A又發了一次新的連接請求，於是向A發出確認報文段，同意建立連接。假如不采用三次握手，那么只要B發出確認，新的連接就建立了。
由於A並未發出建立連接的請求，因此不會理睬B的確認，也不會向B發送數據。但B卻以為新的運輸連接已經建立了，並一直等待A發來數據，因此白白浪費了許多資源。
采用TCP三次握手的方法可以防止上述現象發生。例如在剛才的情況下，由於A不會向B的確認發出確認，B由於收不到確認，就知道A並沒有要求建立連接。