TCP的FIN_WAIT_2状态与关闭等待（CLOSE_WAIT）状态详解
字数 2246 2025-11-11 19:54:35

TCP的FIN_WAIT_2状态与关闭等待（CLOSE_WAIT）状态详解

我们来深入探讨TCP连接终止过程中两个关键但容易混淆的状态：FIN_WAIT_2和CLOSE_WAIT。理解它们对于诊断连接关闭问题和网络编程至关重要。

第一步：回顾TCP四次挥手的基本流程

要理解这两个状态，必须先清楚TCP是如何正常关闭一个连接的。这个过程被称为“四次挥手”。我们假设客户端主动发起关闭，服务器被动关闭。

  1. 主动关闭方（如客户端）发送FIN：客户端希望关闭连接，它会发送一个TCP报文，其中FIN标志位被置为1。发送完毕后，客户端的状态从ESTABLISHED变为FIN_WAIT_1。
  2. 被动关闭方（如服务器）确认ACK：服务器收到FIN报文后，会发送一个ACK（确认）报文作为回应。此时，服务器的状态从ESTABLISHED变为CLOSE_WAIT。
  3. 被动关闭方（如服务器）发送FIN：当服务器也准备好关闭连接时（例如，它已经发送完所有数据），它会发送自己的FIN报文。此时，服务器的状态从CLOSE_WAIT变为LAST_ACK。
  4. 主动关闭方（如客户端）确认ACK：客户端收到服务器的FIN报文后，会发送最终的ACK进行确认。然后客户端的状态从FIN_WAIT_2变为TIME_WAIT，等待一段时间后彻底关闭。服务器收到这个ACK后，状态从LAST_ACK变为CLOSED，连接关闭。

第二步：聚焦CLOSE_WAIT状态

  • 谁进入这个状态？ 被动关闭方（即收到第一个FIN报文的那一端）。
  • 什么时候进入？ 当被动关闭方对主动关闭方发来的FIN报文回复了ACK之后。
  • 这个状态意味着什么？ CLOSE_WAIT状态是一个“等待本地应用层关闭”的状态。它表示：“对方（主动关闭方）已经明确表示不会再发送任何数据了，但我这一端的应用程序可能还有数据要处理或发送。”
  • 在这个状态下做什么？
    1. 被动关闭方（服务器）的TCP协议栈已经知道对方要关闭了。
    2. 但是，服务器上的应用程序（如你的Web服务器程序）可能还没有调用close()系统调用来关闭它自己这一侧的连接。
    3. 因此，连接会停留在CLOSE_WAIT状态，直到应用程序完成工作并主动关闭套接字。一旦应用程序执行了关闭操作，系统才会发送FIN报文，状态随之变为LAST_ACK。
  • 常见问题与诊断：
    • 大量的CLOSE_WAIT连接是危险的信号。 这通常意味着你的应用程序有Bug，例如没有正确地在代码中关闭网络连接（即“连接泄漏”）。这些连接会一直占用系统资源（如文件描述符和内存），最终可能导致系统无法建立新的连接。
    • 使用命令如 netstat -an | grep CLOSE_WAIT 可以查看系统上处于CLOSE_WAIT状态的连接数量。

第三步：聚焦FIN_WAIT_2状态

  • 谁进入这个状态？ 主动关闭方（即首先发起关闭的那一端）。
  • 什么时候进入？ 当主动关闭方发送了FIN（进入FIN_WAIT_1）后，收到了对方对自己FIN的ACK确认，但还没有收到对方的FIN报文时。
  • 这个状态意味着什么？ FIN_WAIT_2状态是一个“等待对方关闭”的状态。它表示：“我这边已经关闭了（不再发送数据），并且对方也确认了我关闭的请求。现在，我正在等待对方完成它的工作并发送它的FIN报文过来。”
  • 在这个状态下做什么？
    1. 主动关闭方（客户端）已经完成了自己的数据发送，并得到了对方的确认。
    2. 现在它只能接收数据，不能再发送数据。它在耐心等待被动关闭方发送FIN报文。
    3. 一旦收到对方的FIN报文，客户端会发送最后一个ACK，然后立即进入TIME_WAIT状态。
  • 常见问题与诊断：
    • 连接卡在FIN_WAIT_2状态：如果被动关闭方（服务器）因为程序Bug或崩溃，一直不发送它的FIN报文（即一直停留在CLOSE_WAIT状态），那么主动关闭方就会一直停留在FIN_WAIT_2状态。
    • 为了防止这种“半开”连接永久占用资源，大多数操作系统实现了超时机制。例如，在Linux上，可以通过 sysctl net.ipv4.tcp_fin_timeout 查看和设置这个超时时间（默认通常是60秒）。超时后，连接会被系统强制关闭。

第四步：总结与对比

特征 CLOSE_WAIT状态 FIN_WAIT_2状态
所属方 被动关闭方（收到FIN的一方） 主动关闭方（首先发送FIN的一方）
前一个状态 ESTABLISHED FIN_WAIT_1
进入条件 发送了对对方FIN的ACK后 收到对方对自己FIN的ACK后
状态含义 等待本机应用程序关闭连接 等待对端TCP发送FIN报文
问题根源 应用层Bug（未调用close） 对端问题（对端卡在CLOSE_WAIT或崩溃）
解决方案 修复应用程序代码，确保关闭连接 检查对端应用状态；依赖系统超时机制回收

简单来说，CLOSE_WAIT是“等自己人”，FIN_WAIT_2是“等对方”。一个连接如果长时间存在，检查是卡在哪个状态，就能快速定位问题是出在本地应用还是远程端。

TCP的FIN_ WAIT_ 2状态与关闭等待（CLOSE_ WAIT）状态详解 我们来深入探讨TCP连接终止过程中两个关键但容易混淆的状态：FIN_ WAIT_ 2和CLOSE_ WAIT。理解它们对于诊断连接关闭问题和网络编程至关重要。 第一步：回顾TCP四次挥手的基本流程 要理解这两个状态，必须先清楚TCP是如何正常关闭一个连接的。这个过程被称为“四次挥手”。我们假设客户端主动发起关闭，服务器被动关闭。 主动关闭方（如客户端）发送FIN ：客户端希望关闭连接，它会发送一个TCP报文，其中FIN标志位被置为1。发送完毕后，客户端的状态从ESTABLISHED变为FIN_ WAIT_ 1。 被动关闭方（如服务器）确认ACK ：服务器收到FIN报文后，会发送一个ACK（确认）报文作为回应。此时，服务器的状态从ESTABLISHED变为CLOSE_ WAIT。 被动关闭方（如服务器）发送FIN ：当服务器也准备好关闭连接时（例如，它已经发送完所有数据），它会发送自己的FIN报文。此时，服务器的状态从CLOSE_ WAIT变为LAST_ ACK。 主动关闭方（如客户端）确认ACK ：客户端收到服务器的FIN报文后，会发送最终的ACK进行确认。然后客户端的状态从FIN_ WAIT_ 2变为TIME_ WAIT，等待一段时间后彻底关闭。服务器收到这个ACK后，状态从LAST_ ACK变为CLOSED，连接关闭。 第二步：聚焦CLOSE_ WAIT状态 谁进入这个状态？ 被动关闭方 （即收到第一个FIN报文的那一端）。 什么时候进入？ 当被动关闭方对主动关闭方发来的FIN报文回复了ACK之后。 这个状态意味着什么？ CLOSE_ WAIT状态是一个“等待本地应用层关闭”的状态。它表示：“对方（主动关闭方）已经明确表示不会再发送任何数据了，但我这一端的应用程序可能还有数据要处理或发送。” 在这个状态下做什么？ 被动关闭方（服务器）的TCP协议栈已经知道对方要关闭了。 但是，服务器上的应用程序（如你的Web服务器程序）可能还没有调用 close() 系统调用来关闭它自己这一侧的连接。 因此，连接会 停留 在CLOSE_ WAIT状态，直到应用程序完成工作并主动关闭套接字。一旦应用程序执行了关闭操作，系统才会发送FIN报文，状态随之变为LAST_ ACK。 常见问题与诊断： 大量的CLOSE_ WAIT连接是危险的信号。 这通常意味着你的应用程序有Bug，例如没有正确地在代码中关闭网络连接（即“连接泄漏”）。这些连接会一直占用系统资源（如文件描述符和内存），最终可能导致系统无法建立新的连接。 使用命令如 netstat -an | grep CLOSE_WAIT 可以查看系统上处于CLOSE_ WAIT状态的连接数量。 第三步：聚焦FIN_ WAIT_ 2状态 谁进入这个状态？ 主动关闭方 （即首先发起关闭的那一端）。 什么时候进入？ 当主动关闭方发送了FIN（进入FIN_ WAIT_ 1）后， 收到了对方对自己FIN的ACK确认 ，但还没有收到对方的FIN报文时。 这个状态意味着什么？ FIN_ WAIT_ 2状态是一个“等待对方关闭”的状态。它表示：“我这边已经关闭了（不再发送数据），并且对方也确认了我关闭的请求。现在，我正在等待对方完成它的工作并发送它的FIN报文过来。” 在这个状态下做什么？ 主动关闭方（客户端）已经完成了自己的数据发送，并得到了对方的确认。 现在它只能 接收数据 ，不能再发送数据。它在耐心等待被动关闭方发送FIN报文。 一旦收到对方的FIN报文，客户端会发送最后一个ACK，然后立即进入TIME_ WAIT状态。 常见问题与诊断： 连接卡在FIN_ WAIT_ 2状态 ：如果被动关闭方（服务器）因为程序Bug或崩溃，一直不发送它的FIN报文（即一直停留在CLOSE_ WAIT状态），那么主动关闭方就会一直停留在FIN_ WAIT_ 2状态。 为了防止这种“半开”连接永久占用资源，大多数操作系统实现了 超时机制 。例如，在Linux上，可以通过 sysctl net.ipv4.tcp_fin_timeout 查看和设置这个超时时间（默认通常是60秒）。超时后，连接会被系统强制关闭。 第四步：总结与对比 | 特征 | CLOSE_ WAIT状态 | FIN_ WAIT_ 2状态 | | :--- | :--- | :--- | | 所属方 | 被动关闭方（收到FIN的一方） | 主动关闭方（首先发送FIN的一方） | | 前一个状态 | ESTABLISHED | FIN_ WAIT_ 1 | | 进入条件 | 发送了对对方FIN的ACK后 | 收到对方对自己FIN的ACK后 | | 状态含义 | 等待 本机应用程序 关闭连接 | 等待 对端TCP 发送FIN报文 | | 问题根源 | 应用层Bug （未调用close） | 对端问题 （对端卡在CLOSE_ WAIT或崩溃） | | 解决方案 | 修复应用程序代码，确保关闭连接 | 检查对端应用状态；依赖系统超时机制回收 | 简单来说， CLOSE_ WAIT是“等自己人”，FIN_ WAIT_ 2是“等对方” 。一个连接如果长时间存在，检查是卡在哪个状态，就能快速定位问题是出在本地应用还是远程端。