TCP建立連線三次握手和釋放連線四次握手

2021-08-17 10:49:20 字數 4048 閱讀 7575

【尊重】

在談及tcp建立連線和釋放連線過程,先來簡單認識一下

tcp報文段首部格式

的的幾個名詞

(這裡只是簡單說明,具體請檢視相關教程)

序列號seq:佔4個位元組,用來標記資料段的

順序,tcp把連線中傳送的所有資料位元組都編上乙個序號,第乙個位元組的編號由本地隨機產生;給位元組編上序號後,就給每乙個報文段指派乙個序號;序列號seq就是這個報文段中的第乙個位元組的資料編號。

確認號ack:

佔4個位元組,

期待收到對方下乙個報文段的第乙個資料位元組的序號;序列號表示報文段攜帶資料的第乙個位元組的編號;而確認號指的是期望接收到下乙個位元組的編號;因此當前報文段最後乙個位元組的編號+1即為確認號。

確認ack:

佔1位,僅當ack=1時,確認號字段才有效。ack=0時,確認號無效

同步syn:

連線建立時用於同步序號。當syn=1,ack=0時表示:這是乙個連線請求報文段。若同意連線,則在響應報文段中使得syn=1,ack=1。因此,syn=1表示這是乙個連線請求,或連線接受報文。

syn這個標誌位只有在tcp建產連線時才會被置1,握手完成後syn標誌位被置0。

終止fin:

用來釋放乙個連線。fin=1表示:此報文段的傳送方的資料已經傳送完畢,並要求釋放運輸連線

ps:ack、syn和fin這些

大寫的單詞表示標誌位,其值要麼是1,要麼是0;ack、seq

小寫的單詞表示序號。

一、tcp建立連線三次握手

(1)、三次握手的過程

1)主機a向主機b傳送tcp連線請求資料報,其中包含主機a的初始序列號seq(a)=x。

(其中報文中同步標誌位syn=1,ack=0,表示這是乙個tcp連線請求資料報文;序號seq=x,表明傳輸資料時的第乙個資料位元組的序號是x)

;2)主機b收到請求後,會發回連線確認資料報。

(其中確認報文段中,標識位syn=1,ack=1,表示這是乙個tcp連線響應資料報文,並含主機b的初始序列號seq(b)=y,以及主機b對主機a初始序列號的確認號ack(b)=seq(a)+1=x+1)

3)第三次,主機a收到主機b的確認報文後,還需作出確認,即傳送乙個序列號seq(a)=x+1;確認號為ack(a)=y+1的報文;

(2)為什麼需要第三次握手?

還要再傳送一次確認是為了,防止已失效的連線請求報文段突然又傳到了b,因而產生錯誤。

已失效的報文段:正常情況下:a發出連線請求,但因為丟失了,故而不能收到b的確認。於是a重新發出請求,然後收到確認,建立連線,資料傳輸完畢後,釋放連線,a發了2個,乙個丟掉,乙個到達,沒有「已失效的報文段」

但是,某種情況下,a的第乙個在某個節點滯留了,延誤到達,本來這是乙個早已失效的報文段,但是在a傳送第二個,並且得到b的回應,建立了連線以後,這個報文段竟然到達了,於是b就認為,a又傳送了乙個新的請求,於是傳送確認報文段,同意建立連線,假若沒有三次的握手,那麼這個連線就建立起來了(有乙個請求和乙個回應),此時,a收到b的確認,但a知道自己並沒有傳送建立連線的請求,因為不會理睬b的這個確認,於是呢,a也不會傳送任何資料,而b呢卻以為新的連線建立了起來,一直等待a傳送資料給自己,此時b的資源就被白白浪費了。但是採用三次握手的話,a就不傳送確認,那麼b由於收不到確認,也就知道並沒有要求建立連線。

簡而言之:

第三次握手,主機

a傳送一次確認是為了防止:

如果客戶端遲遲沒有收到伺服器返回的確認報文,這時他會放棄連線,重新啟動一條連線請求;但問題是:伺服器不知客戶端沒收到,所以他會收到兩個連線請求,白白浪費了一條連線開銷。

二、tcp釋放連線四次握手

(1)四次握手過程

假設主機a為客戶端,主機b為伺服器,其釋放tcp連線的過程如下:

1) 關閉客戶端到伺服器的連線:首先客戶端a傳送乙個fin,用來關閉客戶到伺服器的資料傳送,然後等待伺服器的確認。其中終止標誌位fin=1,序列號seq=u

2) 伺服器收到這個fin,它發回乙個ack,確認號ack為收到的序號加1。

3) 關閉伺服器到客戶端的連線:也是傳送乙個fin給客戶端。

4) 客戶段收到fin後,並發回乙個ack報文確認,並將確認序號seq設定為收到序號加1。

首先進行關閉的一方將執行主動關閉,而另一方執行被動關閉。

主機a傳送fin後,進入終止等待狀態, 伺服器b收到主機a連線釋放報文段後,就立即給主機a傳送確認,然後伺服器b就進入close-wait狀態,此時tcp伺服器程序就通知高層應用程序,因而從a到b的連線就釋放了。此時是「半關閉」狀態。即a不可以傳送給b,但是b可以傳送給a。

此時,若b沒有資料報要傳送給a了,其應用程序就通知tcp釋放連線,然後傳送給a連線釋放報文段,並等待確認。a傳送確認後,進入time-wait,注意,此時tcp連線還沒有釋放掉,然後經過時間等待計時器設定的2msl後,a才進入到close狀態。

(2)為什麼要等待2msl呢?

msl即maximum segment lifetime,也就是

最大報文生存時間

,他是任何報文在網路上存在的最長時間,超過這個時間報文將被丟棄。引用《tcp/ip詳解》中的話:「它(msl)是任何報文段被丟棄前在網路內的最長時間」。rfc 793中規定msl為2分鐘,實際應用中常用的是30秒,1分鐘和2分鐘等。

tcp的time_wait狀態需要等待2msl,當tcp的一端發起主動關閉,在發出最後乙個ack包後,即第3次握手完成後傳送了第四次握手的ack包後就進入了time_wait狀態,必須在此狀態上停留兩倍的msl時間,等待2msl時間主要目的是

怕最後乙個ack包對方沒收到,那麼對方在超時後將重發第三次握手的fin包,主動關閉端接到重發的fin包後可以再發乙個ack應答包。在time_wait狀態時兩端的埠不能使用,要等到2msl時間結束才可繼續使用。當連線處於2msl等待階段時任何遲到的報文段都將被丟棄。

不過在實際應用中可以通過設定so_reuseaddr選項達到不必等待2msl時間結束再使用此埠。

概括原因如下:

①、為了保證a傳送的最後乙個ack報文段能夠到達b。即最後這個確認報文段很有可能丟失,那麼b會超時重傳,然後a再一次確認,同時啟動2msl計時器,如此下去。如果沒有等待時間,傳送完確認報文段就立即釋放連線的話,b就無法重傳了(連線已被釋放,任何資料都不能出傳了),因而也就收不到確認,就無法按照步驟進入close狀態,即必須收到確認才能close。

②、防止「已失效的連線請求報文段」出現在連線中。經過2msl,那些在這個連線持續的時間內,產生的所有報文段就可以都從網路中消失。即在這個連線釋放的過程中會有一些無效的報文段滯留在樓閣結點,但是呢,經過2msl這些無效報文段就肯定可以傳送到目的地,不會滯留在網路中。這樣的話,在下乙個連線中就不會出現上乙個連線遺留下來的請求報文段了。

可以看出:b結束tcp連線的時間比a早一點,因為b收到確認就斷開連線了,而a還得等待2msl.

(3)為什麼tcp釋放連線需要四次?

tcp建立連線要進行三次握手,而斷開連線要進行四次。這是由於tcp的半關閉造成的。因為tcp連線是全雙工的(即資料可在兩個方向上同時傳遞)所以進行關閉時每個方向上都要單獨進行關閉。這個單方向的關閉就叫半關閉。當一方完成它的資料傳送任務,就傳送乙個fin來向另一方通告將要終止這個方向的連線。

注意:1)傳送了fin只是表示這端不能繼續傳送資料(應用層不能再呼叫send傳送),但是還可以接收資料。

收到乙個 fin只意味著這一方向上沒有資料流動,乙個tcp連線在收到乙個fin後仍能傳送資料,比如:如主機a收到主機b的fin斷開tcp連線請求,只是表示主機b已經傳送完資料,主機a收到fin後作出應答,並終止這個方向的資料傳輸,此時處於半關閉狀態。但是主機a仍然可以傳送資料的,只有當主機a傳送完資料並傳送fin給主機b時,主機b才停止這個方向的資料傳輸,並關閉tcp連線。

2)在很多時候,tcp連線的斷開都會由tcp層自動進行,例如你ctrl+c終止你的程式,tcp連線依然會正常關閉,你可以寫**試試。

TCP建立連線三次握手和釋放連線四次握手

尊重 在談及tcp建立連線和釋放連線過程,先來簡單認識一下tcp報文段首部格式 的的幾個名詞 這裡只是簡單說明,具體請檢視相關教程 序列號seq 佔4個位元組,用來標記資料段的順序,tcp把連線中傳送的所有資料位元組都編上乙個序號,第乙個位元組的編號由本地隨機產生 給位元組編上序號後,就給每乙個報文...

TCP建立連線三次握手和釋放連線四次握手

尊重在談及tcp建立連線和釋放連線過程,先來簡單認識一下tcp報文段首部格式的的幾個名詞 這裡只是簡單說明,具體請檢視相關教程 序列號seq 佔4個位元組,用來標記資料段的順序,tcp把連線中傳送的所有資料位元組都編上乙個序號,第乙個位元組的編號由本地隨機產生 給位元組編上序號後,就給每乙個報文段指...

TCP建立連線(三次握手)和釋放連線(四次握手)

建立乙個自定義列表 如何建立乙個註腳 注釋也是必不可少的 katex數學公式 新的甘特圖功能,豐富你的文章 uml 圖表 flowchart流程圖 匯出與匯入 1 三次握手 建立連線 第一次握手 客戶端傳送syn包 syn x 到伺服器,並進入syn send狀態,等待伺服器確認 第二次握手 伺服器...