TCP首部分析及三次握手

2021-08-02 22:01:28 字數 3496 閱讀 4359

要解析tcp報文,首先要了解它的首部格式:

tcp協議的可靠性就體現在首部的序號和確認序號。可以保證資料的按序到達,和資料丟包後的重傳機制。

(1)序號:tcp是面向位元組流的,在乙個tcp連線中傳送的位元組流中的每乙個位元組都按順序編號,整個要傳送的位元組流的起始序號必須在建立連線時設定。假設某一報文段的序號字段值為301,而資料長度為100位元組,那麼下乙個報文應該從401開始。

(2)確認序號:是指該序號之前的所有序號都收到了,若資料在傳送過程中丟失,那麼可以馬上重傳丟失的報文資訊。對於上面的例子,如果序號欄位為301的報文在傳送過程中被丟失,並且301之前的報文都已經安全到達,那麼對方的確認欄位中就會是301,表明之前傳送的301號報文沒有接收到,需要重傳。

就是因為有序號和確認序號,所以tcp協議是非常可靠的。

(3)資料偏移:該字段將tcp報文的首部與有效載荷區分了。因為tcp首部中存在選項字段,而選項欄位的長度是可變的,所以不能用固定值來區分。

(4)6個標誌位

urg:緊急,當urg=1時,表明緊急指標字段有效。它告訴作業系統當前報文中有緊急資料,需要優先處理。所以tcp就會把該緊急資料插入到本報文段資料的最前面,而在緊急資料之後仍是普通資料。

ack:確認,僅當ack=1時,確認號字段才有效,所以ack基本上都是1。

psh:推送,當兩個應用程序進行互動式的通訊時,有時在一段的應用程序希望在鍵入乙個命令後立即就能夠收到對方的響應。在這種情況下,tcp就可以使用推送操作。當傳送方把psh置1,並立即建立乙個報文傳送出去,接收方tcp收到psh=1的報文段,就盡快的交付接受應用程序,而不用再等到整個快取都填滿了才向上交付。

rst:復位,當rst=1時,表明tcp連線中出現嚴重差錯,必須釋放連線,然後再重新建立連線。rst置1用來拒絕乙個非法的報文段或乙個非法的連線。

syn:同步,在連線建立時用來同步序號。當syn=1且ack=0時,表明這是乙個連線請求報文段。對方若同意建立連線,則應在響應報文段中使syn=1且ack=1。因此,syn置1就表示這是乙個連線請求或連線響應報文段。

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

(5)視窗:指傳送本報文段的一方的接收視窗(而不是自己的傳送視窗),表明接收方目前允許對方傳送的資料量。是為了平衡傳送與接收速度的。不至於一方過快,而另一方跟不上的情況。

(6)檢驗和:檢驗資料在傳送過程中有沒有丟失一部分資料。

urg與psh都是讓tcp優先處理該段報文,那麼它們有什麼區別呢?

urg是緊急指標,它是直接交付給程序而不進入緩衝區,程序只需處理緊急資料,其他普通資料仍需在緩衝區內等待。

而psh是將資料放入緩衝區,不用等待緩衝區被寫滿,可以立即交付,但程序處理的是當前緩衝區內的全部資料。

(1)客戶端首先主動開啟連線,然後發出連線請求syn=1,序號是1000,資料長度為0,最大段尺寸mss是1460,如果乙個段太大,封裝成幀後超過了鏈路層的最大幀長度,就必須在ip層分片,為了避免分片,客戶端宣告自己的最大段尺寸,建議伺服器端發來的段不要超過這個長度。

(2)伺服器端傳送連線確認報文,syn=1,ack=1,序號是8000,確認序號是1001,表明1001之前的報文均已收到,下次請傳送序號為1001的報文,並且客戶端的最大段尺寸為1024。

(3)客戶端傳送連線確認報文,確認收到了客戶端的連線確認報文,此時雙方都知道連線已經建立完成,確認序號是8001。

那麼對於tcp的三次握手為什麼是三次握手,而不是兩次握手呢?

假設是兩次握手:

客戶端收到了伺服器的連線響應報文後,認為此時連線已經建立。但是伺服器並不知道客戶端有沒有收到報文,那麼伺服器會一直傳送連線響應報文,而客戶端一直不回應伺服器的報文,伺服器就會一直傳送……最後造成資源浪費。

可有可能在伺服器端傳送連線響應報文後,客戶端並沒有收到,但伺服器端並不知道,伺服器端正常傳送資料,但客戶端一直沒有接受,伺服器就一直傳送資料……最後也會造成資源浪費,並且客戶端並沒有接收到資料。

所以tcp的連線只能是三次握手,雙方都確認收到了對方的連線相應報文,建立連線。

(1)首先客戶端主動關閉連線,然後傳送關閉連線請求報文fin=1,ack=1,序號為1021,資料長度為0(因為沒有傳送資料),確認序號為8011。此時客戶端進入終止等待1狀態。等待伺服器釋放鏈結。

(2)客戶端收到報文後,傳送響應報文,確認序號為1022。同時客戶端會通知上層的應用程序,釋放從客戶端暗道伺服器方向的連線。

【注:】此時客戶端關閉了連線,客戶端不能傳送資料給伺服器,但伺服器仍可以傳送資料給客戶端。

(3)客戶端收到伺服器的響應報文後,進入終止等待2狀態,等待伺服器主動傳送關閉連線請求報文。

(4)伺服器傳送關閉連線請求報文,fin=1,ack=1,序號為8011,確認序號為1022。此時伺服器進入最後確認狀態,等待客戶端的響應報文。

(5)客戶端收到伺服器的關閉連線請求報文後,傳送關閉連線響應報文,同時客戶端進入時間等待狀態,等待2msl(最長報文段壽命)後,客戶端認為連線已經關閉。

(6)伺服器收到客戶端傳送的關閉連線響應報文後,關閉連線。

至此客戶端與伺服器均已關閉連線。

那麼,在客戶端傳送完關閉連線響應報文後,為什麼要等待2msl?

其一,為了保證客戶端傳送的最後乙個響應報文能夠到達伺服器。這個響應報文有可能丟失,因而使處在最後等待狀態的伺服器收不到對己傳送的響應報文。伺服器會超時重傳關閉連線請求報文,而客戶端就能在2msl時間內收到該重傳的報文,接著客戶端重新傳送一次關閉連線響應報文,並且重新啟動2msl計時器。那麼客戶端和伺服器都會進入關閉連線狀態;但如果客戶端在傳送完關閉連線響應報文後立即進入關閉連線狀態,那麼當伺服器超時重傳關閉連線請求報文後,客戶端就無法接受該報文,那麼也無法響應,最後客戶端將無法進入關閉連線狀態。

其二,防止上一節的「已失效的連線請求報文段」出現在本連線中。客戶端在傳送完關閉連線響應報文後,再經過2msl時間後,就可以使本連線持續的時間內所產生的所有報文段都從網路中消失。這樣就可以使下乙個新的連線中不會出現這種舊的連線請求報文段。

那麼,tcp可以是3次揮手嗎?

例如:這樣可以嗎?

假設有這樣一種情況,客戶端按傳送關閉連線請求報文給伺服器,但伺服器還想傳送資料給客戶端,此時連線還沒有關閉,伺服器可以傳送資料,那麼此時客戶端並不知道伺服器是否收到了自己傳送的連線關閉請求報文,客戶端可能會重新傳送請求報文,也可能會一直等待伺服器的響應,伺服器可能接收到了,也可能沒有接收到,那麼就不能正常關閉連線了。

TCP 三次握手分析

tcp transmission control protocol 傳輸控制協議 tcp是主機對主機層的傳輸控制協議,提供可靠的連線服務,採用三次握手確認建立乙個連線 位碼即tcp標誌位,有6種標示 syn synchronous建立聯機 ack acknowledgement 確認 psh pus...

TCP三次握手分析

tcp transmission control protocol 傳輸控制協議 tcp是主機對主機層的傳輸控制協議,提供可靠的連線服務,採用三次握手確認建立乙個連線 位碼即tcp標誌位,有6種標示 syn synchronous建立聯機 ack acknowledgement 確認 psh pus...

tcp三次握手 TCP 三次握手總結

tcp特點概述 tcp segment structure 段結構 step2 server host receives syn,replie with syn ack segment 答覆syn ack報文段 step3 client receives synack,replies with ac...