TCP三次握手和四次揮手

1、三次握手

(1)三次握手的詳述

首先Client端發(fā)送連接請求報文,Server端接受連接后回復(fù)ACK報文,并為這次連接分配資源。Client端接收到ACK報文后也向Server端發(fā)生ACK報文,并分配資源,這樣TCP連接就建立了。seq是報文序號,ack的值表示應(yīng)答對方哪一個seq。

最初兩端的TCP進程都處于CLOSED關(guān)閉狀態(tài),客戶端A主動打開連接,而服務(wù)端B被動打開連接。(A、B關(guān)閉狀態(tài)CLOSED——B收聽狀態(tài)LISTEN——A同步已發(fā)送狀態(tài)SYN-SENT——B同步收到狀態(tài)SYN-RCVD——A、B連接已建立狀態(tài)ESTABLISHED

B的TCP服務(wù)器進程先創(chuàng)建傳輸控制塊TCB,準(zhǔn)備接受客戶進程的連接請求。然后服務(wù)器進程就處于LISTEN(收聽)狀態(tài),等待客戶的連接請求。若有連接請求,則作出響應(yīng)。

1)第一次握手:A的TCP進程也是首先創(chuàng)建傳輸控制塊TCB,然后向B發(fā)出連接請求報文段,(首部的同步位SYN=1初始序號seq=x),(SYN=1的報文段不能攜帶數(shù)據(jù))但要消耗掉一個序號,此時A的TCP進程進入SYN-SENT(同步已發(fā)送)狀態(tài)。

2)第二次握手:B收到連接請求報文段后,如同意建立連接,則向A發(fā)送確認,在確認報文段中(SYN=1,ACK=1,確認號ack=x+1,初始序號seq=y),測試TCP服務(wù)器進程進入SYN-RCVD(同步收到)狀態(tài);

3)第三次握手:TCP客戶進程收到B的確認后,要向B給出確認報文段(ACK=1,確認號ack=y+1,序號seq=x+1)(初始為seq=x,第二個報文段所以要+1),ACK報文段可以攜帶數(shù)據(jù),不攜帶數(shù)據(jù)則不消耗序號。TCP連接已經(jīng)建立,A進入ESTABLISHED(已建立連接)。

當(dāng)B收到A的確認后,也進入ESTABLISHED狀態(tài)。

(2)總結(jié)三次握手過程:

第一次握手:起初兩端都處于CLOSED關(guān)閉狀態(tài),Client將標(biāo)志位SYN置為1,隨機產(chǎn)生一個值seq=x,并將該數(shù)據(jù)包發(fā)送給Server,Client進入SYN-SENT狀態(tài),等待Server確認;

第二次握手:Server收到數(shù)據(jù)包后由標(biāo)志位SYN=1得知Client請求建立連接,Server將標(biāo)志位SYN和ACK都置為1,ack=x+1,隨機產(chǎn)生一個值seq=y,并將該數(shù)據(jù)包發(fā)送給Client以確認連接請求,Server進入SYN-RCVD狀態(tài),此時操作系統(tǒng)為該TCP連接分配TCP緩存和變量;

第三次握手:Client收到確認后,檢查ack是否為x+1,ACK是否為1,如果正確則將標(biāo)志位ACK置為1,ack=y+1,并且此時操作系統(tǒng)為該TCP連接分配TCP緩存和變量,并將該數(shù)據(jù)包發(fā)送給Server,Server檢查ack是否為y+1,ACK是否為1,如果正確則連接建立成功,Client和Server進入ESTABLISHED狀態(tài),完成三次握手,隨后Client和Server就可以開始傳輸數(shù)據(jù)。

起初A和B都處于CLOSED狀態(tài)——B創(chuàng)建TCB,處于LISTEN狀態(tài),等待A請求——A創(chuàng)建TCB,發(fā)送連接請求(SYN=1,seq=x),進入SYN-SENT狀態(tài)——B收到連接請求,向A發(fā)送確認(SYN=ACK=1,確認號ack=x+1,初始序號seq=y),進入SYN-RCVD狀態(tài)——A收到B的確認后,給B發(fā)出確認(ACK=1,ack=y+1,seq=x+1),A進入ESTABLISHED狀態(tài)——B收到A的確認后,進入ESTABLISHED狀態(tài)。

TCB傳輸控制塊Transmission Control Block,存儲每一個連接中的重要信息,如TCP連接表,到發(fā)送和接收緩存的指針,到重傳隊列的指針,當(dāng)前的發(fā)送和接收序號。

(3)為什么A還要發(fā)送一次確認呢?可以二次握手嗎?

答:主要為了防止已失效的連接請求報文段突然又傳送到了B,因而產(chǎn)生錯誤。如A發(fā)出連接請求,但因連接請求報文丟失而未收到確認,于是A再重傳一次連接請求。后來收到了確認,建立了連接。數(shù)據(jù)傳輸完畢后,就釋放了連接,A工發(fā)出了兩個連接請求報文段,其中第一個丟失,第二個到達了B,但是第一個丟失的報文段只是在某些網(wǎng)絡(luò)結(jié)點長時間滯留了,延誤到連接釋放以后的某個時間才到達B,此時B誤認為A又發(fā)出一次新的連接請求,于是就向A發(fā)出確認報文段,同意建立連接,不采用三次握手,只要B發(fā)出確認,就建立新的連接了,此時A不理睬B的確認且不發(fā)送數(shù)據(jù),則B一致等待A發(fā)送數(shù)據(jù),浪費資源。

(4)Server端易受到SYN攻擊?

服務(wù)器端的資源分配是在二次握手時分配的,而客戶端的資源是在完成三次握手時分配的,所以服務(wù)器容易受到SYN洪泛攻擊,SYN攻擊就是Client在短時間內(nèi)偽造大量不存在的IP地址,并向Server不斷地發(fā)送SYN包,Server則回復(fù)確認包,并等待Client確認,由于源地址不存在,因此Server需要不斷重發(fā)直至超時,這些偽造的SYN包將長時間占用未連接隊列,導(dǎo)致正常的SYN請求因為隊列滿而被丟棄,從而引起網(wǎng)絡(luò)擁塞甚至系統(tǒng)癱瘓。

防范SYN攻擊措施:降低主機的等待時間使主機盡快的釋放半連接的占用,短時間受到某IP的重復(fù)SYN則丟棄后續(xù)請求。

2、四次揮手

(1)四次揮手的詳述

  假設(shè)Client端發(fā)起中斷連接請求,也就是發(fā)送FIN報文。Server端接到FIN報文后,意思是說"我Client端沒有數(shù)據(jù)要發(fā)給你了",但是如果你還有數(shù)據(jù)沒有發(fā)送完成,則不必急著關(guān)閉Socket,可以繼續(xù)發(fā)送數(shù)據(jù)。所以你先發(fā)送ACK,"告訴Client端,你的請求我收到了,但是我還沒準(zhǔn)備好,請繼續(xù)你等我的消息"。這個時候Client端就進入FIN_WAIT狀態(tài),繼續(xù)等待Server端的FIN報文。當(dāng)Server端確定數(shù)據(jù)已發(fā)送完成,則向Client端發(fā)送FIN報文,"告訴Client端,好了,我這邊數(shù)據(jù)發(fā)完了,準(zhǔn)備好關(guān)閉連接了"。Client端收到FIN報文后,"就知道可以關(guān)閉連接了,但是他還是不相信網(wǎng)絡(luò),怕Server端不知道要關(guān)閉,所以發(fā)送ACK后進入TIME_WAIT狀態(tài),如果Server端沒有收到ACK則可以重傳。“,Server端收到ACK后,"就知道可以斷開連接了"。Client端等待了2MSL后依然沒有收到回復(fù),則證明Server端已正常關(guān)閉,那好,我Client端也可以關(guān)閉連接了。Ok,TCP連接就這樣關(guān)閉了!

數(shù)據(jù)傳輸結(jié)束后,通信的雙方都可釋放連接,A和B都處于ESTABLISHED狀態(tài)。(A、B連接建立狀態(tài)ESTABLISHED——A終止等待1狀態(tài)FIN-WAIT-1——B關(guān)閉等待狀態(tài)CLOSE-WAIT——A終止等待2狀態(tài)FIN-WAIT-2——B最后確認狀態(tài)LAST-ACK——A時間等待狀態(tài)TIME-WAIT——B、A關(guān)閉狀態(tài)CLOSED

1)A的應(yīng)用進程先向其TCP發(fā)出連接釋放報文段(FIN=1,序號seq=u),并停止再發(fā)送數(shù)據(jù),主動關(guān)閉TCP連接,進入FIN-WAIT-1(終止等待1)狀態(tài),等待B的確認。

2)B收到連接釋放報文段后即發(fā)出確認報文段,(ACK=1,確認號ack=u+1,序號seq=v),B進入CLOSE-WAIT(關(guān)閉等待)狀態(tài),此時的TCP處于半關(guān)閉狀態(tài),A到B的連接釋放。

3)A收到B的確認后,進入FIN-WAIT-2(終止等待2)狀態(tài),等待B發(fā)出的連接釋放報文段。

4)B沒有要向A發(fā)出的數(shù)據(jù),B發(fā)出連接釋放報文段(FIN=1,ACK=1,序號seq=w,確認號ack=u+1),B進入LAST-ACK(最后確認)狀態(tài),等待A的確認。

5)A收到B的連接釋放報文段后,對此發(fā)出確認報文段(ACK=1,seq=u+1,ack=w+1),A進入TIME-WAIT(時間等待)狀態(tài)。此時TCP未釋放掉,需要經(jīng)過時間等待計時器設(shè)置的時間2MSL后,A才進入CLOSED狀態(tài)。

(2)總結(jié)四次揮手過程:

起初A和B處于ESTABLISHED狀態(tài)——A發(fā)出連接釋放報文段并處于FIN-WAIT-1狀態(tài)——B發(fā)出確認報文段且進入CLOSE-WAIT狀態(tài)——A收到確認后,進入FIN-WAIT-2狀態(tài),等待B的連接釋放報文段——B沒有要向A發(fā)出的數(shù)據(jù),B發(fā)出連接釋放報文段且進入LAST-ACK狀態(tài)——A發(fā)出確認報文段且進入TIME-WAIT狀態(tài)——B收到確認報文段后進入CLOSED狀態(tài)——A經(jīng)過等待計時器時間2MSL后,進入CLOSED狀態(tài)

(3)為什么A在TIME-WAIT狀態(tài)必須等待2MSL的時間?

MSL最長報文段壽命Maximum Segment Lifetime,MSL=2

答:兩個理由:1)保證A發(fā)送的最后一個ACK報文段能夠到達B2)防止“已失效的連接請求報文段”出現(xiàn)在本連接中。

1)這個ACK報文段有可能丟失,使得處于LAST-ACK狀態(tài)的B收不到對已發(fā)送的FIN+ACK報文段的確認,B超時重傳FIN+ACK報文段,而A能在2MSL時間內(nèi)收到這個重傳的FIN+ACK報文段,接著A重傳一次確認,重新啟動2MSL計時器,最后A和B都進入到CLOSED狀態(tài),若A在TIME-WAIT狀態(tài)不等待一段時間,而是發(fā)送完ACK報文段后立即釋放連接,則無法收到B重傳的FIN+ACK報文段,所以不會再發(fā)送一次確認報文段,則B無法正常進入到CLOSED狀態(tài)。

2)A在發(fā)送完最后一個ACK報文段后,再經(jīng)過2MSL,就可以使本連接持續(xù)的時間內(nèi)所產(chǎn)生的所有報文段都從網(wǎng)絡(luò)中消失,使下一個新的連接中不會出現(xiàn)這種舊的連接請求報文段。

(4)為什么連接的時候是三次握手,關(guān)閉的時候卻是四次握手?

答:因為當(dāng)Server端收到Client端的SYN連接請求報文后,可以直接發(fā)送SYN+ACK報文。其中ACK報文是用來應(yīng)答的,SYN報文是用來同步的。但是關(guān)閉連接時,當(dāng)Server端收到FIN報文時,很可能并不會立即關(guān)閉SOCKET,所以只能先回復(fù)一個ACK報文,告訴Client端,"你發(fā)的FIN報文我收到了"。只有等到我Server端所有的報文都發(fā)送完了,我才能發(fā)送FIN報文,因此不能一起發(fā)送。故需要四步握手。

(5)為什么TIME_WAIT狀態(tài)需要經(jīng)過2MSL(最大報文段生存時間)才能返回到CLOSE狀態(tài)?

答:雖然按道理,四個報文都發(fā)送完畢,我們可以直接進入CLOSE狀態(tài)了,但是我們必須假設(shè)網(wǎng)絡(luò)是不可靠的,有可能最后一個ACK丟失。所以TIME_WAIT狀態(tài)就是用來重發(fā)可能丟失的ACK報文。

最后編輯于
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
平臺聲明:文章內(nèi)容(如有圖片或視頻亦包括在內(nèi))由作者上傳并發(fā)布,文章內(nèi)容僅代表作者本人觀點,簡書系信息發(fā)布平臺,僅提供信息存儲服務(wù)。
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市,隨后出現(xiàn)的幾起案子,更是在濱河造成了極大的恐慌,老刑警劉巖,帶你破解...
    沈念sama閱讀 227,882評論 6 531
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件,死亡現(xiàn)場離奇詭異,居然都是意外死亡,警方通過查閱死者的電腦和手機,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 98,208評論 3 414
  • 文/潘曉璐 我一進店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人,你說我怎么就攤上這事。” “怎么了?”我有些...
    開封第一講書人閱讀 175,746評論 0 373
  • 文/不壞的土叔 我叫張陵,是天一觀的道長。 經(jīng)常有香客問我,道長,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 62,666評論 1 309
  • 正文 為了忘掉前任,我火速辦了婚禮,結(jié)果婚禮上,老公的妹妹穿的比我還像新娘。我一直安慰自己,他們只是感情好,可當(dāng)我...
    茶點故事閱讀 71,477評論 6 407
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著,像睡著了一般。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發(fā)上,一...
    開封第一講書人閱讀 54,960評論 1 321
  • 那天,我揣著相機與錄音,去河邊找鬼。 笑死,一個胖子當(dāng)著我的面吹牛,可吹牛的內(nèi)容都是我干的。 我是一名探鬼主播,決...
    沈念sama閱讀 43,047評論 3 440
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了?” 一聲冷哼從身側(cè)響起,我...
    開封第一講書人閱讀 42,200評論 0 288
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后,有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體,經(jīng)...
    沈念sama閱讀 48,726評論 1 333
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點故事閱讀 40,617評論 3 354
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發(fā)現(xiàn)自己被綠了。 大學(xué)時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 42,807評論 1 369
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖,靈堂內(nèi)的尸體忽然破棺而出,到底是詐尸還是另有隱情,我是刑警寧澤,帶...
    沈念sama閱讀 38,327評論 5 358
  • 正文 年R本政府宣布,位于F島的核電站,受9級特大地震影響,放射性物質(zhì)發(fā)生泄漏。R本人自食惡果不足惜,卻給世界環(huán)境...
    茶點故事閱讀 44,049評論 3 347
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧,春花似錦、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 34,425評論 0 26
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至,卻和暖如春,著一層夾襖步出監(jiān)牢的瞬間,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 35,674評論 1 281
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人。 一個月前我還...
    沈念sama閱讀 51,432評論 3 390
  • 正文 我出身青樓,卻偏偏與公主長得像,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當(dāng)晚...
    茶點故事閱讀 47,769評論 2 372

推薦閱讀更多精彩內(nèi)容