什么是三次握手、四次挥手

什么是三次握手

在网络数据传输中，传输层协议TCP(传输控制协议)是建立连接的可靠传输，TCP建立连接的过程，我们称为三次握手。

第一次，客户端向服务器发送SYN同步报文段，请求建立连接

第二次，服务器确认收到客户端的连接请求，并向客户端发送SYN同步报文，表示要向客户端建立连接

第三次，客户端收到服务器端的确认请求后，处于建立连接状态，向服务器发送确认报文

客户端是在收到确认请求后，先建立连接

服务器是在收到最后客户端的确认后，建立连接

发起连接请求的一定是客户端

 

为什么建立连接时要进行三次握手？

我们可以分析一次握手肯定是不行的，这样服务器都不一定能收到连接请求

 

那么如果是两次握手呢?

如果是两次握手，连接过程应该是这样的，当服务器收到对端的连接请求时，就认为连接建立好了，进入ESTABLISHED状态。客户端在收到服务器发来的同步确认报文后，就认为连接建立好了，进入ESTABLISHED，在报文都能正常收到的情况下，两次握手是可以安全建立连接的。

但是存在这样的情况，假设第二次握手的报文丢失了，当前的状态是，服务器认为连接已经建立好了，可是客户端没有收到同步确认报文，认为连接还没有建立好，此时，服务器端的连接其实是无效连接，客户端因为没有收到确认，便会向服务器重传同步报文，同样，在服务器收到客户端的同步报文时，认为连接已经建立好了，同样糟糕的事情发生了，服务器给客户端发送的同步确认报文丢失了，或者是说有人恶意向服务器不断发送SYN同步报文（SYN洪水）。那么服务器端就会有大量的无效连接，服务器处理连接的数量是有限的，当有大量的无效连接建立后，服务器处理有效连接是能力就会受限，且建立连接会消耗大量是资源，至此有可能导致服务器崩溃。

这样看来两次握手是不可行的。

 

三次握手为什么是可行的呢？

在上面的两次握手的方案中，我们看到建立连接过程中，是服务器先处于连接建立好的状态，出现差错时，客户端没有连接建立成功，致使服务器可能有大量的无效连接，导致服务器安全问题。

那么在三次握手方案中，客户端收到服务器的同步确认报文后，就认为连接建立好了（先处于连接建立好的状态），而服务器是要收到客户端的确认报文后才认为连接建立好了。

那么也可能存在这样的问题，在最后一次握手时，服务器没有收到客户端的确认报文，此时的状态是，客户端处于建立连接状态，服务器处于没有建立连接状态，此时客户端负责维护这次连接

 

三次握手中，是谁先发起请求，谁来负责维护这次连接，那么会出现上面类似SYN洪水的问题吗？显然是不会的，自己发出SYN，最终无效连接还是建立在自己这方，客户端也不会这么无聊吧

而当客户端尝试向服务器发送数据时，服务器看到的是，还没有建立连接的数据，服务器会响应一个带有RST标志位的报文，告知客户端你需要先建立连接，此时当客户端收到这个报文时，就会重新发起建立连接的请求。

总结下来就是，三次握手中，即使建立连接失败，对服务器是没有影响的，保证服务器的安全，而对客户端而言，也不过是多次建立连接而已。并且在经过验证，三次握手的成功率也是非常高的。

 

四次握手可行吗？

很明显，三次握手已经可以满足我们的需求了，也就没必要多一次而浪费资源了。

在两次握手和三次握手的方案中，我们发现要保证客户端先建立连接的话，能保证连接的安全建立。若是偶数次握手，或者是说让服务器先建立连接，就是不安全不可行的方案。所以四次 握手是不可行的。

 

什么是四次挥手

在网络数据传输中，传输层协议断开连接的过程我们称为四次挥手

第一次，A端像B端发送FIN结束报文段，准备关闭连接

第二次，B端确认A端的FIN，表示自己已经收到对方关闭连接的请求

中间这段时间，A端停止向B端发送数据，但是B端可以向A端发送数据，要将自己未处理完任务处理完

第三次，B端向A端发送FIN结束报文段，准备关闭连接

第四次，A端确认B端的FIN，进入TIME_WAIT状态，此时A端进程已经退出，但是连接还在

当B端收到A端的ACK之后，先断开连接

当A端等待2 MSL之后，确认的B端接收到ACK后，再断开连接

发起断开连接请求的一端最后要进入有一个TIME_WAIT状态

发起连接请求的可以是客户端也可以是服务器端

 

为什么断开连接要四次?

不像建立连接的过程,服务器端在调用了accept()之后,剩下的都交给内核来处理,用户空间不用做什么,断开连接是,A端调用close()关闭文件描述符后,A端就停止发送数据了进行发送,B端收到后结束报文段之后,的得知A端要断开连接了,但是B端可能有自己还没有处理完的数据,不能立即断开连接,就要先给出回复,表示自己已经收到消息了,然后将自己的数据处理完之后,可以断开连接的时候,再调用close()发出断开连接请求,在收到A端的确认回复之后,断开连接,这样看来每一步都不能少,但是有时候若服务器端没有什么要处理的数据,就看可以直接调用close()捎带上响应报文,此时就是3次

为什么先发起断开连接请求的一端最后要等待 2MSL？

MSL为一段报文从一段到一段的最大时间，也称为报文的最大生存时间，我们假设在上面的四次挥手过程中最后A端在收到B端的FIN之后，就关闭连接，最后B端在收到A端的确认报文之后也断开连接，这种情况是我们预期的

试想是否存在这样的情况，在A端已经关闭连接后，但是发给B端的ACK报文中途丢失，此时B端就会重发FIN结束报文段，但是A端已经关闭与这台服务器的连接，并且已经开始了一段新的连接，那么A端收到这个过期的FIN，误认为是关闭当前连接，给出错误处理。

也就是说A端等待 2MSL就 可以保证在B端没有收到A 到ACK时，B端重发的FIN,A端来的及处理，然后重新确认等待2 MSL，保证了最后的ACK 报文 B端成功收到。