运行lsof -i在CLOSE_WAIT中显示很多连接？我应该担心吗

因此，我lsof -i | wc -l定期运行，它告诉我有420条线路中有240至255条处于CLOSE_WAIT状态。TCP连接如何进入此状态？

我应该担心并且应该如何解决？

（我打算编辑mikegrb的答案，但认为我对此略有保留）

CLOSE_WAIT的含义几乎完全相同，即内核在删除条目之前正在等待本地进程关闭其文件描述符。TCP连接已被完全拆除，并且远端可能会给人以连接是finito的印象，但是您的一端正在坚持下去。

唯一需要担心的是，许多CLOSE_WAIT条目会消耗内核内存和文件描述符表条目，如果其中有大量的条目，则可能会成为问题。如果您要查看的条目是瞬态的，则可能只是您在循环很多次TCP连接数，在连接关闭到进程关闭文件描述符之间的短时间内，您会看到其中的一小部分。另一方面，如果它们是永久性的（端口和IP地址不会随时间变化），则说明描述符泄漏了某些内容，因此需要对其进行修复，以便在完成操作后始终将其关闭。正如mikegrb所说，较新的版本可能已经解决了该问题，因此可能有必要在相关邮件列表中检查问题或检查变更日志。

CLOSE_WAIT状态意味着另一端发送了FIN段以关闭连接。连接仍然建立。您可以将其视为半双工模式，允许该端刷新所有缓冲区，将最后数据位发送到该端，请求关闭连接，然后再从该端关闭连接。

如果您有许多连接留在CLOSE_WAIT中，则意味着负责进程的套接字一旦进入CLOSE_WAIT，就不会关闭该套接字。您可以使用tcpdump或其他网络流量捕获工具查看数据包。

还要看看负责的过程。出于好奇，负责任的流程是什么？它可能具有更新的固定版本，或者可能是时候提交错误报告了；）

如果您在较弱的网络中运行，则可以进行以下调整：

• via ulimits和via /proc（系统范围）的最大文件描述符数量
• 您可以通过以下方式缩短TCP等待时间 /proc

您可能没有关闭服务器上运行的应用程序中某处的资源（文件句柄，网络连接）。