tcp ip

建立鏈接3次握手

image.png

SYN 同步序列編號(hào)(Synchronize Sequence Numbers) 是 TCP/IP 建立連接時(shí)使用的握手信號(hào)。在客戶機(jī)和服務(wù)器之間建立正常的 TCP 網(wǎng)絡(luò)連接時(shí),客戶機(jī)首先發(fā)出一個(gè) SYN 消息,服務(wù)器使用 SYN-ACK 應(yīng)答表示接收到了這個(gè)消息,最后客戶機(jī)再以 ACK(Acknowledgement)消息響應(yīng)。這樣在客戶機(jī)和服務(wù)器之間才能建立起可靠的 TCP 連接,數(shù)據(jù)才可以在客戶機(jī)和服務(wù)器之間傳遞。

簡(jiǎn)單理解3次握手,就是要在通信開始前,確定client\server的收發(fā)功能都正常
第一次握手:Client 什么都不能確認(rèn);Server 確認(rèn)了對(duì)方發(fā)送正常,自己接收正常
第二次握手:Client 確認(rèn)了:自己發(fā)送、接收正常,對(duì)方發(fā)送、接收正常;Server 確認(rèn)了:對(duì)方發(fā)送正常,自己接收正常
第三次握手:Client 確認(rèn)了:自己發(fā)送、接收正常,對(duì)方發(fā)送、接收正常;Server 確認(rèn)了:自己發(fā)送、接收正常,對(duì)方發(fā)送、接收正常
所以三次握手就能確認(rèn)雙發(fā)收發(fā)功能都正常,缺一不可。

image.png

ack = seq + 1

為什么要發(fā)送最后一次ACK ?

一句話,主要防止已經(jīng)失效的連接請(qǐng)求報(bào)文突然又傳送到了服務(wù)器,從而產(chǎn)生錯(cuò)誤。

如果使用的是兩次握手建立連接,假設(shè)有這樣一種場(chǎng)景,客戶端發(fā)送了第一個(gè)請(qǐng)求連接并且沒有丟失,只是因?yàn)樵诰W(wǎng)絡(luò)結(jié)點(diǎn)中滯留的時(shí)間太長(zhǎng)了,由于TCP的客戶端遲遲沒有收到確認(rèn)報(bào)文,以為服務(wù)器沒有收到,此時(shí)重新向服務(wù)器發(fā)送這條報(bào)文,此后客戶端和服務(wù)器經(jīng)過兩次握手完成連接,傳輸數(shù)據(jù),然后關(guān)閉連接。此時(shí)此前滯留的那一次請(qǐng)求連接,網(wǎng)絡(luò)通暢了到達(dá)了服務(wù)器,這個(gè)報(bào)文本該是失效的,但是,兩次握手的機(jī)制將會(huì)讓客戶端和服務(wù)器再次建立連接,這將導(dǎo)致不必要的錯(cuò)誤和資源的浪費(fèi)。

如果采用的是三次握手,就算是那一次失效的報(bào)文傳送過來了,服務(wù)端接受到了那條失效報(bào)文并且回復(fù)了確認(rèn)報(bào)文,但是客戶端不會(huì)再次發(fā)出確認(rèn)。由于服務(wù)器收不到確認(rèn),就知道客戶端并沒有請(qǐng)求連接。

斷開連接4次

image.png

斷開一個(gè) TCP 連接則需要“四次揮手”:

  • 客戶端進(jìn)程發(fā)出連接釋放報(bào)文,并且停止發(fā)送數(shù)據(jù)。釋放數(shù)據(jù)報(bào)文首部,F(xiàn)IN=1,其序列號(hào)為seq=u(等于前面已經(jīng)傳送過來的數(shù)據(jù)的最后一個(gè)字節(jié)的序號(hào)加1),此時(shí),客戶端進(jìn)入FIN-WAIT-1(終止等待1)狀態(tài)。 TCP規(guī)定,F(xiàn)IN報(bào)文段即使不攜帶數(shù)據(jù),也要消耗一個(gè)序號(hào)。

  • 服務(wù)器收到連接釋放報(bào)文,發(fā)出確認(rèn)報(bào)文,ACK=1,ack=u+1,并且?guī)献约旱男蛄刑?hào)seq=v,此時(shí),服務(wù)端就進(jìn)入了CLOSE-WAIT(關(guān)閉等待)狀態(tài)。TCP服務(wù)器通知高層的應(yīng)用進(jìn)程,客戶端向服務(wù)器的方向就釋放了,這時(shí)候處于半關(guān)閉狀態(tài),即客戶端已經(jīng)沒有數(shù)據(jù)要發(fā)送了,但是服務(wù)器若發(fā)送數(shù)據(jù),客戶端依然要接受。這個(gè)狀態(tài)還要持續(xù)一段時(shí)間,也就是整個(gè)CLOSE-WAIT狀態(tài)持續(xù)的時(shí)間。

  • 客戶端收到服務(wù)器的確認(rèn)請(qǐng)求后,此時(shí),客戶端就進(jìn)入FIN-WAIT-2(終止等待2)狀態(tài),等待服務(wù)器發(fā)送連接釋放報(bào)文(在這之前還需要接受服務(wù)器發(fā)送的最后的數(shù)據(jù))。
    服務(wù)器將最后的數(shù)據(jù)發(fā)送完畢后,就向客戶端發(fā)送連接釋放報(bào)文,F(xiàn)IN=1,ack=u+1,由于在半關(guān)閉狀態(tài),服務(wù)器很可能又發(fā)送了一些數(shù)據(jù),假定此時(shí)的序列號(hào)為seq=w,此時(shí),服務(wù)器就進(jìn)入了LAST-ACK(最后確認(rèn))狀態(tài),等待客戶端的確認(rèn)。

  • 客戶端收到服務(wù)器的連接釋放報(bào)文后,必須發(fā)出確認(rèn),ACK=1,ack=w+1,而自己的序列號(hào)是seq=u+1,此時(shí),客戶端就進(jìn)入了TIME-WAIT(時(shí)間等待)狀態(tài)。注意此時(shí)TCP連接還沒有釋放,必須經(jīng)過2? *?MSL(最長(zhǎng)報(bào)文段壽命)的時(shí)間后,當(dāng)客戶端撤銷相應(yīng)的TCB后,才進(jìn)入CLOSED狀態(tài)。
    服務(wù)器只要收到了客戶端發(fā)出的確認(rèn),立即進(jìn)入CLOSED狀態(tài)。同樣,撤銷TCB后,就結(jié)束了這次的TCP連接??梢钥吹?,服務(wù)器結(jié)束TCP連接的時(shí)間要比客戶端早一些。

參考:
https://blog.csdn.net/qzcsu/article/details/72861891

最后編輯于
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請(qǐng)聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成,瀏覽時(shí)請(qǐng)結(jié)合常識(shí)與多方信息審慎甄別。
平臺(tái)聲明:文章內(nèi)容(如有圖片或視頻亦包括在內(nèi))由作者上傳并發(fā)布,文章內(nèi)容僅代表作者本人觀點(diǎn),簡(jiǎn)書系信息發(fā)布平臺(tái),僅提供信息存儲(chǔ)服務(wù)。

相關(guān)閱讀更多精彩內(nèi)容

  • 經(jīng)過面試的同學(xué)經(jīng)常會(huì)遇到這樣的問題: 你是如何理解TCP/IP協(xié)議的?回答:通訊協(xié)議?三次握手 ? 四次揮手? 一...
    BennyLoo閱讀 15,211評(píng)論 3 27
  • TCP/IP協(xié)議的工作流程如下: ●在源主機(jī)上,應(yīng)用層將一串應(yīng)用數(shù)據(jù)流傳送給傳輸層。 ●傳輸層將應(yīng)用層的數(shù)據(jù)流截成...
    杰倫哎呦哎呦閱讀 741評(píng)論 0 2
  • 學(xué)習(xí)TCP/IP,一定要看這個(gè)圖。它對(duì)排除和定位網(wǎng)絡(luò)或系統(tǒng)故障時(shí)大有幫助。 傳輸控制協(xié)議TCP簡(jiǎn)介:1.面向連接的...
    cmazxiaoma閱讀 921評(píng)論 0 1
  • 內(nèi)容來自網(wǎng)絡(luò),本文為個(gè)人總結(jié) 參考: ( https://www.cnblogs.com/buxiangxin/p...
    哥斯拉啊啊啊哦閱讀 4,485評(píng)論 0 0
  • 為什么會(huì)有TCP/IP協(xié)議 在世界上各地,各種各樣的電腦運(yùn)行著各自不同的操作系統(tǒng)為大家服務(wù),這些電腦在表達(dá)同一種信...
    S_ZY閱讀 236評(píng)論 0 0

友情鏈接更多精彩內(nèi)容