欧美bbbwbbbw肥妇,免费乱码人妻系列日韩,一级黄片

圖解TCP通信三次握手和四次分手

  發(fā)布時間:2014-09-24 09:07:40   作者:佚名   我要評論
這篇文章主要介紹了圖解TCP通信三次握手和四次分手,對正在學(xué)習(xí)TPC通信的同學(xué)會有些幫助,需要的朋友可以參考下

TCP協(xié)議非常重要,這里把它的連接和釋放整理一下。

首先是三次握手:

1、  客戶端發(fā)起,像服務(wù)器發(fā)送的報文SYN=1,ACK=0,然后選擇了一個初始序號:seq=x。

SYN是干什么用的?

在鏈接的時候創(chuàng)建一個同步序號,當(dāng)SYN=1同時ACK=0的時候,表明這是一個連接請求的報文段。如果對方有意鏈接,返回的報文里面SYN=1,ACK=1,。從這個意義上來說,SYN=1的時候,就表明這是一個‘請求’或者‘接受請求’的報文。

SYN=1的報文段不能攜帶數(shù)據(jù)。但是要消耗掉一個序號,

ACK是干什么用的?

僅當(dāng)ACK=1的時候,確認(rèn)字號(期望收到對方下一個報文段的第一個數(shù)據(jù)字節(jié)的編號)才有效。因此,TCP規(guī)定,當(dāng)鏈接建立之后,所有往來的報文里面的ACK都應(yīng)該是1(事實(shí)上,也只有客戶端發(fā)起的鏈接請求報文的ACK沒有置1)。

現(xiàn)在的狀態(tài):客戶端進(jìn)入SYN-SEND狀態(tài);

2、  服務(wù)器接收到了SYN=1,ACK=0的請求報文之后,返回一個SYN=1,ACK=1的確認(rèn)報文。

同時,確認(rèn)號ack=x+1,同時也為自己選擇一個初始序號seq=y

現(xiàn)在的狀態(tài):服務(wù)器進(jìn)入SYN-REVD狀態(tài);

3、  客戶端接收到了服務(wù)器的返回信息之后,還要給服務(wù)器返回最后一條確認(rèn),ACK=1,確認(rèn)號ack=y+1;

現(xiàn)在的狀態(tài):客戶端進(jìn)入ESTABLISHED狀態(tài)。

下面說一下為什么兩次握手不行,非得三次:

首先說明一種正常的情況,就是客戶端發(fā)送了一條請求鏈接的報文,但是由于網(wǎng)絡(luò)原因丟失了,所以,不可能接收到服務(wù)器端的確認(rèn)。這個時候,客戶端就就只有再一次發(fā)送原來的請求報文,這次服務(wù)器收到之后返回確認(rèn),客戶端再確認(rèn)一次,鏈接確立。

然后考慮一種不正常的情況,客戶端發(fā)了兩次請求鏈接的報文,第二條被服務(wù)器捕捉到,返回數(shù)據(jù),完成了兩次握手。數(shù)據(jù)傳送完成之后,鏈接關(guān)閉。但是這時候,第一條擁塞的請求報文現(xiàn)在到達(dá)了服務(wù)器端,服務(wù)器還以為客戶端要又一次建立連接,于是發(fā)送確認(rèn),然后把自己敞開,等著客戶端發(fā)送過來數(shù)據(jù)。于是,很多的網(wǎng)絡(luò)資源就是這樣浪費(fèi)掉了。

要是實(shí)行三次握手,服務(wù)器收到了一條過期的請求報文,返回確認(rèn)信息,客戶端接收到了服務(wù)器的信息之后感到莫名其妙。于是不置一詞。服務(wù)器過一段時間還沒有收到第三次握手的數(shù)據(jù),知道客戶端并沒有要求建立鏈接的請求,含淚離開。

然后是四次分手:

現(xiàn)在雙方的狀態(tài)都是ESTABLISHED狀態(tài)。

1、  客戶端發(fā)起請求,請求斷開鏈接。FIN=1,seq=u。u是之前傳送過來的最后一個字節(jié)的序號+1。

FIN:用來釋放一個鏈接,當(dāng)FIN=1的時候,表明此報文的發(fā)送方已經(jīng)完成了數(shù)據(jù)的發(fā)送,沒有新的數(shù)據(jù)要傳送,并要求釋放鏈接。

客戶端進(jìn)入FIN-WAIT-1狀態(tài),等著服務(wù)器返回確認(rèn);

2、  服務(wù)器收到客戶端的請求斷開鏈接的報文之后,返回確認(rèn)信息。ACK=1,seq=v,ack=u+1。

服務(wù)器進(jìn)入CLOSE-WAIT狀態(tài)。

這個時候,客戶端不能給服務(wù)器發(fā)送信息報文,只能接收。但是服務(wù)器要是還有信息要傳給服務(wù)器,仍然能傳送。

3、  當(dāng)服務(wù)器也沒有了可以傳的信息之后,給客戶端發(fā)送請求結(jié)束的報文。FIN=1,ACK=1,

ack=u+1,seq=w。

這個時候的狀態(tài):服務(wù)器進(jìn)入LAST-ACK狀態(tài)。

4、  客戶端接收到FIN=1的報文之后,返回確認(rèn)報文,ACK=1,seq=u+1,ack=w+1。

發(fā)送完畢之后,客戶端進(jìn)入等待狀態(tài),等待兩個時間周期。關(guān)閉。

為什么最后還要等待兩個時間周期呢?

1、  客戶端的最后一個ACK報文在傳輸?shù)臅r候丟失,服務(wù)器并沒有接收到這個報文。這個候。

服務(wù)器就會超時重傳這個FIN消息,然后客戶端就會重新返回最后一個ACK報文,等待兩個時間周期,完成關(guān)閉。如果不等待這兩個時間周期,服務(wù)器重傳的那條消息就不會收到。服務(wù)器就因?yàn)榻邮詹坏娇蛻舳说男畔⒍荒苷jP(guān)閉。

2、  預(yù)防上一次在三次握手中提到的失效的報文干擾。兩個時間周期過去之后,所有的報文都會在網(wǎng)絡(luò)中消失,保證下一次重新連接的時候有亂七八糟的報文影響。

相關(guān)文章

  • 三大網(wǎng)絡(luò)管理協(xié)議:SNMP、NETCONF、RESTCONF介紹

    本文將詳細(xì)介紹三種主要的協(xié)議:SNMP(Simple Network Management Protocol)、NETCONF(Network Configuration Protocol)和RESTCONF,需要的朋友可以參考下
    2024-02-13
  • 常見網(wǎng)絡(luò)協(xié)議匯總

    常見的網(wǎng)絡(luò)協(xié)議有:TCP/IP協(xié)議、UDP協(xié)議、HTTP協(xié)議、FTP協(xié)議等,本文就詳細(xì)的介紹一下常見的網(wǎng)絡(luò)協(xié)議,通過這些具體的協(xié)議更深刻的認(rèn)識整體網(wǎng)絡(luò)的傳輸流程及相關(guān)網(wǎng)絡(luò)原理,
    2023-05-30
  • L2TP和PPTP的區(qū)別小結(jié)

    本文主要介紹了L2TP和PPTP的區(qū)別,主要的前區(qū)別在于用途不同、使用要求不同,下面就來介紹一下L2TP和PPTP的聯(lián)系與區(qū)別,感興趣的可以了解一下
    2023-05-30
  • 自組織網(wǎng)絡(luò)Ad Hoc之OLSR 協(xié)議詳解

    這篇文章主要介紹了自組織網(wǎng)絡(luò)Ad Hoc之OLSR 協(xié)議詳解,需要的朋友可以參考下
    2023-05-08
  • 自組織網(wǎng)絡(luò)Ad Hoc之AODV協(xié)議詳解

    這篇文章主要介紹了自組織網(wǎng)絡(luò)Ad Hoc之AODV協(xié)議詳解,需要的朋友可以參考下
    2023-05-08
  • 自組織網(wǎng)絡(luò)Ad Hoc 網(wǎng)絡(luò)基礎(chǔ)知識

    自組織網(wǎng)絡(luò)(Ad Hoc)是一種移動通信和計算機(jī)網(wǎng)絡(luò)相結(jié)合的網(wǎng)絡(luò),是移動計算機(jī)網(wǎng)絡(luò)的一種,用戶終端可以在網(wǎng)絡(luò)內(nèi)隨意移動而保持通信
    2023-05-08
  • 一次完整的http請求過程分析

    瀏覽器輸入一個URL回車后,會發(fā)生什么呢?這里就為大家分享一下,需要的朋友可以參考下
    2022-10-19
  • 常用網(wǎng)絡(luò)協(xié)議匯總

    本篇主要是對網(wǎng)絡(luò)協(xié)議進(jìn)行一個歸納總結(jié),方便后續(xù)查閱及復(fù)習(xí),當(dāng)然如有新的認(rèn)知或新的理解,也會持續(xù)更新
    2022-10-19
  • 常用網(wǎng)絡(luò)協(xié)議匯總 詳解篇

    今日回顧網(wǎng)絡(luò)知識時,發(fā)現(xiàn)自己專門整理過一篇關(guān)于日常生活中常見的網(wǎng)絡(luò)協(xié)議知識以及作用的梳理,特發(fā)此一貼,也當(dāng)給自己鞏固網(wǎng)絡(luò)知識了,如有錯誤,望各大佬指正
    2022-10-19
  • HTTP協(xié)議的8種請求方式及常用請求方式的解析

    HTTP即超文本傳輸協(xié)議,是一種實(shí)現(xiàn)客戶端和服務(wù)器之間通信的響應(yīng)協(xié)議,它是用作客戶端和服務(wù)器之間的請求,需要的朋友可以參考下
    2022-10-19

最新評論