TCP为什么是三次握手而不是两次？

一、两次握手仿佛可行

首先是客户端向服务端发送一个数据为空、SYN为1的、序列号为789的报文，然后服务端向客户端发送一个数据可以不为空、SYN为1、序列号为123的报文，此时服务端认为已经建立了连接，可以接着发送SYN为0、数据不为空序列号为124、125、126的报文。假如第二次握手服务端发送的报文123丢失了，客户端由于没有收到SYN为1的报文，所以认为没有建立连接，即使收到了124、125、126也不确认，超时后客户端就重新发送789。客户端又收到了一个SYN为1的报文，就重发123。客户端收到了重发的123，于是以123为起点建立滑动窗口，开始等待后面的报文。服务端的124、125、126也会因为没收到回应报文而重发，这样客户端就能收到124、125、126并确认了。

二、两次握手其实不行

如客户端发出连接请求，但因连接请求报文丢失而未收到确认，于是客户端再重传一次连接请求。后来收到了确认，建立了连接。数据传输完毕后，就释放了连接，客户端共发出了两个连接请求报文段，其中第一个丢失，第二个到达了服务端，但是第一个丢失的报文段只是在某些网络结点长时间滞留了，延误到连接释放以后的某个时间才到达服务端，此时服务端误认为客户端又发出一次新的连接请求，于是就向客户端发出确认报文段，同意建立连接，不采用三次握手，只要服务端发出确认，就建立新的连接了，此时客户端忽略服务端发来的确认，也不发送数据，则服务端一致等待客户端发送数据，浪费资源。

三次握手，服务端没有收到客户端发来的SYN位为1的报文时，不会重发自己的第二次握手的报文。