三次握手建立TCP连接的过程
SYN-同步位；ACK-确认位；序号-seq；确认号-ack；
CLOSED-关闭状态；LISTEN-监听状态；SYN-SENT-同步发送状态；SYN-RCVD-同步接收状态；ESTABLISHED-连接建立状态；
SYN（同步）报文段-SYN=1的报文段，不能携带数据，但要消耗一个序号；
ACK（确认）报文段-ACK=1的报文段，可以携带数据，携带数据则消耗一个序号，不携带数据则不消耗序号；
主机A为客户端，主机B为服务端，开始，客户端和服务端均处于CLOSED状态；客户端主动打开连接，进入SYN-SENT状态，服务端被动打开连接，进入LISTEN状态。
第一次握手：客户端向服务端发出连接请求报文段（SYN报文段）， 首部中的同步位SYN=1，序号seq=x；
第二次握手：服务端收到连接请求报文段后，若同意建立连接，则向客户端发送确认报文段，首部中的同步位SYN=1，确认位ACK=1，序号seq=y，确认号ack=x+1（上一步客户端发给服务端的序号+1），服务端进入SYN-RCVD状态；
第三次握手：客户端接收到服务端的请求确认报文段后，再向服务端发送请求确认报文段，首部中的确认位ACK=1，序号seq=x+1，确认号ack=y+1（上一步服务端发给客户端的序号+1），客户端进入ESTABLISHED状态；服务端收到客户端发来的确认报文段后，也进入ESTABLISHED状态。
问题1：为什么不是两次握手？
防止客户端已经失效的连接请求报文段突然又传送到了服务端，产生错误。
客户端发出第一个连接请求报文段后，滞留在某个网络结点，客户端再次发出了第二个连接请求报文段，与服务端建立连接，数据发送结束后，释放了连接；此后服务端收到了客户端发来的第一个连接请求报文段（已经失效的连接请求报文段），误以为是客户端又发出的一次连接请求，于是向客户端发出确认报文段，若采用两次握手，此时已经建立连接；但是由于客户端没有发出建立连接的请求，所以不会理睬服务端发来的确认报文段，也不会向服务端发送数据，而服务端却一直等待客户端发送数据，白白浪费资源。
问题2：为什么不是四次握手？
第二次握手服务端向客户端发出确认报文段，该报文段可以分为两部分进行发送，确认报文段（ACK=1,ack=x+1）和同步报文段（SYN=1，seq=y），但是发送确认报文段和同步报文段没有先后顺序的要求，所以将两部分合在一起发送，将四次握手简化为三次握手，简化建立TCP连接的过程。
参考文献 《计算机网络》（第7版） 谢希仁 电子工业出版社