TCP的三次握手與四次揮手理解

2022-06-08 06:39:10 字數 3494 閱讀 8209

本文經過借鑑書籍資料、他人部落格總結出的知識點,歡迎提問

序列號seq:佔4個位元組,用來標記資料段的順序,tcp把連線中傳送的所有資料位元組都編上乙個序號,第乙個位元組的編號由本地隨機產生;給位元組編上序號後,就給每乙個報文段指派乙個序號;序列號seq就是這個報文段中的第乙個位元組的資料編號。

確認號ack:佔4個位元組,期待收到對方下乙個報文段的第乙個資料位元組的序號;序列號表示報文段攜帶資料的第乙個位元組的編號;而確認號指的是期望接收到下乙個位元組的編號;因此當前報文段最後乙個位元組的編號+1即為確認號。

確認ack:佔1位,僅當ack=1時,確認號字段才有效。ack=0時,確認號無效

同步syn:連線建立時用於同步序號。當syn=1,ack=0時表示:這是乙個連線請求報文段。若同意連線,則在響應報文段中使得syn=1,ack=1。因此,syn=1表示這是乙個連線請求,或連線接受報文。syn這個標誌位只有在tcp建產連線時才會被置1,握手完成後syn標誌位被置0。

終止fin:用來釋放乙個連線。fin=1表示:此報文段的傳送方的資料已經傳送完畢,並要求釋放運輸連線

ps:ack、syn和fin這些大寫的單詞表示標誌位,其值要麼是1,要麼是0;ack、seq小寫的單詞表示序號。

字段   含義

urg  緊急指標是否有效。為1,表示某一位需要被優先處理

ack   確認號是否有效,一般置為1。

psh   提示接收端應用程式立即從tcp緩衝區把資料讀走。

rst   對方要求重新建立連線,復位。

syn   請求建立連線,並在其序列號的字段進行序列號的初始值設定。建立連線,設定為1

fin       希望斷開連線。

第一次握手:建立連線時,客戶端傳送syn包(syn=j)到伺服器,並進入syn_sent狀態,等待伺服器確認;syn:同步序列編號(synchronize sequence numbers)。

第二次握手:伺服器收到syn包,必須確認客戶的syn(ack=j+1),同時自己也傳送乙個syn包(syn=k),即syn+ack包,此時伺服器進入syn_recv狀態;

第三次握手:客戶端收到伺服器的syn+ack包,向伺服器傳送確認包ack(ack=k+1),此包傳送完畢,客戶端和伺服器進入established(tcp連線成功)狀態,完成三次握手。

1)客戶端程序發出連線釋放報文,並且停止傳送資料。釋放資料報文首部,fin=1,其序列號為seq=u(等於前面已經傳送過來的資料的最後乙個位元組的序號加1),此時,客戶端進入fin-wait-1(終止等待1)狀態。 tcp規定,fin報文段即使不攜帶資料,也要消耗乙個序號。

2)伺服器收到連線釋放報文,發出確認報文,ack=1,ack=u+1,並且帶上自己的序列號seq=v,此時,服務端就進入了close-wait(關閉等待)狀態。tcp伺服器通知高層的應用程序,客戶端向伺服器的方向就釋放了,這時候處於半關閉狀態,即客戶端已經沒有資料要傳送了,但是伺服器若傳送資料,客戶端依然要接受。這個狀態還要持續一段時間,也就是整個close-wait狀態持續的時間。

3)客戶端收到伺服器的確認請求後,此時,客戶端就進入fin-wait-2(終止等待2)狀態,等待伺服器傳送連線釋放報文(在這之前還需要接受伺服器傳送的最後的資料)。

4)伺服器將最後的資料傳送完畢後,就向客戶端傳送連線釋放報文,fin=1,ack=u+1,由於在半關閉狀態,伺服器很可能又傳送了一些資料,假定此時的序列號為seq=w,此時,伺服器就進入了last-ack(最後確認)狀態,等待客戶端的確認。

5)客戶端收到伺服器的連線釋放報文後,必須發出確認,ack=1,ack=w+1,而自己的序列號是seq=u+1,此時,客戶端就進入了time-wait(時間等待)狀態。注意此時tcp連線還沒有釋放,必須經過2∗∗msl(最長報文段壽命)的時間後,當客戶端撤銷相應的tcb後,才進入closed狀態。

6)伺服器只要收到了客戶端發出的確認,立即進入closed狀態。同樣,撤銷tcb後,就結束了這次的tcp連線。可以看到,伺服器結束tcp連線的時間要比客戶端早一些。

常見面試題

【問題1】為什麼連線的時候是三次握手,關閉的時候卻是四次握手?

答:因為當server端收到client端的syn連線請求報文後,可以直接傳送syn+ack報文。其中ack報文是用來應答的,syn報文是用來同步的。但是關閉連線時,當server端收到fin報文時,很可能並不會立即關閉socket,所以只能先回覆乙個ack報文,告訴client端,"你發的fin報文我收到了"。只有等到我server端所有的報文都傳送完了,我才能傳送fin報文,因此不能一起傳送。故需要四步握手。

【問題2】為什麼time_wait狀態需要經過2msl(最大報文段生存時間)才能返回到close狀態?

答:雖然按道理,四個報文都傳送完畢,我們可以直接進入close狀態了,但是我們必須假象網路是不可靠的,有可以最後乙個ack丟失。所以time_wait狀態就是用來重發可能丟失的ack報文。在client傳送出最後的ack回覆,但該ack可能丟失。server如果沒有收到ack,將不斷重**送fin片段。所以client不能立即關閉,它必須確認server接收到了該ack。client會在傳送出ack之後進入到time_wait狀態。client會設定乙個計時器,等待2msl的時間。如果在該時間內再次收到fin,那麼client會重發ack並再次等待2msl。所謂的2msl是兩倍的msl(maximum segment lifetime)。msl指乙個片段在網路中最大的存活時間,2msl就是乙個傳送和乙個回覆所需的最大時間。如果直到2msl,client都沒有再次收到fin,那麼client推斷ack已經被成功接收,則結束tcp連線。

【問題3】為什麼不能用兩次握手進行連線?

答:3次握手完成兩個重要的功能,既要雙方做好傳送資料的準備工作(雙方都知道彼此已準備好),也要允許雙方就初始序列號進行協商,這個序列號在握手過程中被傳送和確認。

現在把三次握手改成僅需要兩次握手,死鎖是可能發生的。作為例子,考慮計算機s和c之間的通訊,假定c給s傳送乙個連線請求分組,s收到了這個分組,併發 送了確認應答分組。按照兩次握手的協定,s認為連線已經成功地建立了,可以開始傳送資料分組。可是,c在s的應答分組在傳輸中被丟失的情況下,將不知道s 是否已準備好,不知道s建立什麼樣的序列號,c甚至懷疑s是否收到自己的連線請求分組。在這種情況下,c認為連線還未建立成功,將忽略s發來的任何資料分 組,只等待連線確認應答分組。而s在發出的分組超時後,重**送同樣的分組。這樣就形成了死鎖。

【問題4】如果已經建立了連線,但是客戶端突然出現故障了怎麼辦?

tcp還設有乙個保活計時器,顯然,客戶端如果出現故障,伺服器不能一直等下去,白白浪費資源。伺服器每收到一次客戶端的請求後都會重新復位這個計時器,時間通常是設定為2小時,若兩小時還沒有收到客戶端的任何資料,伺服器就會傳送乙個探測報文段,以後每隔75秒鐘傳送一次。若一連傳送10個探測報文仍然沒反應,伺服器就認為客戶端出了故障,接著就關閉連線。

TCP三次握手 四次揮手理解

tcp三次握手建立連線 第一次握手 客戶端傳送給伺服器一段連線請求報文,等待伺服器回應 第二次握手 伺服器收到報文,並傳送給客戶端乙個確認報文,等待客戶端回應 第三次握手 客戶端收到新報文 再傳送給伺服器乙個確認報文,完成三次握手 tcp四次揮手斷開連線 第一次揮手 客戶端傳送一段結束請求報文,等待...

TCP的三次握手與四次揮手理解

影象時最直觀的解釋 序列號seq 佔4個位元組,用來標記資料段的順序,tcp把連線中傳送的所有資料位元組都編上乙個序號,第乙個位元組的編號由本地隨機產生 給位元組編上序號後,就給每乙個報文段指派乙個序號 序列號seq就是這個報文段中的第乙個位元組的資料編號。確認號ack 佔4個位元組,期待收到對方下...

Tcp三次握手與四次揮手

tcp三次握手 四次揮手 在tcp ip協議中,tcp協議提供可靠的連線服務,採用三次握手建立乙個連線。第一次握手 建立連線時,客戶端傳送syn包 syn j 到伺服器,並進入syn send狀態,等待伺服器確認 syn 同步序列編號 synchronize sequence numbers 第二次...