CLOSE_WAIT状态生成的原因.docxVIP

CLOSE_WAIT CLOSE_WAIT 状态生成的原因 关闭 socket 分为主动关闭( Active closure )和被动关 闭( Passive closure )两种情况。前者是指有本地主机主动 发起的关闭；而后者则是指本地主机检测到远程主机发起关 闭之后，作出回应，从而关闭整个连接。 其状态图如下图所示：起初每个 其状态图如下图所示： 起初每个 socket 都是 CLOSED 状态，当客户端初使化一个连接， 他发送一个 SYN 包到服务器，客户端进入 SYN_SENT 状态。 服务器接收到 SYN 包，反馈一个 SYN-ACK 包，客户端接 收后返馈一个 ACK 包客户端变成 ESTABLISHED 状态，如 果长时间没收到 SYN-ACK 包，客户端超时进入 CLOSED 状态。 当服务器绑定并监听某一端口时， socket 的状态是 LISTEN ，当客户企图建立连接时， 服务器收到一个 SYN 包， 并反馈 SYN-ACK 包。服务器状态变成 SYN_RCVD ，当客 户端发送一个 ACK 包时，服务器 socket 变成 状态时有两种图径关闭它， 第一是主动关闭，第二是被动 关闭。如果你要主动关闭的话，发送一个 FIN 包。当你的程 序 closesocket 或者 shutdown (标记)，你的程序发送一个 ESTABLISHED 状态。 ESTABLISHED 状态。 当一个程序在 ESTABLISHED FIN 包到 peer ，你的 socket 变成 FIN_WAIT_1 状态。 peer 反馈一个 ACK 包，你的 socket 进入 FIN_WAIT_2 状态。如 果 peer 也在关闭连接，那么它将发送一个 FIN 包到你的电 脑，你反馈一个 ACK 包，并转成 TIME_WAIT 状态。 TIME_WAIT 状态又号 2MSL 等待状态。 MSL 意思是最 大段生命周期( Maximum Segment Lifetime) 表明一个包存 在于网络上到被丢弃之间的时间。每个 IP 包有一个 TTL(time_to_live) ，当它减到 0 时则包被丢弃。每个路由器 使 TTL 减一并且传送该包。 当一个程序进入 TIME_WAIT 状 态时，他有2个 MSL的时间，这个充许 TCP重发最后的 ACK ，万一最后的 ACK 丢失了，使得 FIN 被重新传输。在 2MSL 等待状态完成后， socket 进入 CLOSED 状态。 被动关闭： 当程序收到一个 FIN 包从 peer ，并反馈一个 ACK 包，于是程序的 socket 转入 CLOSE_WAIT 状态。因 为 peer 已经关闭了，所以不能发任何消息了。但程序还可 以。要关闭连接，程序自已发送给自已 FIN ，使程序的 TCP socket 状态变成 LAST_ACK 状态，当程序从 peer 收到 ACK 包时，程序进入 CLOSED 状态。 ///////////////////////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////// ，可以查看是否有大root 权限执行 lsof -n httpd | grep TCP ，可以查看是否有大 量 CLOSE_WAIT 摘要：本文阐述了为何 socket 连接锁定在 CLOSE_WAIT 状 态，以及通过什么措施力求避免这种情况。 不久前，我的 Socket Client 程序遇到了一个非常尴尬的错误。 它本来应该在一个 socket 长连接上持续不断地向服务器发 送数据，如果 socket 连接断开， 那么程序会自动不断地重试 建立连接。 有一天发现程序在不断尝试建立连接，但是总是失败。用 netstat 查看，这个程序竟然有上千个 socket 连接处于 CLOSE_WAIT 状态，以至于达到了上限，所以无法建立新 的 socket 连接了。 为什么会这样呢？ 它们为什么会都处在 CLOSE_WAIT 状态呢？ CLOSE_WAIT 状态的生成原因 首先我们知道，如果我们的 Client 程序处于 CLOSE_WAIT 状态的话，说明套接字是被动关闭的！ 因为如果是 Server 端主动断掉当前连接的话， 那么双方关闭 这个 TCP 连接共需要四个 packet ： Server ---gt; FIN ---gt; Client Server lt;--- ACK lt;--- Client 这时候 Server 端处于 FIN_WA