一、三次握手的过程

TCP需要三次握手才能建立连接，整个过程如下图所示：

假设A运行的是TCP客户端进程，而B运行的是TCP服务端进程。最开始的时候两端的TCP进程都处于ClOSED（关闭）状态。

这时候，A主动打开连接，而B被动打开连接，B在打开连接之后进入LISTEN（收听）状态。

（1）第一次握手

A的TCP客户进程向B发出建立连接请求报文段，其中SYN（同步位）=1，ACK（确认位）=0，seq（序号）=x。

TCP规定，当报文段的SYN=1且ACK=0时，表明这是一个请求建立连接的；SYN报文段（SYN=1的报文段）不能携带数据，但是要消耗掉一个序号。

在A发送完毕之后，A的TCP客户端进程进入SYN-SENT（同步已发送）状态。

（2）第二次握手

B在收到连接请求报文段之后，如果同意建立连接，则向A发送确认报文段。其中SYN=1，ACK=1，ack（确认号）=x+1，同时设置自己的初始序号seq=y。

TCP规定，当报文段的SYN=1且ACK=1时，表明这是一个同一建立连接响应报文段；这个报文段也不能携带数据，同样需要消耗掉一个序号。

在B发送完毕之后，B的TCP服务端进程进入SYN-RCVD（同步收到）状态。

（3）第三次握手

A在收到B的确认报文段之后，还需要向B给出确认报文段。其中ACK=1，seq=x+1，ack=y+1。

TCP规定，这个ACK报文段可以携带数据；如果不携带数据则不消耗序号，即A下一个数据报文段的序号仍然是seq=x+1。

在A发送完毕之后，A的TCP客户端进程进入ESTABLISHED（已建立连接）状态；B在接收到A的确认报文段之后，B的服务端进程也进入ESTABLISHED（已建立连接）状态。

以上就是所说的三次握手过程。

二、三次握手的原因

为什么A还需要发送一次确认，进行第三次握手呢？主要是为了防止已失效的请求连接报文段突然又传送到了B，因而产生错误。

原因如下：

先假如出现了一种异常情况，即A发出的第一个连接请求报文段因为在某些网络节点上滞留了。由于超时重传，于是A又向B发起请求并成功建立了连接，在传输完数据之后，AB同之间释放了连接。

而在A和B已经释放连接之后，那个在网络上滞留的报文段又达到了B。这时候，B接收到报文以为是A发起的新的一次建立连接的请求，于是就向A发出确认建立连接报文段。而A此时并没有发起建立连接的请求，于是不予理睬。但是B以为新的连接已经建立，一直等待A发送数据，于是B的许多资源就浪费了。

参考资料：

1、TCP协议中的三次握手和四次挥手(图解) http://blog.csdn.net/whuslei/article/details/6667471

2、简析TCP的三次握手与四次分手 http://www.jellythink.com/archives/705

3、TCP三次握手详解及释放连接过程  http://blog.csdn.net/oney139/article/details/8103223