TCP的三次握手，看不懂的同学可以来看这里。（超详细讲解）

TCP的三次握手。

    第一次握手：建立连接时，客户端 发送 syn 包（syn=j）到 服务器，并进入 SYN_SENT 状态，等待服务器确认；

      syn：同步序列号（Synchronize Sequence Numbers）

    第二次握手：服务器 收到 客户端 发送的 syn 包，必须确认客户的ACK（ack=j+1），同时自己也发送一个 SYN包（seq=k），即 SYN+ACK包，此时服务器进入 SYN_RECV 状态；

      seq: (sequence)

      ack: 确认

    第三次握手：客户端 收到 服务器 的 SYN+ACK 包，向 服务器  发送确认包 ACK(ack=k+1），此包发送完毕，客户端和服务器进入 ESTABLISHED（TCP连接成功）状态，完成三次握手。

      established: 建立成功了

*******************************************************************************************************************************

为啥需要三次，而不是两次?

那么我们必须明白一个事情，握手是为了解决什么问题？

握手要解决的问题其实是：希望服务器端只开一个连接给客户端使用。两次握手不是一定不成功

假设 a 送信给 b（第一次）。

b 收到信，并再次写信告诉 a 她收到信了！（第二次）

这时候 a 并没有再写信给 b（没有第三次）。

表面上 a 和 b 通信已经成功，但这里其实有两种可能：

1. a 没有到 b 的信。

2. a 可以收到 b 的信。

 问题就在这里，假设只有两次握手 

 a 送信给 b,  b 收到信后再次写信传给 a（两次握手完毕）。

 但是，b 的信给 a 的时候，信丢了（b 到 a 的网络不通）。

 此时，a 没有收到信的情况下，会以为信没有发给 b。(因为是两次握手，此时的 b 只是假设 a 收到了包)

b 此时的状态是，开放了一个通道，等 a 再次写信过来。

a 此时的状态是，因为没收到回信，重新发信给 b 。（其实 a 如果收到包，那么两次握手也成功建立了连接）

那么 b 收到信之后又会开一个新通道等 a 发信过来，周而复始，就造成了网络资源浪费！！！

3次握手之后就没有这种问题吗？

3 次握手成功，证明了a 到 b 和 b 到 a 网络是通的。a 发送信息给 b，这时候有个超时时间，如果 b 的信息发送不到 a 那里（这时候会超时），那么 a 按道理会重新发送一个新请求，直到 b 收到信息且返回给 a 为止。

为什么握手的时候不直接发正文信息，因为如果网络不通的情况下，发送正文给服务器，那么服务器很容易拥堵挂掉。

总结：3次握手是为了减少因网络或其他原因造成不必要的资源浪费（a没有收到b的包的情况下）