1. 程式人生 > >Python中的TCP三次握手和四次揮手過程

Python中的TCP三次握手和四次揮手過程

時間 斷開連接 產生 等待 ip地址 狀態 ima ack 丟失

tcp三次握手和四次揮手

技術分享圖片

首先先介紹什麽是傳輸層:

技術分享圖片

1、三次握手

1) 三次握手的詳述

首先Client(客戶)端發送連接請求報文,Server(服務器)段接受連接後回復ACK報文,並為這次連接分配資源。Client端接收到ACK報文後也向Server段發生ACK報文,並分配資源,這樣TCP連接就建立了。

技術分享圖片

最初兩端的TCP進程都處於CLOSED關閉狀態,A主動打開連接,而B被動打開連接。(A、B關閉狀態CLOSED——B收聽狀態LISTEN——A同步已發送狀態SYN-SENT——B同步收到狀態SYN-RCVD——A、B連接已建立狀態ESTABLISHED

  • B的TCP服務器進程先創建傳輸控制塊TCB,準備接受客戶進程的連接請求。然後服務器進程就處於LISTEN(收聽)狀態,等待客戶的連接請求。若有,則作出響應。
  • 1)第一次握手:A的TCP客戶進程也是首先創建傳輸控制塊TCB,然後向B發出連接請求報文段,(首部的同步位SYN=1初始序號seq=x),(SYN=1的報文段不能攜帶數據)但要消耗掉一個序號,此時TCP客戶進程進入SYN-SENT(同步已發送)狀態。
  • 2)第二次握手:B收到連接請求報文段後,如同意建立連接,則向A發送確認,在確認報文段中(SYN=1,ACK=1,確認號ack=x+1,初始序號seq=y),測試TCP服務器進程進入SYN-RCVD(同步收到)狀態;
  • 3)第三次握手:TCP客戶進程收到B的確認後,要向B給出確認報文段(ACK=1,確認號ack=y+1,序號seq=x+1)(初始為seq=x,第二個報文段所以要+1),ACK報文段可以攜帶數據,不攜帶數據則不消耗序號。TCP連接已經建立,A進入ESTABLISHED(已建立連接)。
  • 當B收到A的確認後,也進入ESTABLISHED狀態。

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

  • 第一次握手:起初兩端都處於CLOSED關閉狀態,Client將標誌位SYN置為1,隨機產生一個值seq=x,並將該數據包發送給Server,Client進入SYN-SENT狀態,等待Server確認;
  • 第二次握手:Server收到數據包後由標誌位SYN=1得知Client請求建立連接,Server將標誌位SYN和ACK都置為1,ack=x+1,隨機產生一個值seq=y,並將該數據包發送給Client以確認連接請求,Server進入SYN-RCVD狀態,此時操作系統為該TCP連接分配TCP緩存和變量;
  • 第三次握手
    :Client收到確認後,檢查ack是否為x+1,ACK是否為1,如果正確則將標誌位ACK置為1,ack=y+1,並且此時操作系統為該TCP連接分配TCP緩存和變量,並將該數據包發送給Server,Server檢查ack是否為y+1,ACK是否為1,如果正確則連接建立成功,Client和Server進入ESTABLISHED狀態,完成三次握手,隨後Client和Server就可以開始傳輸數據。

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

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

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

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

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

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

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

2、四次揮手

(1)四次揮手的詳述

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

技術分享圖片

數據傳輸結束後,通信的雙方都可釋放連接,A和B都處於ESTABLISHED狀態。(A、B連接建立狀態ESTABLISHED——A終止等待1狀態FIN-WAIT-1——B關閉等待狀態CLOSE-WAIT——A終止等待2狀態FIN-WAIT-2——B最後確認狀態LAST-ACK——A時間等待狀態TIME-WAIT——B、A關閉狀態CLOSED

  • 1)A的應用進程先向其TCP發出連接釋放報文段(FIN=1,序號seq=u),並停止再發送數據,主動關閉TCP連接,進入FIN-WAIT-1(終止等待1)狀態,等待B的確認。
  • 2)B收到連接釋放報文段後即發出確認報文段,(ACK=1,確認號ack=u+1,序號seq=v),B進入CLOSE-WAIT(關閉等待)狀態,此時的TCP處於半關閉狀態,A到B的連接釋放。
  • 3)A收到B的確認後,進入FIN-WAIT-2(終止等待2)狀態,等待B發出的連接釋放報文段。
  • 4)B沒有要向A發出的數據,B發出連接釋放報文段(FIN=1,ACK=1,序號seq=w,確認號ack=u+1),B進入LAST-ACK(最後確認)狀態,等待A的確認。
  • 5)A收到B的連接釋放報文段後,對此發出確認報文段(ACK=1,seq=u+1,ack=w+1),A進入TIME-WAIT(時間等待)狀態。此時TCP未釋放掉,需要經過時間等待計時器設置的時間2MSL後,A才進入CLOSED狀態。

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

起初A和B處於ESTABLISHED狀態——A發出連接釋放報文段並處於FIN-WAIT-1狀態——B發出確認報文段且進入CLOSE-WAIT狀態——A收到確認後,進入FIN-WAIT-2狀態,等待B的連接釋放報文段——B沒有要向A發出的數據,B發出連接釋放報文段且進入LAST-ACK狀態——A發出確認報文段且進入TIME-WAIT狀態——B收到確認報文段後進入CLOSED狀態——A經過等待計時器時間2MSL後,進入CLOSED狀態

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

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

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

  • 1)這個ACK報文段有可能丟失,使得處於LAST-ACK狀態的B收不到對已發送的FIN+ACK報文段的確認,B超時重傳FIN+ACK報文段,而A能在2MSL時間內收到這個重傳的FIN+ACK報文段,接著A重傳一次確認,重新啟動2MSL計時器,最後A和B都進入到CLOSED狀態,若A在TIME-WAIT狀態不等待一段時間,而是發送完ACK報文段後立即釋放連接,則無法收到B重傳的FIN+ACK報文段,所以不會再發送一次確認報文段,則B無法正常進入到CLOSED狀態。
  • 2)A在發送完最後一個ACK報文段後,再經過2MSL,就可以使本連接持續的時間內所產生的所有報文段都從網絡中消失,使下一個新的連接中不會出現這種舊的連接請求報文段。

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

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

(5)為什麽TIME_WAIT狀態需要經過2MSL(最大報文段生存時間)才能返回到CLOSE狀態?

答:雖然按道理,四個報文都發送完畢,我們可以直接進入CLOSE狀態了,但是我們必須假象網絡是不可靠的,有可以最後一個ACK丟失。所以TIME_WAIT狀態就是用來重發可能丟失的ACK報文。

Python中的TCP三次握手和四次揮手過程