TCP三次握手 四次揮手詳解

2021-05-25 14:11:22 字數 3536 閱讀 8685

、建立連線協議(三次握手)

(1)客戶端傳送乙個帶syn標誌的tcp報文到伺服器。這是三次握手過程中的報文1。

(2) 伺服器端回應客戶端的,這是三次握手中的第2個報文,這個報文同時帶ack標誌和syn標誌。因此它表示對剛才客戶端syn報文的回應;同時又標誌syn給客戶端,詢問客戶端是否準備好進行資料通訊。

(3) 客戶必須再次回應服務段乙個ack報文,這是報文段3。

2、連線終止協議(四次揮手)

由於tcp連線是全雙工的,因此每個方向都必須單獨進行關閉。這原則是當一方完成它的資料傳送任務後就能傳送乙個fin來終止這個方向的連線。收到乙個 fin只意味著這一方向上沒有資料流動,乙個tcp連線在收到乙個fin後仍能傳送資料。首先進行關閉的一方將執行主動關閉,而另一方執行被動關閉。

(1) tcp客戶端傳送乙個fin,用來關閉客戶到伺服器的資料傳送(報文段4)。

(2) 伺服器收到這個fin,它發回乙個ack,確認序號為收到的序號加1(報文段5)。和syn一樣,乙個fin將占用乙個序號。

(3) 伺服器關閉客戶端的連線,傳送乙個fin給客戶端(報文段6)。

(4) 客戶段發回ack報文確認,並將確認序號設定為收到序號加1(報文段7)。

closed: 這個沒什麼好說的了,表示初始狀態。

listen: 這個也是非常容易理解的乙個狀態,表示伺服器端的某個socket處於監聽狀態,可以接受連線了。

syn_rcvd: 這個狀態表示接受到了syn報文,在正常情況下,這個狀態是伺服器端的socket在建立tcp連線時的三次握手會話過程中的乙個中間狀態,很短暫,基本上用netstat你是很難看到這種狀態的,除非你特意寫了乙個客戶端測試程式,故意將三次tcp握手過程中最後乙個ack報文不予傳送。因此這種狀態時,當收到客戶端的ack報文後,它會進入到established狀態。

syn_sent: 這個狀態與syn_rcvd遙想呼應,當客戶端socket執行connect連線時,它首先傳送syn報文,因此也隨即它會進入到了syn_sent狀態,並等待服務端的傳送三次握手中的第2個報文。syn_sent狀態表示客戶端已傳送syn報文。

established:這個容易理解了,表示連線已經建立了。

fin_wait_1: 這個狀態要好好解釋一下,其實fin_wait_1和fin_wait_2狀態的真正含義都是表示等待對方的fin報文。而這兩種狀態的區別是:fin_wait_1狀態實際上是當socket在established狀態時,它想主動關閉連線,向對方傳送了fin報文,此時該socket即進入到fin_wait_1狀態。而當對方回應ack報文後,則進入到fin_wait_2狀態,當然在實際的正常情況下,無論對方何種情況下,都應該馬上回應ack報文,所以fin_wait_1狀態一般是比較難見到的,而fin_wait_2狀態還有時常常可以用netstat看到。

fin_wait_2:上面已經詳細解釋了這種狀態,實際上fin_wait_2狀態下的socket,表示半連線,也即有一方要求close連線,但另外還告訴對方,我暫時還有點資料需要傳送給你,稍後再關閉連線。

time_wait: 表示收到了對方的fin報文,並傳送出了ack報文,就等2msl後即可回到closed可用狀態了。如果fin_wait_1狀態下,收到了對方同時帶fin標誌和ack標誌的報文時,可以直接進入到time_wait狀態,而無須經過fin_wait_2狀態。

closing: 這種狀態比較特殊,實際情況中應該是很少見,屬於一種比較罕見的例外狀態。正常情況下,當你傳送fin報文後,按理來說是應該先收到(或同時收到)對方的ack報文,再收到對方的fin報文。但是closing狀態表示你傳送fin報文後,並沒有收到對方的ack報文,反而卻也收到了對方的fin報文。什麼情況下會出現此種情況呢?其實細想一下,也不難得出結論:那就是如果雙方幾乎在同時close乙個socket的話,那麼就出現了雙方同時傳送fin報文的情況,也即會出現closing狀態,表示雙方都正在關閉socket連線。

close_wait: 這種狀態的含義其實是表示在等待關閉。怎麼理解呢?當對方close乙個socket後傳送fin報文給自己,你系統毫無疑問地會回應乙個ack報文給對方,此時則進入到close_wait狀態。接下來呢,實際上你真正需要考慮的事情是察看你是否還有資料傳送給對方,如果沒有的話,那麼你也就可以close這個socket,傳送fin報文給對方,也即關閉連線。所以你在close_wait狀態下,需要完成的事情是等待你去關閉連線。

last_ack: 這個狀態還是比較容易好理解的,它是被動關閉一方在傳送fin報文後,最後等待對方的ack報文。當收到ack報文後,也即可以進入到closed可用狀態了。

最後有2個問題的回答,我自己分析後的結論(不一定保證100%正確)

1、 為什麼建立連線協議是三次握手,而關閉連線卻是四次握手呢?

這是因為服務端的listen狀態下的socket當收到syn報文的建連請求後,它可以把ack和syn(ack起應答作用,而syn起同步作用)放在乙個報文裡來傳送。但關閉連線時,當收到對方的fin報文通知時,它僅僅表示對方沒有資料傳送給你了;但未必你所有的資料都全部傳送給對方了,所以你可以未必會馬上會關閉socket,也即你可能還需要傳送一些資料給對方之後,再傳送fin報文給對方來表示你同意現在可以關閉連線了,所以它這裡的ack報文和fin報文多數情況下都是分開傳送的。

2、 為什麼time_wait狀態還需要等2msl後才能返回到closed狀態?

這是因為:雖然雙方都同意關閉連線了,而且握手的4個報文也都協調和傳送完畢,按理可以直接回到closed狀態(就好比從syn_send狀態到establish狀態那樣);但是因為我們必須要假想網路是不可靠的,你無法保證你最後傳送的ack報文會一定被對方收到,因此對方處於last_ack狀態下的socket可能會因為超時未收到ack報文,而重發fin報文,所以這個time_wait狀態的作用就是用來重發可能丟失的ack報文。

什麼是2msl

msl是maximum segment lifetime英文的縮寫,中文可以譯為「報文最大生存時間」,他是任何報文在網路上存在的最長時間,超過這個時間報文將被丟棄。因為tcp報文(segment)是ip資料報(datagram)的資料部分,具體稱謂請參見《資料在網路各層中的稱呼》一文,而ip頭中有乙個ttl域,ttl是time to live的縮寫,中文可以譯為「生存時間」,這個生存時間是由源主機設定初始值但不是存的具體時間,而是儲存了乙個ip資料報可以經過的最大路由數,每經過乙個處理他的路由器此值就減1,當此值為0則資料報將被丟棄,同時傳送icmp報文通知源主機。rfc 793中規定msl為2分鐘,實際應用中常用的是30秒,1分鐘和2分鐘等。

2msl

即兩倍的msl,tcp的time_wait狀態也稱為2msl等待狀態,當tcp的一端發起主動關閉,在發出最後乙個ack包後,即第3次握手完成後傳送了第四次握手的ack包後就進入了time_wait狀態,必須在此狀態上停留兩倍的msl時間,等待2msl時間主要目的是怕最後乙個ack包對方沒收到,那麼對方在超時後將重發第三次握手的fin包,主動關閉端接到重發的fin包後可以再發乙個ack應答包。在time_wait狀態時兩端的埠不能使用,要等到2msl時間結束才可繼續使用。當連線處於2msl等待階段時任何遲到的報文段都將被丟棄。不過在實際應用中可以通過設定so_reuseaddr選項達到不必等待2msl時間結束再使用此埠。

ttl與msl是有關係的但不是簡單的相等的關係,msl要大於等於ttl。

TCP三次握手 四次揮手詳解

1 建立連線協議 三次握手 1 客戶端傳送乙個帶syn標誌的tcp報文到伺服器。這是三次握手過程中的報文1。2 伺服器端回應客戶端的,這是三次握手中的第2個報文,這個報文同時帶ack標誌和syn標誌。因此它表示對剛才客戶端syn報文的回應 同時又標誌syn給客戶端,詢問客戶端是否準備好進行資料通訊。...

TCP三次握手 四次揮手詳解

1 建立連線協議 三次握手 1 客戶端傳送乙個帶syn標誌的tcp報文到伺服器。這是三次握手過程中的報文1。2 伺服器端回應客戶端的,這是三次握手中的第2個報文,這個報文同時帶ack標誌和syn標誌。因此它表示對剛才客戶端syn報文的回應 同時又標誌syn給客戶端,詢問客戶端是否準備好進行資料通訊。...

TCP三次握手 四次揮手詳解

1 建立連線協議 三次握手 1 客戶端傳送乙個帶syn標誌的tcp報文到伺服器。這是三次握手過程中的報文1。2 伺服器端回應客戶端的,這是三次握手中的第2個報文,這個報文同時帶ack標誌和syn標誌。因此它表示對剛才客戶端syn報文的回應 同時又標誌syn給客戶端,詢問客戶端是否準備好進行資料通訊。...