TCP连接建立的3次握手？为什么不是2次握手？为什么不是4次握手？

TCP连接建立三次握手：
①开始时客户端A和服务器端B都处于“CLOSE（关闭）”状态。随后B先进入“LISTEN（收听）”状态。

②A首先向处于“LISTEN”状态的B发送“连接建立请求报文”，报文不携带任何的数据段，但是SYN=1， seq = x。随后，A进入“SYN-SEND准备发送”状态。

③B收到“连接建立请求报文”后，同意连接，则向A发送“连接建立请求确认报文”，有，SYN=1，ACK=1，ack = x+1，seq = y。随后，B进入“SYN-RCVD准备接收”状态。

④A收到“连接建立请求确认报文”后，客户端发送“连接建立请求确认报文”，有，ACK = 1, ack = y+1, seq = x+1。随后，A进入“ESTABLISHED已建立连接”状态。服务器端B在收到ACK报文后，也进入“ESTABLISHED已建立连接”状态。

为什么不是2次握手：防止失效的连接请求报文段突然又传送到主机B
①A首先发送一个连接请求，但是该请求在网络节点上滞留了，没有收到确认。于是A重传了一次请求，并且收到了B的确认，于是连接建立，数据传输完成后，释放连接，假定A发出的第一个请求报文段并没有丢失，而是在某些网络节点上滞留，本来是一个失效的请求，但B收到后误认为是A再次发出一个新请求，于是向A发送确认，同意建立连接。

②假定采用两次握手，那么只要B发出确认，则新的连接就建立了。由于A并没有发出请求，因此不理会B的确认，也不会向B发送数据，但B却以为新的连接已经建立，并一直等待A的数据，B的许多资源就这样白白浪费了。

③假定采用三次握手，则B发出确认，但A因为并没有发请求，所以不理会B的确认，B没有收到A的确认，则连接建立失败，B知道连接建立失败。会回收资源。

④极端的情况可能由于Client用户端多次重新发送请求数据而导致Server端最后建立了N多个响应在等待，因而造成极大的资源浪费！所以，“三次握手”很有必要。

为什么不采用4次握手：
①握手握的是序列号，四次握手的过程是：（1）A发送给B 同步序号SYN+A的seq为x；2，B收到后确认收到ACK发给A，然后令ack=x+1，确认A的seq按序到达；3，B向A发送SYN+自己的序列号seq为y；4, A收到B的序列号，存储到本地，发送ack=y+1,确认收到了，发送ACK+ack和自己的新序号seq为x+1。

②其中2,3两步是完全可以归为一次发送的，所以不需要四次握手。