为什么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三次握手过程。

今天的分享就把到这了~