为什么处于 FIN_WAIT2 状态的连接不被 Linux 内核关闭？

Question

我有一个叫长寿命过程中的问题KUBE-代理的存在部分Kubernetes。

问题是有时连接会处于 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，但它可能已经消失了）我不明白为什么这些连接没有被系统“关闭” .

有什么我可以做的吗？

请注意，重新启动相关进程是最后的手段。

Answer 1

内核超时仅适用于孤立的连接。如果连接仍然附加到套接字，则拥有该套接字的程序负责超时关闭连接。可能它已经调用shutdown并正在等待连接完全关闭。应用程序可以等待关闭完成。

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

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

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

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

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

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