TCP狀態變遷

2021-08-31 17:06:23 字數 1361 閱讀 5297

連線建立:連線建立分要經過三次握手過程:

[quote]

1)客戶端傳送乙個syn段到指明客戶打算連線的伺服器的埠,報文段中要設定客戶端初始序號。

2)伺服器發回包含伺服器的初始序號的syn報文段作為應答。同時,將確認序號設定為客戶的初始序號加1,並設定ack位標誌報文段為確認報文段。

3)客戶端必須將確認序號設定為伺服器初始序號加1,對伺服器的syn報文段進行確認。[/quote]

關閉連線:

[quote]

當客戶端請求關閉連線時,客戶端傳送乙個fin包後,客戶端就進入fin_wait_1狀態,等待對方的確認包,

伺服器傳送乙個ack包給客戶,客戶端收到ack包後結束fin_wait_1狀態,進入fin_wait_2狀態,等待伺服器發過來的關閉請求,

伺服器發乙個fin包後,進入close_wait狀態,

當客戶端收到伺服器的fin包,fin_wait_2狀態就結束,然後給伺服器端的fin包給以乙個確認包,客戶端這時進入time_wait,

當伺服器收到確認包後,close_wait狀態結束了,

這時候伺服器端真正的關閉了連線.但是客戶端還在time_wait狀態下,

[/quote]

[quote]

什麼時候結束呢.我在這裡再講到乙個新名詞:2msl等待狀態,其實time_wait就是2msl等待狀態,

為什麼要設定這個狀態,原因是有足夠的時間讓ack包到達伺服器端,如果伺服器端沒收到ack包,超時了,然後重新發乙個fin包,直到伺服器收到ack 包.

time_wait狀態等待時間是在tcp重新啟動後不連線任何請求的兩倍.

大家有沒有發現乙個問題:如果對方在第三次握手的時候出問題,如發fin包的時候,不知道什麼原因丟了這個包,然而這邊一直處在fin_wait_2狀 態,而且tcp/ip並沒有設定這個狀態的過期時間,那他一直會保留這個狀態下去,越來越多的fin_wait_2狀態會導致系統崩潰.

[/quote]

[img]

狀態:描述

[list]

[*]closed:無連線是活動的或正在進行

[*]listen:伺服器在等待進入呼叫

[*]syn_recv:乙個連線請求已經到達,等待確認

[*]syn_sent:應用已經開始,開啟乙個連線

[*]established:正常資料傳輸狀態

[*]fin_wait1:應用說它已經完成

[*]fin_wait2:另一邊已同意釋放

[*]itmed_wait:等待所有分組死掉

[*]closing:兩邊同時嘗試關閉

[*]time_wait:另一邊已初始化乙個釋放

[*]last_ack:等待所有分組死掉

[/list]

資料整理 TCP狀態變遷

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 資料整理 tcp狀態變遷 開始 傳說中的3次握手。1.closed 起始點。在超時或者連線關閉的時候進入此狀態。2.listen server 端在等待連線過來的時候所處的狀態,s...

TCP狀態變遷流程

主動建立tcp鏈結情況 被動建立tcp鏈結情況 主動斷開鏈結的情況 被動斷開連線的情況 在time wait階段需要停留2倍的msl,msl即maximum segment lifetime,表示任何報文被丟棄前在網路內的最長時間,tcp ip詳解中額外註解了 rfc793指出msl為2min,然而...

TCP連線各狀態數量 以及TCP各狀態變遷流程

檢視linux系統中tcp連線情況 檢視系統tcp連線中各個狀態的連線數。netstat an awk tcp end 檢視和本機80埠建立連線並狀態在established的所有ip netstat an grep 80 grep esta awk awk begin sort uniq 輸出每個...