[计算机网络] TCP连接——TCP四次挥手

Note:本文内容参考自《计算机网络 自顶向下方法 原书第六版》


前言:基于TCP的传输任务结束后,参与该条TCP的两个进程中的任何一个都能终止该连接,以释放资源,终止连接这个过程同样需要双方协商,意见达成一致后才能安全终止连接,此过程也被称作TCP四次挥手。


TCP连接的关闭——TCP四次挥手过程

举个例子说明这个过程:假设是客户端发起终止TCP连接的请求


第一步:客户进程向服务器进程发送一个特殊的TCP报文,这个报文段的首部中的标志位FIN比特被设置为1,同时客户端进入FIN_WAIT_1状态,此时客户TCP需要等待一个来自服务器的带有确认的TCP报文段


第二步:服务器收到客户端发送的TCP报文后,就向客户端回送一个确认(ACK)报文段


客户端收到服务器发回的确认报文段后,会进入到FIN_WAIT_2状态,处于该状态的客户端需要等待服务器的FIN比特被置为1的另一个TCP报文段。


第三步:服务器发送它自己的终止报文段,该报文段中的FIN比特被置为1


第四步:接收到服务器的终止报文段后,客户TCP对该报文段进行确认(ACK),同时客户端会进入TIME_WAIT状态。

若发现ACK丢失,TIME_WAIT状态会使得TCP客户重传最后的确认报文,在TIME_WAIT中消耗的时间与具体实现有关,典型的值包括30秒,1分钟或2分钟。等待时间结束后,TCP连接才正式关闭,客户端所有资源(端口等)将被释放。


图示


结合TCP三次握手(可参考我的另一篇文章TCP三次握手)回顾正常情况下(此处不讨论复杂的异常情况)

客户端TCP和服务器TCP经历的典型状态序列

  • 客户端



流程说明

  1. 客户端开始时处于CLOSED状态,当一个客户端程序发起一个新的TCP连接时,客户中的TCP会向服务端发送一个SYN报文段
  2. 随后客户端进入SYN_SENT状态,处于该状态的客户端会等待服务端的响应TCP报文,来自服务端的TCP报文包含一个ACK字段,并且SYN比特会被置为1
  3. 收到服务端的TCP报文后,客户端TCP会进入到ESTABLISHED状态,处在这个状态的客户端能发送和接收包含有效载荷数据的TCP报文了
  4. 当客户端进程决定要关闭TCP连接,它会向服务端发送一个包含FIN比特并且该比特被置为1的终止报文段,随后进入FIN_WAIT_1状态,处于这个状态的客户端会等待服务端的带有确认ACK的报文
  5. 接收到服务端的ACK报文后,客户端会进入到FIN_WAIT_2状态,处于这个状态的客户端会等待来自服务器的FIN比特被置为1的报文段
  6. 接收到服务端的终止报文段后,客户端会向服务端发送自己的确认ACK报文,并进入TIME_WAIT状态,在这个状态,如果发生ACK丢失,客户端会被要求重传最后的确认报文
  7. 经过等待后,连接才正式关闭,客户端重新回到CLOSED状态

  • 服务器

流程说明:

  1. 服务端的初始状态同样是CLOSED状态,当需要与指定客户端建立TCP连接时,服务端应用会先创建一个用于监听指定端口的Socket,并且进入LISTEN状态
  2. 处于该状态的服务端会一直监听指定端口直至收到客户端的SYN报文,收到这个报文后,服务端会回复给客户端一个确认ACK报文,该报文中SYN比特置1,并且进入到SYN_RCVD状态
  3. 处于该状态的服务端需要等待客户端的确认,当接收到客户端的ACK报文段之后,服务端随即进入ESTABLISHED状态,此时服务端和客户端都处于该状态
  4. 当客户端主动关闭TCP连接时,处于ESTABLISHED状态的服务端会接收到客户端的终止报文段,接收到该报文段之后服务端会向客户端回应确认ACK报文段并进入到CLOSE_WAIT状态
  5. 处于CLOSE_WAIT状态的服务端紧接着会向客户端发送一个FIN比特被置1的终止报文段,并且进入到LAST_ACK状态
  6. 处于LAST_ACK状态的服务端等待来自客户端的最终确认报文,接收到该报文后服务端重新回到CLOSED状态
博主设置当前文章不允许评论。

没有更多推荐了,返回首页