为什么TCP 要采用「3次握手」建立连接?1个例子教会你~

首先说说为什么是三次握手?

当客户端发送一次请求A后,但是A在网络延迟了很久, 接着客户端又发送了一次B,但是此时A已经无效了。

接着服务器相应了B,并返回TCP连接头,建立连接(这里就2次哈)。

然后,A 历经千山万水终于到服务器了, 服务器一看有请求来了,则接受。

由于一开始A带着的TCP格式都是正确的,那么服务器,理所应当的也返回成功连接的flag,但是,此时客户端已经判断该次请求无效,废弃了。

然后服务器,就这么一直挂着(浪费资源),造成的一个问题是,md, 这个锅是谁的?所以,为了保险起见,再补充一次连接就可以了。

所以3次是最合适的。在Chinese中,以3为起称为多,如果你用4,5,6,7,8...次的话,这不更浪费吗?

TCP作为一种可靠传输控制协议,其核心思想:既要保证数据可靠传输,又要提高传输的效率,而用三次恰恰可以满足以上两方面的需求。

在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状态,完成三次握手。

为什么要进行三次握手?举个栗子吧!

在红军时期,A连和B连分在左右翼,约定在几时几分一同发起打击。这个几时几分的信息就需要人工通过通讯员来走路传递。所以A连指挥官派出通讯员。

这是第一次。

假设通讯员到达了B连,并且告知了B连指挥官几时几分,B连指挥官一定会让通讯员再回去通知A连指挥官,可怜的通讯员只能冒着危险返回A连,因为A连指挥官看不到通讯员返回的话,不知道几时几分这个信息到底传达到了B连没有。

这是第二次

现在B连指挥官开始担心通讯员是否回到了A连,如果没回到,B连指挥官会设身处地的想一想A连指挥官见不到返回的通讯员,肯定是不敢打的,所以B连指挥官最盼望的是再次看到通讯员出现在B连,所以A连指挥官会让通讯员再回B连一次。

因此可以说三次握手是在最快最省力的情况下作出的选择。

上面分析还不够形象,很容易忘记,下面我们利用wireshark来证明一下上面的分析过程。

从下面的的输出就可以很容易看出来,必须要经过前面的三次tcp请求才会有起一次http请求。

第一次握手数据包,客户端发送一个TCP,标志位为SYN,序列号为0, 代表客户端请求建立连接,如下图所示

(第一次握手)

第二次握手的数据包,服务器发回确认包, 标志位为 SYN,ACK. 将确认序号(Acknowledgement Number)设置为客户的I S N加1以.即0+1=1,如下图所示

(第二次握手)

第三次握手的数据包,客户端再次发送确认包(ACK) SYN标志位为0,ACK标志位为1.并且把服务器发来ACK的序号字段+1,放在确定字段中发送给对方.并且在数据段放写ISN的+1,如下图所示

(第三次握手)

以上就是 wireshark中的tcp三次握手过程。

今天的分享就把到这了~

(0)

相关推荐