tcp是面向連線的協議。運輸連線是用來傳送tcp報文的。
tcp運輸連線的建立和釋放是每一次面向連線的通訊中必不可少的過程。
運輸連線有三個階段：連線建立、資料傳送、連線釋放
下圖是這三個階段的示意圖：
連線的建立
tcp的連線採用客戶伺服器的方式。
主動發起連線建立的應用程序叫做客戶（client）
被動等待連線建立的應用程序叫做伺服器（server）
下面描述連線建立的過程：
假定主機a是客戶端、主機b是服務端。
初始狀態：a和b都是處於closed關閉狀態。
操作：a主動開啟連線，b被動開啟連線
過程：a的tcp客戶程序首先建立傳輸控制模組tcb，然後向b發出連線請求報文。
首部中同步位syn=1，序列號seq=x. tcp 規定，syn報文段（syn=1的報文段）不能夠攜帶資料，但是要消耗乙個序列號。傳送完之後，a進入syn-sent狀態。（同步已傳送狀態）。
b收到連線請求報文段後，如同意建立連線，就向a傳送確認。確認欄位中把syn 和 ack 都置為1，確認號是ack=x+1，同時也為自己選擇乙個序列號：seq=y. 請注意，這個報文段也不能夠攜帶資料，但是要消耗序列號。傳送完之後，b進入syn-rcvd狀態（同步收到狀態）。
a收到b的確認之後，還要向b給出確認。確認報文的ack置為1，確認號ack=y+1，而自己的序號為seq=x+1。tcp標準規定，ack報文可以攜帶資料，但是如果不攜帶資料則不消耗序號，在這種情況下，下乙個資料報文的序號仍然是seq=x+1。傳送完畢之後，tcp連線建立。a進入established狀態，b收到a的確認之後，也進入established狀態。
此時，三次握手完成。
問題：為什麼a最後還要傳送一次確認呢？
答案：這主要是為了防止已經失效的連線請求報文段突然又傳送到b，因而產生錯誤。
所謂「已經失效的連線請求報文段」是這樣產生的。
考慮一種正常情況，a發出連線請求，但因連線請求報文丟失而未收到確認。於是，a再重傳一次連線請求，這次收到了確認，建立了連線。資料傳輸完畢之後，就釋放了連線。
a總共傳送了兩次連線請求報文段，其中第乙個丟失了，第二個到達了b. 此時沒有已經失效的連線請求報文段。
現在考慮一種異常情況，即a發出的第乙個連線請求報文段並沒有丟失，而是在某些網路結點長時間滯留了，以致延誤到連線釋放之後的某個時間才到達b。本來這是乙個已經失效的報文段。但b收到此失效的連線請求報文段之後，就誤認為是a又發出一次連線請求。於是向a發出確認報文段，同意建立連線。假定不採用三次握手，那麼只要b收到連線請求報文段，新的連線就建立了。
由於現在a並沒有發出建立連線的請求，因此不會理睬b的確認，也不會向b傳送資料。但b卻以為新的運輸連線已經建立了，並會一直等待a發來的資料，b的許多資源就這樣白白浪費了。
採用三次握手的辦法可以防止以上現象的發生。例如在剛才情況下，a不會向b的確認發出確認，b由於收不到確認，就知道a並沒有要求建立連線。
計算機網路 三次握手
假設a為客戶端，b為服務端。首先b處於listen 監聽 狀態，等待客戶的連線請求。a向b傳送連線請求報文，syn 1,ack 0 選擇乙個初始的序號x b收到連線請求，如果同意建立連線，則向a傳送連線確認報文，syn 1,ack 1 確認號為1，同時也選擇乙個初始的序號y。a收到b的連線確認序號後...
計算機網路 TCP IP三次握手和四次揮手
udp通訊時不需要接收方確認，屬於不可靠的傳輸，可能會出現丟包現象，實際應用中要求程式設計師程式設計驗證。udp與tcp位於同一層，但它不管資料報的順序 錯誤或重發。因此，udp不被應用於那些使用虛電路的面向連線的服務，udp主要用於那些面向查詢 應答的服務，例如nfs。相對於ftp或telnet，...
計算機網路面試總結 三次握手
urg 緊急指標標誌 ack 確認序號標誌 psh push標誌 rst 重制連線標誌 syn 同步序號，用於建立連線過程 fin finish標註，用於釋放連線 握手是為了建立連線，tcp三次握手的流程圖如下 在tcp ip協議中，tcp協議提供可靠的連線服務，採用三次握手建立乙個連線 針對syn...