三次握手四次挥手

三次握手

过程

• 一开始客户端和服务器都处于COLSE状态；
• 先是服务器监听某个端口，服务器处于Listen状态；
• 客户端向服务器发送SYN，请求建立连接，客户端处于SYN_SENT状态；
• 服务器收到后，返回ACK+SYN的响应，服务器处于SYN_RCVD状态；
• 客户端收到响应后发送ACK，客户端处于ESTALISHED状态；
• 服务器收到响应后，服务器处于ESTALISHED状态；
• 至此，客户端与服务器之间的双向连接就成功建立。可以互相传送数据，在第三次握手时，就可以传送数据了。

两次握手可不可以，四次握手可不可以

三次握手就已经能保证双方可靠的传输，没必要四次。
说说为什么不能两次握手：

• 防止历史连接的初始化。网络是一个非常复杂的环境，我们谁都无法预测，可能我们在本次建立连接发送SYN时网络就非常拥堵，导致我们之前发送的SYN比我们这此发送的先到达，然后服务器收到SYN后，就建立连接，返回ACK+SYN，我们收到后一看响应确认号不对，如果是三次握手，我们就可以返回RST重新建立连接，就可以防止历史连接的初始化。
• 帮助双方同步初始化序列化。序列号非常重要，服务器可以通过序列号去重，还可以通过序列号按序接收，客户端发送SYN，收到服务器的SYN+ACK，客户端就知道自己发送的数据被服务器收到了；然后客户端恢复ACK，服务器收到后也就知道自己发送的数据也被客户端收到了。
• 避免不必要的资源浪费。如果就只有两次握手，那服务器在收到客户端发送的SYN后，由于不能知道自己回复的SYN+ACK能不能被客户端收到，就只能在收到SYN后就建立连接，分配好资源。如果服务器返回的SYN+ACK丢失了，那超过一端时间客户端就会重新发送SYN，可能会发送好几个，而且每个SYN，服务器都会建立连接，造成不必要的资源浪费。

四次挥手

过程

• 客户端向服务器发送FIN，请求断开连接，客户端处于FIN_WAIT1状态；
• 服务器收到后，返回一个ACK，服务器处于COLSE_WAIT状态；
• 客户端收到后，处于FIN_WAIT2状态；
• 服务器返回一个FIN，服务器处于LAST_ACK状态；
• 客户端收到后，返回ACK，客户端处于TIME_WAIT状态；
• 服务器收到ACK后，处于CLOSE状态；
• 客户端距离上次发送的ACK的时间超过2*MSL也就处于CLOSE状态。

为什么要四次挥手

客户端发送FIN请求断开连接，此时客户端不再发送数据，但可以接收数据，服务器收到FIN后会立即回一个ACK表示服务器已经收到消息，但服务器此时可能还在发送数据，所以需要等数据发送完之后再回FIN。

为什么要等2*MSL的时间

• 最后一个ACK可能会发生丢包，如果丢包，服务器会重新发送FIN，这样ACK到服务器，FIN到客户端，一来一去就是两个MSL，确保服务器的连接正常关闭；
• 2*MSL足够让本次连接中的其它包都被丢弃，可能由于网络的原因，之前发送的数据报还没有到达，如果立马关闭，可能又有别的进程占了这个端口，然后这个端口建好连接后，上次的数据报才刚到达，那这不就乱了，所以等2*MSL，足够长让未到达的数据报都被丢弃。