为什么FIN_WAIT2中的连接未被Linux内核关闭?

Modified on: Sat, 20 Apr 2019 12:40:02 +0800

我在一个名为kube-proxyKubernetes的一部分。

问题是连接有时会处于FIN_WAIT2状态。

$ sudo netstat -tpn | grep FIN_WAIT2
tcp6       0      0 10.244.0.1:33132        10.244.0.35:48936       FIN_WAIT2   14125/kube-proxy
tcp6       0      0 10.244.0.1:48340        10.244.0.35:56339       FIN_WAIT2   14125/kube-proxy
tcp6       0      0 10.244.0.1:52619        10.244.0.35:57859       FIN_WAIT2   14125/kube-proxy
tcp6       0      0 10.244.0.1:33132        10.244.0.50:36466       FIN_WAIT2   14125/kube-proxy

随着时间的推移,这些连接会叠加,从而导致流程出现异常。我已经向Kubernetes bug-tracker 报告了一个问题,但我想了解为什么会这样Linux内核没有关闭连接。

根据其文档(搜索tcp_fin_timeout)连接在FIN_WAIT2状态应该在X秒后由内核关闭,其中X可以从/ proc读取。在我的机器上,它设置为60:

$ cat /proc/sys/net/ipv4/tcp_fin_timeout
60

所以,如果我理解正确,这样的连接应该关闭60秒。但事实并非如此,他们在这种状态下待了好几个小时。

虽然我也明白FIN_WAIT2连接非常不寻常(这意味着主机正在等待连接远端的某些ACK可能已经消失)我不明白为什么这些连接没有“关闭”由系统。

我能做点什么吗?

请注意,重新启动相关流程是最后的选择。

作者:,Adam Romanek

最佳答案

内核超时仅在连接成为孤立时才适用。如果连接仍然连接到套接字,则拥有该套接字的程序负责超时关闭连接。可能它已经调用shutdown并等待连接干净地关闭。应用程序可以等待关闭完成所需的时间。

典型的干净关闭流程如下:

  1. 应用程序决定关闭连接并关闭连接的写入端。

  2. 应用程序等待另一方关闭其一半的连接。

  3. 应用程序检测到对方关闭连接并关闭其套接字。

  4. 醇>

    应用程序可以在第2步等待它。

    听起来应用程序需要超时。一旦它决定关闭连接,它应该放弃等待另一方在一段合理的时间后进行干净的关闭。


相关问答

添加新评论