简述TCP协议的三次握手以及为什么2次握手不行

第一次握手：

客户端向服务器发出连接请求报文，这时报文首部中的同部位SYN=1，同时随机生成初始序列号 seq=x，此时，TCP客户端进程进入了 SYN-SENT（同步已发送状态）状态。TCP规定，SYN报文（SYN=1的报文段）不能携带数据，但需要消耗掉一个序号。这个三次握手中的开始。表示客户端想要和服务端建立连接。

第二次握手：

TCP服务器收到请求报文后，如果同意连接，则发出确认报文。确认报文中应该 ACK=1，SYN=1，确认号是ack=x+1(x+1 则代表是我们2个之间的通信)，同时也要为自己随机初始化一个序列号 seq=y，此时，TCP服务器进程进入了SYN-RCVD（同步收到）状态。这个报文也不能携带数据，但是同样要消耗一个序号。这个报文带有SYN(建立连接)和ACK(确认)标志，询问客户端是否准备好。

第三次握手：

客户端收到服务器的SYN+ACK包，然后就会像服务器发送确认包ACK（ack=y+1）(y+1 则代表是我们2个之间的通信)和SYN（seq=x+1）(代表客户端第二次发送报文了 也就是第三次握手了)，等到这个包发送完毕之后客户端和服务器就会进入ESTABLISHED状态，完成三次握手，而后就可以在服务端和客户端之间传输数据。此时SYN标志位已经不需要，因为当我们发送ACK标志位的时候代表三次握手成功，已经建立完连接了，接下来可以传送数据过去了。

既然都有SYN包那为什么还要ACK来确认呢？

SYN是同步序号，当 SYN=1 而ACK=0 时，表明这是一个连接请求报文。对方若同意建立连接，则应在响应报文中使 SYN=1 和 ACK=1。因此SYN置1就表示这是一个连接请求或连接接受报文。而ACK状态是用来确认是否同意连接。也就是传了 SYN，证明发送方到接收方的通道没有问题，但是接收方到发送方的通道还需要 ACK 信号来进行验证。

为什么要三次握手呢？

想象一下假如2次握手客户端向服务端发送请求，但是由于网络原因请求滞留了，客户端把这次请求当作失效报文处理，但是服务端接收到这个报文后会告诉客户端我同意建立链接，然后会一直等待客户端发送数据，然而客户端已经把这次请求当作失效报文处理，服务端就会白白的在那浪费资源！

如果只有一次握手问题更大，同样也会出现2次握手出现的问题，客户端请求过来也不管同没同意直接开始发送数据问题就会有很多，并且从安全角度考虑：假如服务端同意了就会在对应端口等待数据，此时并没有ack seq交互，随便客户端都能在这个端口发送数据。