什么是三次握手
在网络数据传输中,传输层协议TCP(传输控制协议)是建立连接的可靠传输,TCP建立连接的过程,我们称为三次握手。
第一次,客户端向服务器发送SYN同步报文段,请求建立连接
第二次,服务器确认收到客户端的连接请求,并向客户端发送SYN同步报文,表示要向客户端建立连接
第三次,客户端收到服务器端的确认请求后,处于建立连接状态,向服务器发送确认报文
客户端是在收到确认请求后,先建立连接
服务器是在收到最后客户端的确认后,建立连接
发起连接请求的一定是客户端
为什么建立连接时要进行三次握手?
我们可以分析一次握手肯定是不行的,这样服务器都不一定能收到连接请求
那么如果是两次握手呢?
如果是两次握手,连接过程应该是这样的,当服务器收到对端的连接请求时,就认为连接建立好了,进入ESTABLISHED状态。客户端在收到服务器发来的同步确认报文后,就认为连接建立好了,进入ESTABLISHED,在报文都能正常收到的情况下,两次握手是可以安全建立连接的。
但是存在这样的情况,假设第二次握手的报文丢失了,当前的状态是,服务器认为连接已经建立好了,可是客户端没有收到同步确认报文,认为连接还没有建立好,此时,服务器端的连接其实是无效连接,客户端因为没有收到确认,便会向服务器重传同步报文,同样,在服务器收到客户端的同步报文时,认为连接已经建立好了,同样糟糕的事情发生了,服务器给客户端发送的同步确认报文丢失了,或者是说有人恶意向服务器不断发送SYN同步报文(SYN洪水)。那么服务器端就会有大量的无效连接,服务器处理连接的数量是有限的,当有大量的无效连接建立后,服务器处理有效连接是能力就会受限,且建立连接会消耗大量是资源,至此有可能导致服务器崩溃。
这样看来两次握手是不可行的。
什么是四次挥手
在网络数据传输中,传输层协议断开连接的过程我们称为四次挥手
第一次,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端成功收到。