淺談TCP三次握手,四次揮手


今天我們來講一下TCP的三次握手和四次揮手,先來張思維導圖。

 

 

 一、TCP是什么

TCP(Transmission Control Protocol 傳輸控制協議)是一種面向連接的、可靠的、基於字節流的傳輸層通信協議。

我們知道了上述了解到了TCP的定義,通俗一點講,TCP就是一個雙方通信的一個規范標准(協議)。

我們在學習TCP握手的過程之前,首先必須要了解TCP報文頭部的一些標識信息。因為TCP握手的過程中,會使用到這些報文信息,如果沒有掌握這些信息,在學習握手的過程中,整個人都處於懵逼狀態,也是為了能夠深入TCP三次握手的原理。

1、TCP頭部報文

 

 

 (1)Source Port 和 Destination Port

兩者分別為【源端口號】和【目的端口號】,源端口號就是指本地端口,目的端口就是遠程端口。一個數據包(Pocket)被解分成數據段(Segment)后就會涉及到連接上層協議的端口問題。那么可以這么理解,我們可以想象發送方很多的窗戶,接收方也有很多的窗戶,這些窗口都標有不同的端口號,源端口號和目的端口號就分別代表從哪個規定的窗口發送到對方接收的窗口。不同的應用程序都有着不同的端口。

 

 

 擴展:應用程序的端口號和應用程序所在主機的IP地址統稱為Socket(套接字),IP,端口號,在互聯網上Socket唯一標識每一個應用程序。

源端口號+源IP+目的端口號+目的IP 成為“套接字對”,一對套接字就是一個連接,一個客戶都安於服務端之間的連接。

(2)Sequence Number

稱為【序列號】,用於TCP通信過程中某一傳輸方向上字節流的每個字節的編號,為了確保數據通信的有序性,避免網絡中亂序問題。接收端根據這個編號進行確認,保證分割的數據段在原始數據包的位置。

再通俗一點的將,每個字段再傳輸中用序列號來標記自己的位置,而這個字段就是用來完成雙方傳輸中確保字段原始位置是按照順序傳輸的,(發送方的數據是怎么一個順序,到了接收方也要確保是這個順序)

PS:初始序列號由自己定,而后續的序列號由對端的ACK決定:SN_x=ACK_y(x的序列號=y發給x的ACK),這里后面會講到的。

(3)Acknowledgement Number

稱為【確認序列號】,確認序列號是接收確認端所期望收到的下一個序列號,確認序列號應上是上次已經成功收到的數據字節序列號加1,只有當標志位中的ACK標識為1的確認序列號的字段才有效。主要用來就解決不丟包的問題。若確認序列號=N,則表明:到序列號N-1位置的所有數據都已正確收到。

在這里,現在我們只需要知道他們的作用是什么,就是在數據傳輸的時候是一段一段的,都是由序列號進行標識的,所以說,接收端沒接受一段,之后就想要的下一段序列號就稱為【確認序列號】。

(4)TCP Flag

TCP首部中有6個標識bite,他們中的多個可同時被設置為1,主要是用於操控TCP的狀態機的,依次為 URG、ACK、PSH、RST、SYN、FIN。不要求初學者全部掌握,這里面只講三個重點的標識:

ACK:這個標識可以理解為發送端發送數據到接收端,發送的時候ACK為0,標識接收端還未應答,一旦接收端接收到數據之后,就將ACK置為1,發送端接到ACK為1之后,就知道了接收端已經接收到了數據。

FIN:表示發送端已經達到數據末尾,也就是說雙方的數據傳輸完成,沒有數據可以傳送的。發送FIN標識位的TCP數據包后,連接將被斷開,這個標識的數據包也經常被用於進行端口掃描。

這個很好理解,就是說發送端只剩下最后一段數據了,同時要告訴接收端后邊沒有數據可以接收了,所以用FIN標識一下,接收端看到這個FIN之后,哦!這是接收的最后的數據了,接收完就關閉了。

 

 Window Size:稱為滑動窗口大小,所說的滑動窗口,用來進行流量控制。

二、為什么進行TCP三次握手

原因如下:

1、為了確認雙方的接受與發送能力是否正常

2、指定自己的初始化序列號,為后面的可靠傳輸做准備

3、如果是HTTPS協議的話,三次握手的這個過程還會進行數字證書的驗證以及加密密鑰的生成。

如果你了解UDP的話,TCP的出現正是彌補了UDP不可靠傳輸的缺點,但是TCP的誕生,也必然增加了連接的復雜性。

三、TCP三次握手的過程:

下面我們就看一下TCP三次握手的過程:

 

 初始狀態:客戶端處於Closed(關閉)狀態,服務器處於Listen(監聽)狀態。

 

 第一次握手:客戶端發送請求報文將SYN=j(1)初始化序列號發送給服務端,發送完畢之后,客戶端處於SYN_Send狀態。

第二次握手:服務端收到SYN請求報文之后,如果同意連接,會以自己的SYN(服務端)=K(0)和ack(1)=SYN(客戶端)+1(ACK=1)報文作為應答,服務端為SYN_Receive狀態

第三次握手:客戶端接收到服務端的SYN+ACK,然后發送ack=SYN(服務端)+1(ACK=1)確認包作為應答,客戶端轉為Established狀態

四、為什么不是一次、兩次握手

防止了服務器端的一直等待而浪費資源,為了防止已失效的連接請求報文突然又傳送到了服務端而產生的錯誤。如果此時客戶端發送的延時的握手信息服務端收到了,然后服務端進行響應,認為客戶端要和他建立連接,此時,客戶端並沒有這個意思。但服務端卻認為連接已經建立,並一直等待客戶端發送數據,這樣,服務端的很多資源就白白浪費掉了。

五、TCP四次分手

下面我們接着給大家分享一下TCP四次揮手(分手)的過程

思維導圖如下:

 

 

 六、為何要TCP三次握手/四次分手

TCP的三次握手和四次回收和你談戀愛是一模一樣的,從相識到相戀到分手,然后認識另一個女孩再不斷重復這個過程就是數據傳輸在網絡中不斷建立起三次握手和四次分手的過程。

戀愛就戀愛吧,分手就分手吧,握手握來握去,揮手揮來揮去不嫌麻煩嗎?

1、為什么要進行三次握手:

本問上面第四段也講到了,三次握手的目的是:為了防止已經失效的連接請求報文突然又傳送到了服務端而產生錯誤。

舉個簡單易懂的例子,你在微信對一個女孩表白,這條信息由於網絡的問題延時發送了。

然后此時你不耐煩了,去和微信另外一個女孩表白,然后另一個女孩告訴你同意了,然后你心里很高興,把高興的心情分享給了女孩,女孩知道了你和她在一起很高興,此時三次握手完畢,你戀愛了。

到了第二天,突然,發給第一個女孩的信息才收到,女孩認為你要和她表白,此時你已經和另外一個女孩戀愛了,然后第一個女孩發微信同意了你的表白,但是你不理睬,那個女孩還在苦苦的等待你給她分享此時此刻的高興心情。

現在我們發現如果沒有分享高興的心情給女孩(也就是第三次握手過程),那么那個女孩一直等待,白白浪費了心思,所謂的千年等不了一回。

如果你是客戶端,女孩是服務端,服務端收到延時的報文,以為你要和它連接,所以會發給你確認同意的連接,但你一直不搭理它,所以服務端的資源也就這么白白的浪費掉了。所以知道為什么要進行三次握手了吧。

在《計算機網絡》中“三次握手”的目的是為了解決“網絡中存在延遲的重復分組”的問題。

2、為什么TCP要四次分手

我們知道,TCP協議是一種面向連接的、可靠的、基於字節流的運輸層通信協議,而且TCP是全雙工模式。對於初學者來說,定義太枯燥,無味,其實意思就是你和女孩聊天是面向連接的,只有連接起來才可以通信。可靠就是你發送的信息可以保證送達到對方,全雙工意思就是你不僅可以發送消息給女孩,那個女孩也可以發送消息給你。

為什么TCP要進行四次分手?我們接着上回說,你現在和第二個女孩戀愛了,突然有一天發現第一個女孩是因為沒有收到你的表白而錯過了在一起的機會,那么你要和第二個女孩分手。那過程對應在TCP四次分手是什么樣子的呢?

你要給第二個女孩子微信發消息,我們分手吧,此時第二個女孩收到消息知道了,非常傷心,就屏蔽了你。但是此時你還沒有屏蔽她,她完全可以給你繼續發消息,她給你發消息說:好吧。此時你收到了確認消息,此時是第二次分手過程。那么女孩又給你發送消息:渣男,永遠不要來找我。此時你又收到消息,看到消息后發了一個拜拜,然后你就直接屏蔽拉黑了對方。此時女孩微信顯示你刪除了對方,然后就把你也拉黑刪除了。那么四次分手就到此為止,恭喜你,成功分手。

上述過程闡述了為什么要進行TCP四次分手,為了能夠讓對方屏蔽你直至最后雙方互相刪除掉,然后你又可以和另外一個女孩子三次握手了。

3、TCP四次分手過程

初始狀態:客戶端和服務端都在連接狀態,接下來開始進行四次分手斷開連接操作:

 

 (1)第一次分手:第一次分手無論是客戶端還是服務端都可以發起。因為TCP是全雙工的。加入客戶端發送的數據已經發送完畢,發送FIN=1告訴服務端,客戶端所有的數據全部發送完畢,服務端可以關閉接收了。但是如果服務端又數據要發給客戶端,客戶端照樣可以接收的。此時客戶端處於FIN=1等待服務端確認釋放連接狀態。

(2)第二次分手:服務端接收到客戶端的釋放請求連接之后,知道客戶端沒有數據發送給自己了,然后服務端發送ACK=1告訴客戶端接收到你發給我的消息,此時服務端處於CLOSE_WAIT等待關閉狀態。

(3)第三次分手:此時服務端向客戶端把所有的數據發送完了,然后發送一個FIN=1,用於告訴客戶端,服務端的所有數據發送完畢,客戶端你也可以關閉接收數據連接了。此時服務端狀態處於LAT_ACK狀態,來等待確認客戶端是否收到了自己的請求。

(4)第四次分手:此時如果客戶端接收到了服務端發送完畢的消息之后,就發送ACK=1,告訴服務端,客戶端已經接收到你的消息,但是我們發現上圖中有一個2MSL的延時等待。

(5)為什么要有2MSL等待延遲

對應這樣一種情況,最后客戶端發送的ACK=1給服務端的過程丟失了,服務端沒能收到,服務端怎么認為的?我已經發送完數據了,怎么客戶端沒有回應我?是不是中途丟失了?然后服務端再次發起斷開連接的請求,一個來回就是2MSL,客戶端給服務端發送的ACK=1丟失,服務端等待1MSL沒收到,然后重新發送消息需要1MSL。如果再次接收到服務端的消息,則重啟2MSL計時器,發送確認請求。客戶端只需等待2MSL,如果沒有再次收到服務端的消息,說明服務端已經接收到自己確認消息了,此時對方都關閉連接,TCP四次分手完畢。

(6)如果雙方建立連接,一方出問題

如果雙方建立連接,一方出問題怎么辦?為了防止出現上述戀愛故事中的千年等一回的情況,已經建立連接,但是服務端一直等待接收,客戶端出現問題一直不能發送。所以設計一個保活的計時器,如果一方出現問題,另一方過了這個計時器的時間,就發送試探報文,以后每隔75秒發送一次,若一連發送10個探測報文仍然沒有反應,服務端就認為客戶端除了故障,接着就關閉連接。

最后為大家整理的三次握手和四次揮手的整張圖:

 

 最后,希望各位都能找到女朋友,哈哈。

好了,今天的知識就分享到這里了。


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM