1. 程式人生 > >三次揮手四次揮手(轉載)

三次揮手四次揮手(轉載)

完成 bsp soc class 數據 src 三次 tcp/ip 也不會

技術分享圖片

TCP是面向連接的,無論哪一方向另一方發送數據之前,都必須先在雙方之間建立一條連接。在TCP/IP協議中,TCP 協議提供可靠的連接服務,連接是通過三次握手進行初始化的。三次握手的目的是同步連接雙方的序列號和確認號 並交換 TCP窗口大小信息。

1.第一次握手:建立連接。客戶端發送連接請求報文段,將SYN位置為1,Sequence Number為x;然後,客戶端進入SYN_SEND狀態,等待服務器的確認;

2.第二次握手:服務器收到SYN報文段。服務器收到客戶端的SYN報文段,需要對這個SYN報文段進行確認,設置Acknowledgment Number為x+1(Sequence Number+1);同時,自己自己還要發送SYN請求信息,將SYN位置為1,Sequence Number為y;服務器端將上述所有信息放到一個報文段(即SYN+ACK報文段)中,一並發送給客戶端,此時服務器進入SYN_RECV狀態;

3.第三次握手:客戶端收到服務器的SYN+ACK報文段。然後將Acknowledgment Number設置為y+1,向服務器發送ACK報文段,這個報文段發送完畢以後,客戶端和服務器端都進入ESTABLISHED狀態,完成TCP三次握手。

完成了三次握手,客戶端和服務器端就可以開始傳送數據。以上就是TCP三次握手的總體介紹。

那四次揮手呢?

當客戶端和服務器通過三次握手建立了TCP連接以後,當數據傳送完畢,肯定是要斷開TCP連接的啊。那對於TCP的斷開連接,這裏就有了神秘的“四次揮手”。

1.第一次揮手:主機1(可以使客戶端,也可以是服務器端),設置Sequence Number和Acknowledgment Number,向主機2發送一個FIN報文段;此時,主機1進入FIN_WAIT_1狀態;這表示主機1沒有數據要發送給主機2了;

2.第二次揮手:主機2收到了主機1發送的FIN報文段,向主機1回一個ACK報文段,Acknowledgment Number為Sequence Number加1;主機1進入FIN_WAIT_2狀態;主機2告訴主機1,我也沒有數據要發送了,可以進行關閉連接了;

3.第三次揮手:主機2向主機1發送FIN報文段,請求關閉連接,同時主機2進入CLOSE_WAIT狀態;

4.第四次揮手:主機1收到主機2發送的FIN報文段,向主機2發送ACK報文段,然後主機1進入TIME_WAIT狀態;主機2收到主機1的ACK報文段以後,就關閉連接;此時,主機1等待2MSL後依然沒有收到回復,則證明Server端已正常關閉,那好,主機1也可以關閉連接了。

至此,TCP的四次揮手就這麽愉快的完成了。當你看到這裏,你的腦子裏會有很多的疑問,很多的不懂,感覺很淩亂;沒事,我們繼續總結。

為什麽要三次握手?

既然總結了TCP的三次握手,那為什麽非要三次呢?怎麽覺得兩次就可以完成了。那TCP為什麽非要進行三次連接呢?在謝希仁的《計算機網絡》中是這樣說的:

為了防止已失效的連接請求報文段突然又傳送到了服務端,因而產生錯誤。

在書中同時舉了一個例子,如下:

"已失效的連接請求報文段”的產生在這樣一種情況下:client發出的第一個連接請求報文段並沒有丟失,

而是在某個網絡結點長時間的滯留了,以致延誤到連接釋放以後的某個時間才到達server。本來這是一

個早已失效的報文段。但server收到此失效的連接請求報文段後,就誤認為是client再次發出的一個新

的連接請求。於是就向client發出確認報文段,同意建立連接。假設不采用“三次握手”,那麽只要server

發出確認,新的連接就建立了。由於現在client並沒有發出建立連接的請求,因此不會理睬server的確認,

也不會向server發送數據。但server卻以為新的運輸連接已經建立,並一直等待client發來數據。這樣,

server的很多資源就白白浪費掉了。采用“三次握手”的辦法可以防止上述現象發生。例如剛才那種情況,

client不會向server的確認發出確認。server由於收不到確認,就知道client並沒有要求建立連接。"

這就很明白了,防止了服務器端的一直等待而浪費資源。

為什麽要四次揮手?

那四次揮手又是為何呢?TCP協議是一種面向連接的、可靠的、基於字節流的運輸層通信協議。TCP是全雙工 模式,這就意味著,當主機1發出FIN報文段時,只是表示主機1已經沒有數據要發送了,主機1告訴主機2, 它的數據已經全部發送完畢了;但是,這個時候主機1還是可以接受來自主機2的數據;當主機2返回ACK報文 段時,表示它已經知道主機1沒有數據發送了,但是主機2還是可以發送數據到主機1的;當主機2也發送了FIN 報文段時,這個時候就表示主機2也沒有數據要發送了,就會告訴主機1,我也沒有數據要發送了,之後彼此 就會愉快的中斷這次TCP連接。如果要正確的理解四次揮手的原理,就需要了解四次揮手過程中的狀態變化。

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連接,但另外還告訴對方,我暫時還有點數據需要傳送給你(ACK信息),稍後再關閉連接。 (主動方)

CLOSE_WAIT:這種狀態的含義其實是表示在等待關閉。怎麽理解呢?當對方close一個SOCKET後發送FIN 報文給自己,你系統毫無疑問地會回應一個ACK報文給對方,此時則進入到CLOSE_WAIT狀態。接下來呢,實 際上你真正需要考慮的事情是察看你是否還有數據發送給對方,如果沒有的話,那麽你也就可以 close這個 SOCKET,發送FIN報文給對方,也即關閉連接。所以你在CLOSE_WAIT狀態下,需要完成的事情是等待你去關 閉連接。(被動方)

LAST_ACK: 這個狀態還是比較容易好理解的,它是被動關閉一方在發送FIN報文後,最後等待對方的ACK報 文。當收到ACK報文後,也即可以進入到CLOSED可用狀態了。(被動方)

TIME_WAIT: 表示收到了對方的FIN報文,並發送出了ACK報文,就等2MSL後即可回到CLOSED可用狀態了。 如果FINWAIT1狀態下,收到了對方同時帶FIN標誌和ACK標誌的報文時,可以直接進入到TIME_WAIT狀態,而無 須經過FIN_WAIT_2狀態。(主動方)

CLOSED: 表示連接中斷。

原文出自:https://www.cnblogs.com/shihaochangeworld/p/5770294.html

三次揮手四次揮手(轉載)