tcp建立連線的過程叫做握手，握手需要在客戶和伺服器之間交換三個tcp報文段。
下圖是三報文握手建立tcp連線的過程：
在這個例子中，a作為客戶端主動開啟連線，b作為服務端被動開啟連線。
一開始，b的tcp伺服器程序先建立傳輸控制塊tcb，準備接受客戶程序的連線請求。然後伺服器程序就處於listen（收聽)狀態，等待客戶的連線請求。如有，即做出響應。
a的tcp客戶程序也是首先建立傳輸模組tcb。然後zhi，在打算建立tcp連線時，向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狀態。這就是tcp三報文握手的建立過程。
問：為什麼不是兩次握手呢？（為什麼a最後還要傳送一次確認呢？）答：這主要是為了防止已失效的連線請求報文突然又傳送到了b，因此產生錯誤。這時候考慮兩種情況：考慮一種正常情況，a發成連線請求，但因連線請求報文丟失而未收到確認。於是a再重傳一次連線請求。後來收到了確認，建立了連線。資料傳輸完成後就釋放了連線。a共傳送了兩個連線請求報文段，其中第乙個丟失，第二個到達了b，沒有「已失效的連線請求報文段".
另一種異常情況，即a發出的第乙個連線請求報文段並沒有丟失，而是在某些網路節點長時間滯留了，以致延誤到連線釋放以後的某個時間才到達b。本來這是乙個早已失效的報文段。但b收到此失效的連線請求報文段後，就誤認為是a又發出一次新的連線請求。於是就向a發出確認報文段，同意建立連線。假定不採用報文握手，那麼只要b發出確認，新的連線就建立了。
由於現在a並沒有發出建立連線的請求，因此不會理睬b的確認，也不會向b傳送資料。但b卻認為新的運輸連線已經建立了，並一直等待a發來資料。b的許多資源就這樣白白浪費了。
問：為什麼不是四次握手呢答：上圖中b傳送給a的報文段中，也可以拆成兩個報文段。可以先傳送乙個確認報文段（ack=1,ack=x+1),然後再傳送乙個同步報文段（syn=1,seq=y)。這樣的過程就變成了四報文握手，但效果是一樣。與其如此，還不如直接三報文握手。
TCP建立連線的三次握手過程
tcp是網際網路中的傳輸層協議，使用三次握手協議建立連線，下面是tcp建立連線的全過程。上圖畫出了tcp建立連線的過程。假定主機a執行的是tcp客戶程式，b執行的是tcp伺服器程式。最初兩端的tcp程序都處於closed狀態。圖中在主機下面的是tcp程序所處的狀態。a是主動開啟連線，b是被動開啟連線...
TCP建立連線過程（三次握手）
第一次 傳送方傳送syn的連線請求報文到接收方，請求建立連線 接收方收到之後開始為本次請求分配資源 第二次 接收方收到傳送方連線的請求後，傳送ack確認收到傳送方的連線請求，並向傳送方發起syn連線請求 傳送方收到接收方的ack請求，開始分配資源 第三次 傳送方收到接收方的連線請求後，也會傳送ack...
TCP連線建立時三次握手詳解
1 概述 tcp連線建立過程中要解決以下三個問題 1 要使每一方能夠確知對方的存在。2 要允許雙方協商一些引數 如最大報文段長度，最大視窗大小，服務質量等 3 能夠對運輸實體資源 如快取大小，連線表中的專案等 進行分配。tcp 連線的建立都是採用客戶伺服器方式。主動發起連線建立的應用程序叫做客戶 c...