TCP协议三次握手内容，为什么不可以是两次握手？

三次握手内容：

1. 假定主机 A 运行的是 TCP 客户程序，而 B 运行 TCB 服务器程序。最初两端的 TCP 进程都处于 CLOSED（关闭）状态。
2. 一开始， B 的 TCP 服务器进程先创建传输控制块 TCB，准备接受客户进程的连接请求。然后服务器进程就处于 LISTEN（收听）状态，等待客户的连接请求。如有，即做出响应。
3. A 的 TCP 客户进程也是首先创建传输控制模块 TCB。然后，在打算进行 TCP 连接时，向B 发出连接请求报文段，这时首部中的同步位 SYN=1，同时选择一个初始序号 seq=x。TCP 规定， SYN 报文段（即 SYN=1 的报文段）不能携带数据，但要消耗掉一个序号。这时， TCP 客户进程进入 SYN-SENT（同步已发送）状态。
4. B 收到连接请求报文段后，如同意建立连接，则向 A 发送确认。在确认报文段中应把SYN 位和 ACK 位都置为 1，确认号是 ack=x+1，同时也为自己选择一个初始序号 seq=y。请注意，这个报文段也不能携带数据，但同样要消耗掉一个序号。这时 TCP 服务器进程进入 SYN-RCVD（同步收到）状态。
5. TCP 客户进程收到 B 的确认后，还要向 B 给出确认。确认报文段的 ACK 置 1，确认号ack=y+1，而自己的序号 seq=x+1。 TCP 的标准规定， ACK 报文段可以携带数据。但如果不携带数据则不消耗序号，在这种情况下，下一个数据报文段的序号仍是 seq=x+1。这时， TCP 连接已经建立， A 进入 EATABLISHED（已建立连接）状态。当 B 收到 A 的确认后，也进入ESTABLISHED（已建立连接）状态。

为什么不可以是两次握手？

当客户端向服务器端发送一个连接请求时，由于某种原因长时间驻留在网络节点中，无法到达服务器端，由于TCP的超时重传机制，当客户端在特定的时间内没有收到服务器端的的确认应答时，就会重新向服务器端发送连接请求，该请求到达服务器端并建立连接，进行数据传输，当数据传输完成时，释放了TCP连接。

若此时第一次的连接请求报文段延迟了一段时间后到达了服务器端，本来这是一个很早到达的失效的报文段，但是服务器端收到了该链接请求后误以为是客户端重新又发起了一次连接请求，于是服务器端发出确认应答报文段，并表示同意建立连接。如果没有第三次握手，由于服务器端发送了确认应答信息，则表示新的连接建立成功，但是客户端并没有向服务器端发送任何建立请求，客户端将忽略服务器端的确认报文，更不会发送任何请求或数据。而服务器端认为建立成功了，并一直在等待建立连接，直到超出计数器的设定值，则认为服务器端出现了异常，并关闭此链接。这个等待的过程中，浪费了服务器端的资源。

如果是三次握手将不会出现不该建立的连接。