HTTP協議三次握手和四次揮手
TCP(Transmission Control Protocol) 傳輸控制協議
TCP是主機對主機層的傳輸控制協議,提供可靠的連線服務,採用三次握手確認建立一個連線:
位碼即tcp標誌位,有6種標示:
SYN(synchronous建立聯機)
ACK(acknowledgement 確認)
PSH(push傳送)
FIN(finish結束)
RST(reset重置)
URG(urgent緊急)
Sequence number(順序號碼)
Acknowledge number(確認號碼)
第一次握手:主機A傳送位碼為syn=1,隨機產生seq number=1234567的資料包到伺服器,主機B由SYN=1知道,A要求建立聯機;
第二次握手:主機B收到請求後要確認聯機資訊,向A傳送ack number=(主機A的seq+1),syn=1,ack=1,隨機產生seq=7654321的包
第三次握手:主機A收到後檢查ack number是否正確,即第一次傳送的seq number+1,以及位碼ack是否為1,若正確,主機A會再傳送ack number=(主機B的seq+1),ack=1,主機B收到後確認seq值與ack=1則連線建立成功。
完成三次握手,主機A與主機B開始傳送資料。
在TCP/IP協議中,TCP協議提供可靠的連線服務,採用三次握手建立一個連線。
第一次握手:建立連線時,客戶端傳送syn包(syn=j)到伺服器,並進入SYN_SEND狀態,等待伺服器確認;
第二次握手:伺服器收到syn包,必須確認客戶的SYN(ack=j+1),同時自己也傳送一個SYN包(syn=k),即SYN+ACK包,此時伺服器進入SYN_RECV狀態; 第三次握手:客戶端收到伺服器的SYN+ACK包,向伺服器傳送確認包ACK(ack=k+1),此包傳送完畢,客戶端和伺服器進入ESTABLISHED狀態,完成三次握手。 完成三次握手,客戶端與伺服器開始傳送資料.
例項:
IP 192.168.1.116.3337 > 192.168.1.123.7788: S 3626544836:3626544836
IP 192.168.1.123.7788 > 192.168.1.116.3337: S 1739326486:1739326486 ack 3626544837
IP 192.168.1.116.3337 > 192.168.1.123.7788: ack 1739326487,ack 1
第一次握手:192.168.1.116傳送位碼syn=1,隨機產生seq number=3626544836的資料包到192.168.1.123,192.168.1.123由SYN=1知道192.168.1.116要求建立聯機;
第二次握手:192.168.1.123收到請求後要確認聯機資訊,向192.168.1.116傳送ack number=3626544837,syn=1,ack=1,隨機產生seq=1739326486的包;
第三次握手:192.168.1.116收到後檢查ack number是否正確,即第一次傳送的seq number+1,以及位碼ack是否為1,若正確,192.168.1.116會再傳送ack number=1739326487,ack=1,192.168.1.123收到後確認seq=seq+1,ack=1則連線建立成功。
揮手告別:
【注意】中斷連線端可以是Client端,也可以是Server端。
假設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連線就這樣關閉了!
【問題】為什麼連線的時候是三次握手,關閉的時候卻是四次握手?
答:因為當Server端收到Client端的SYN連線請求報文後,可以直接傳送SYN+ACK報文。其中ACK報文是用來應答的,SYN報文是用來同步的。但是關閉連線時,當Server端收到FIN報文時,很可能並不會立即關閉SOCKET,所以只能先回復一個ACK報文,告訴Client端,"你發的FIN報文我收到了"。只有等到我Server端所有的報文都傳送完了,我才能傳送FIN報文,因此不能一起傳送。故需要四步握手。
相關文章
- TCP協議的三次握手和四次揮手TCP協議
- TCP協議特點和三次握手/四次揮手TCP協議
- 【網路】TCP協議中三次握手和四次揮手TCP協議
- 談談TCP協議的三次握手和四次揮手TCP協議
- 網路協議 - TCP/IP 三次握手和四次揮手協議TCP
- 理解TCP/IP協議三次握手四次揮手TCP協議
- TCP協議中的三次握手和四次揮手(圖解)TCP協議圖解
- TCP協議中的三次握手與四次揮手TCP協議
- 正本清源:TCP協議之三次握手和四次揮手TCP協議
- 探究 tcp 協議中的三次握手與四次揮手TCP協議
- TCP三次握手和四次揮手TCP
- TCP三次握手和四次揮手理解TCP
- 面試必問之 TCP/IP協議的三次握手 四次揮手面試TCP協議
- TCP協議的三次握手與四次揮手過程圖解TCP協議圖解
- TCP三次握手四次揮手TCP
- TCP三次握手&四次揮手TCP
- TCP 三次握手四次揮手TCP
- 簡述TCP三次握手和四次揮手TCP
- TCP 三次握手 與 四次揮手TCP
- TCP 、 UDP、三次握手、四次揮手TCPUDP
- TCP三次握手與四次揮手TCP
- TCP的三次握手四次揮手TCP
- TCP協議三次握手、四次揮手以及TCP視窗滑動機制TCP協議
- 說說TCP的三次握手和四次揮手TCP
- 圖解TCP的三次握手和四次揮手圖解TCP
- TCP 三次握手和四次揮手及其狀態TCP
- 【Java面試題】之三次握手和四次揮手Java面試題
- TCP的三次握手與四次揮手TCP
- TCP三次握手四次揮手介紹TCP
- TCP三次握手及四次揮手理解TCP
- TCP-三次握手和四次揮手簡單理解TCP
- 跟著動畫學TCP三次握手和四次揮手動畫TCP
- 看圖理解TCP的三次握手和四次揮手TCP
- 詳解TCP一:三次握手、四次揮手TCP
- tcp三次握手、四次揮手過程解析TCP
- 面試官,不要再問我三次握手和四次揮手面試
- 詼諧的談談TCP三次握手和四次揮手TCP
- TCP:三次握手和四次揮手,面試無死角答覆TCP面試