Websocket 连接卡在 FIN_WAIT1 FIN_WAIT2 状态答案

【问题标题】：Websocket connection stuck in FIN_WAIT1 FIN_WAIT2 statesWebsocket 连接卡在 FIN_WAIT1 FIN_WAIT2 状态
【发布时间】：2014-11-24 08:53:40
【问题描述】：

我正在尝试拥有一个服务器，多个客户端需要使用该服务器打开一个 websocket 并发送数据。但看起来很多客户端无法建立连接..

在服务器机器上，当我执行lsof 或netstat -an 时，我看到除了处于ESTABLISHED 状态的连接外，许多连接都显示为FIN_WAIT1 和FIN_WAIT2 状态。截至目前，打开文件的 ulimit 为 1024。卡在这两种状态的连接会被计入打开文件列表吗？如果是这样的话，1024 的限制很快就会用完。

/proc/sys/net/ipv4/tcp_orphan_retries是0，相当于8好像 https://serverfault.com/questions/274212/what-does-tcp-orphan-retries-set-to-0-mean/408882#408882

我已经查阅了这个链接： https://serverfault.com/questions/7689/how-do-i-get-rid-of-sockets-in-fin-wait1-state

但我不太了解。我已经在网上阅读了这两种状态，并且我意识到它们是协议的一部分，但我希望连接不会陷入它们无用的状态。我能以某种方式做到这一点吗？我应该更改ulimit吗？但这只是意味着问题将发生在时间 x+y 而不是 x。

【问题讨论】：

标签： ubuntu tcp websocket connection ulimit

【解决方案1】：

每当您看到 Fin_Wait 状态或任何与此相关的等待状态时，我们通常将其称为 1/2 会话。 TCP 堆栈在请求和响应的顺序上遵循非常严格的协议。正是因为这些规则，它才知道如何以及何时以及如何通过发送重试来尝试恢复。在任何等待状态的实例中，堆栈都知道它正在等待某些东西。只有两件事可以满足此条件：1）某种适当的响应或 2）超时。

当然，最好的方法是得到正确的响应。应该做一些工作来找出为什么会有这么多等待。有时这是由于不稳定的交换、路由和/或其他网络相关活动。但是，这也可能是拒绝服务攻击的结果，因为他们不关心状态。应用层的必要资源可以被释放的唯一方法是应用程序重新获得控制权。 TCP 仅在 1) 工作流程正常或 2) 发生超时或其他异常情况时才给予控制。例如，FIN 和 RST 可以在任何时候乱序发送。他们都被认为胜过任何其他州。请记住，并非所有客户端或主机的行为方式都与我们讨论的不同 TCP 堆栈实现方式相同。

根据系统，可以配置一些、许多或很少的 TCP 堆栈参数。 Fin Waits 和 RST Waits 的超时值有可配置的参数。也许你可以调整这些来解决你的问题。

【讨论】：