linux-networking – 为什么FIN_WAIT2状态的连接没有被Linux内核关闭？

概述我在一个名为 kube-proxy的长期过程中遇到了一个问题,它是 Kubernetes的一部分. 问题是连接有时会处于FIN_WAIT2状态. $sudo netstat -tpn | grep FIN_WAIT2tcp6 0 0 10.244.0.1:33132 10.244.0.35:48936 FIN_WAIT2 14125/kube- 我在一个名为 kube-proxy的长期过程中遇到了一个问题,它是 Kubernetes的一部分.

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

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

这些连接随着时间的推移而堆积起来,使得该过程行为不端.我已经reported an issue到Kubernetes BUG-tracker但我想了解为什么这样的连接没有被linux内核关闭.

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

$cat /proc/sys/net/ipv4/tcp_fin_timeout60

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

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

我有什么可以做的吗？

请注意,重新启动相关过程是最后的手段.

解决方法 内核超时仅适用于连接是孤立的.如果连接仍然连接到套接字,则拥有该套接字的程序负责超时关闭连接.可能它已经调用了shutdown并且正在等待连接干净地关闭.应用程序可以等待关闭完成所需的时间.

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

>应用程序决定关闭连接并关闭连接的写入端.
>应用程序等待另一方关闭其连接的一半.
>应用程序检测到另一方关闭连接并关闭其套接字.

只要喜欢,应用程序就可以在步骤2等待.

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

总结

以上是内存溢出为你收集整理的linux-networking – 为什么FIN_WAIT2状态的连接没有被Linux内核关闭？全部内容，希望文章能够帮你解决linux-networking – 为什么FIN_WAIT2状态的连接没有被Linux内核关闭？所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。