首先：客户端和服务器端都处于关闭状态，客户端主动打开，服务器被动打开
（1）服务器创建tcb（传输控制块），等待接收客户端的请求，处于listen状态
（2）客户端也创建tcb（传输控制块）。想服务器发送请求报文段，这是首部的SYN设置为1，同时选择一个初序号x，seq=x，TCP规定SYN报文段（SYN=1）不能携带数据，但是需要消耗一个序号，同时TCP进入SYN_send状态
（3）客户端接收到了请求报文段的时候，发送确认报文，将ACK=1，SYN=1，确认序号ack=x+1（因为上一次消耗了一个序号，所以服务器希望客户端下次从x+1的序号开始发送数据），同时为自己设置一个序号（seq=1），发送后自己处于SYN_RECV状态，因为这个时候也不能携带数据，但是还是需要消耗一个序号
（4）客户端接收后，在继续向服务器发送一个确认报文，ACK=1,因为这个时候没有SYN，所以可以携带数据，也可以不携带数据，但是不携带数据的话也不会再向前两次消耗一个序号了。seq=x+1（因为上一次确认序号是x+1），ack=y+1（希望服务器下一次从y+1开始发送数据）这个结束后A进入ESTABLISHED(已建立连接状态)
（5）B接收到后也进入了已建立连接状态
为什么不是两次握手而是三次握手
“已失效的连接请求报文段”的产生在这样一种情况下：client发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达server。本来这是一个早已失效的报文段。但server收到此失效的连接请求报文段后，就误认为是client再次发出的一个新的连接请求。于是就向client发出确认报文段，同意建立连接。假设不采用“三次握手”，那么只要server发出确认，新的连接就建立了。由于现在client并没有发出建立连接的请求，因此不会理睬server的确认，也不会向server发送ack包。但server却以为新的运输连接已经建立，并一直等待client发来数据。这样，server的很多资源就白白浪费掉了。采用“三次握手”的办法可以防止上述现象发生。例如刚才那种情况，client不会向server的确认发出确认。server由于收不到确认，就知道client并没有要求建立连接。
同时如果没有向上面的情况有先后达到，如果两个同时到达的话，可能会发生死锁的情况