三次握手
TCP建立连接的过程叫做握手，握手需要在客户和服务器之间交换三个TCP报文段。
最初客户端和服务端都处于CLOSED（关闭）状态。本例中A(Client)主动打开连接，B(Server）被动打开连接。
一开始，B的TCP服务器进程首先创建传输控制块TCB，准备接受客户端进程的连接请求。然后服务端进程就处于LISTEN（监听）状态，等待客户端的连接请求。如有，立即做出响应。
第一次握手: A的TCP客户端进程也是首先创建传输控制块TCB。然后，在打算建立TCP 连接时，向B发出连接请求报文段，这时首部中的同步位SYN=1,同时选择-一个初始序号seq=x。TCP规定, SYN报文段(即SYN=1的报文段)不能携带数据，但要消耗掉一个序号。这时，TCP客户进程进入SYN-SENT (同步已发送)状态。
第二次握手: B收到连接请求报文后，如果同意建立连接，则向A发送确认。在确认报文段中应把SYN位和ACK 位都置1,确认号是ack =x+ 1,同时也为自己选择一个初始序号seq=y。请注意，这个报文段也不能携带数据，但同样要消耗掉一个序号。 这时TCP服务端进程进入SYN-RCVD ( 同步收到)状态。
第三次握手: TCP客户进程收到B的确认后，还要向B给出确认。确认报文段的ACK置1，确认号ack=y+ 1,而自己的序号seq=x+1。这时ACK报文段可以携带数据。但如果不携带数据则不消耗序号，这种情况下，下一个数据报文段的序号仍是seq =x+1。这时，TCP连接已经建立，A进入ESTABLISHED (已建立连接)状态。.
为什么两次握手不可以呢？
为了防止已经失效的连接请求报文段突然又传送到了B,因而产生错误。比如下面这种情况：A发出的第一个连接请求报文段并没有丢失，而是在网路结点长时间滞留了，以致于延误到连接释放以后的某个时间段才到达B。本来这是一个早已失效的报文段。但是B收到此失效的链接请求报文段后，就误认为A又发出一次新的连接请求。于是就向A发出确认报文段，同意建立连接。
对于上面这种情况，如果不进行第三次握手,B发出确认后就认为新的运输连接已经建立了,并一直等待A发来数据。B的许多资源就这样白白浪费了。如果采用了三次握手，由于A实际上并没有发出建立连接请求，所以不会理睬B的确认，也不会向B发送数据。B由于收不到确认，就知道A并没有要求建立连接。
为什么不需要四次握手？
有人可能会说A发出第三次握手的信息后在没有接收到B的请求就已经进入了连接状态，那如果A的这个确认包丢失或者滞留了怎么办?我们需要明白一点，完全可靠的通信协议是不存在的。在经过三次握手之后，客户端和服务端已经可以确认之前的通信状况，都收到了确认信息。所以即便再增加握手次数也不能保证后面的通信完全可靠，所以是没有必要的。