TCP三次握手和四次揮手

一、tcp連線建立（三次握手）

第一次握手

建立連線。客戶端a向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狀態。

為什麼採用三次握手？

為了防止已失效的連線請求報文段突然又傳送到了b，因而產生錯誤。「已失效的連線請求報文段」是指a發出的第乙個連線請求報文段並沒有丟失，而是在某些網路結點長時間滯留了，以致延誤到連線釋放以後的某個實踐才到達b。本來這時乙個早已失效的報文段。但b收到此失效的連線請求報文段後，就誤認為是a又發出一次新的連線請求，於是就向a發出確認報文段，同意建立連線。假定不採用三次握手，那麼只要b發出確認，新的連線就建立了。

由於現在a並沒有發出建立連線的請求，因此不會理睬b的確認，也不會向b傳送資料。但b卻以為新的運輸連線已經建立了，並一直等待a發來資料。b的許多資源就這樣白白浪費了。採用三次握手的辦法可以防止上述情況發生。a不會向b的確認發出確認。b由於收不到確認就知道a並沒有要求建立連線。

二、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（根據tcp標準，前面傳送過的fin報文段要消耗乙個序號）。然後進入到timt-wait(時間等待)狀態。請注意，現在tcp連線還沒有釋放掉。必須經過時間等待計時器（time-wait timer）設定的時間2msl後，a才進入到closed狀態。時間msl叫做最長報文段壽命（maximum segment lifetime）,rfc793建議設定為2分鐘。因此tcp允許不同的實現可根據具體情況使用更小的msl值。因此，從a進入到time-wait狀態後，要經過4分鐘才能進入到closed狀態。才能開始建立下乙個連線。當a撤銷相應的傳輸控制塊後，就結束了這次的tcp連線。

TCP三次握手和四次揮手

tcp 四次揮手 TCP的三次握手和四次揮手

TCP三次握手和四次揮手

TCP三次握手和四次揮手

相關推薦