TCP的四次挥手过程

TCP的四次挥手过程

客户端和服务端都可以主动释放连接

这里以客户端示例
情景一:服务端有数据存在(四次挥手)

  • 客户端发送FIN标识到服务端,告知服务端我要释放连接
  • 服务端收到FIN标识,知道了客户端想断开连接,于是马上检查是否还有数据发送给客户端,如果还有数据没有发送,就发送ACK标识告诉客户端:等一会,你还有数据在我这里
  • 待所有数据发送完毕后,服务端发送FIN标识给客户端,告诉客户端,现在已经没有数据了,我要关闭连接啦
  • 客户端收到服务端的FIN标识,知道服务端现在就要关闭连接了,于是就发送ACK标识,告知服务端:我知道啦,你关吧
  • 于是服务器关闭,客户端也关闭了

情景二:没有数据存在(三次挥手)

  • 客户端发送FIN标识到服务端,告知服务端我要释放连接
  • 服务端收到FIN标识,知道了客户端想断开连接,于是马上检查是否还有数据发送给客户端,发现客户端咋我这里已经没有数据了,就发送FIN,ACK标识告诉客户端:你没有数据在我这里,我要关闭连接啦
  • 客户端收到服务端的FIN标识,知道服务端现在就要关闭连接了,于是就发送ACK标识,告知服务端:我知道啦,你关吧
  • 于是服务器关闭,客户端也关闭了
    TCP的四次挥手过程_第1张图片

为什么要等待2MSL时间

假设当客户端发送最后一次ACK,就不接收任何消息,处于关闭状态,而此时如果服务端没有收到ACK,会怎么样?

服务端角度:给客户端发送消息,没有收到回复,触发重发机制。但是客户端已经把连接关闭了,我的连接怎么办?谁来救救我~~

假设客户端在关闭之前等待指定时间(图中是2MSL),如果在2MSL时间内收到来自服务端重传的报文段,就知道上次的ACK没有到达服务端,于是重新发送ACK,这样可以保证A和B都能正常关闭连接

TCP的四次挥手过程_第2张图片

你可能感兴趣的:(web网络安全,java基础,Java,tcp/ip,四次挥手)