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並沒有要求建立連線。
詳解TCP建立連線三次握手過程
tcp建立連線的過程叫做握手，握手需要在客戶和伺服器之間交換三個tcp報文段。下圖是三報文握手建立tcp連線的過程 在這個例子中，a作為客戶端主動開啟連線，b作為服務端被動開啟連線。一開始，b的tcp伺服器程序先建立傳輸控制塊tcb，準備接受客戶程序的連線請求。然後伺服器程序就處於listen 收聽...
TCP建立連線過程（三次握手）
第一次 傳送方傳送syn的連線請求報文到接收方，請求建立連線 接收方收到之後開始為本次請求分配資源 第二次 接收方收到傳送方連線的請求後，傳送ack確認收到傳送方的連線請求，並向傳送方發起syn連線請求 傳送方收到接收方的ack請求，開始分配資源 第三次 傳送方收到接收方的連線請求後，也會傳送ack...
三次握手 TCP建立連線
在tcp ip 中，tcp協議提供可靠的連線服務 採用三次握手建立乙個連線。第一次握手 建立連線時，客戶端 傳送syn 包 syn j 到伺服器 並進入syn send狀態，等待伺服器確認 syn 同步序列編號 synchronize sequence numbers 第二次握手 伺服器 收到syn...