三次握手

第一次握手

当客户端向服务器发起连接请求时，客户端会发送同步序列标号SYN到服务器，
在这里我们设SYN为x，等待服务器确认，这时客户端的状态为SYN_SENT。

第二次握手

当服务器收到客户端发送的SYN后，服务器要做的是确认客户端发送过来的SYN，在这里服务器发送确认包ACK，这里的ACK为x+1，意思是说“我收到了你发送的SYN了”，
同时，服务器也会向客户端发送一个SYN包，这里我们设SYN为y。这时服务器的状态为SYN_RECV。
一句话，服务器端发送SYN和ACK两个包。

第三次握手

客户端收到服务器发送的SYN和ACK包后，需向服务器发送确认包ACK，，这里的ACK为y+1，发送完毕后，客户端的状态为ESTABLISH，服务器收到ACK之后状态为ESTABLISH，即TCP连接成功。

注意

在三次握手中，客户端和服务器端都发送两个包SYN和ACK，只不过服务器端的两个包是一次性发过来的，客户端的两个包是分两次发送的。

四次挥手

当A端和B端要断开连接时，需要四次握手，这里称为四次挥手。
断开连接请求可以由客户端发出，也可以由服务器端发出，在这里我们称A端向B端请求断开连接。

第一次挥手

A端向B端请求断开连接时会向B端发送一个带有FIN标记的报文段，这里的FIN是Finish的意思。A端状态变为FIN_WAIT_1

第二次挥手

B端收到A发送的FIN后，B段现在可能现在还有数据没有传完，所以B端并不会马上向A端发送FIN，而是先发送一个确认序号ACK，意思是说“你发的断开连接请求我收到了，但是我现在还有数据没有发完，请稍等一下呗”。
Server状态变为CLOSE_WAIT
Client收到序号为(M+1)的ACK后状态变为FIN_WAIT_2

第三次挥手

当B端的事情忙完了，那么此时B端就可以断开连接了，此时B端向A端发送FIN序号，意思是这次可以断开连接了。
Server端状态变为LAST_ACK

第四次挥手

A端收到B端发送的FIN后，会向B端发送确认ACK，Client状态变为TIME_WAIT
Server端收到序号为(N+1)的ACK,Server的状态变为CLOSED
然后经过两个MSL时长后断开连接,Client的状态也变为CLOSE
至此，一个完整的TCP连接就关闭了。

MSL是Maximum Segment Lifetime，最大报文段生存时间，2个MSL是报文段发送和接收的最长时间。

状态详解

1、LISTENING状态
服务器TCP连接到一半
2、ESTABLISHED状态
建立了连接，两台机器正在通信。
3、CLOSE_WAIT
服务器关闭到一般等待客户端发ack
4、TIME_WAIT
服务端收到fin并发送ack之后

其他问题

为什么TCP连接是三次，挥手确是四次？

在TCP连接中，服务器端的SYN和ACK向客户端发送是一次性发送的，而在断开连接的过程中，B端向A端发送的ACK和FIN是是分两次发送的。因为在B端接收到A端的FIN后，B端可能还有数据要传输，所以先发送ACK，等B端处理完自己的事情后就可以发送FIN断开连接了。

两次握手可以么？

TCP连接时是三次握手，那么两次握手可行吗？

在谢希仁著《计算机网络》第六版中讲"三次握手"的目的是"为了防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误"。

假定出现一种异常情况下：client发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达server。本来这是一个早已失效的报文段。但server收到此失效的连接请求报文段后，就误认为是client再次发出的一个新的连接请求。于是就向client发出确认报文段，同意建立连接。假设不采用“三次握手”，那么只要server发出确认，新的连接就建立了。由于现在client并没有发出建立连接的请求，因此不会理睬server的确认，也不会向server发送ACK包。这样就会白白浪费资源。

而经过三次握手，客户端和服务器都有应有答，这样可以确保TCP正确连接。