为什么kill进程后socket一直处于FIN_WAIT_1状态

本文介绍一个因为conntrack内核参数设置和iptables规则设置的原因导致TCP连接不能正常关闭(socket一直处于FIN_WAIT_1状态)的案例，并介绍conntrack相关代码在conntrack表项超时后对新报文的处理逻辑。

案例现象

问题的现象：

ECS上有一个进程，建立了到另一个服务器的socket连接。 kill掉进程，发现tcpdump抓不到FIN包发出，导致服务器端的连接没有正常关闭。

为什么有这种现象呢？

梳理

正常情况下kill进程后，用户态调用close()系统调用来发起TCP FIN给对端，所以这肯定是个异常现象。关键的信息是：

1. 用户态kill进程。
2. ECS网卡层面没有抓到FIN包。

从这个现象描述中可以推断问题出在位于用户空间和网卡驱动中间的内核态中。但是是系统调用问题，还是FIN已经构造后出的问题，还不确定。这时候比较简单有效的判断的方法是看socket的状态。socket处于TIME_WAIT_1状态，这个信息很有用，可以判断系统调用是正常的，因为按照TCP状态机，FIN发出来后socket会进入TIME_WAIT_1状态，在收到对端ACK后进入TIME_WAIT_2状态。关于socket的另一个信息是：这个socket长时间处于TIME_WAIT_1状态，这也反向证明了在网卡上没有抓到FIN包的陈述是合理。FIN包没出虚机网卡，对端收不到FIN，所以自然没有机会回ACK。

真凶

问题梳理到了这里，基本上可以进一步聚焦了，在没有大bug的情况下，需要重点看下iptables(netfilter), tc等机制对报文的影响。果然在ECS中有许多iptables规则。利用iptables -nvL可以打出每条rule匹配到的计数，或者利用写log的办法，示例如下：

# 记录下new state的报文的日志
iptables -A INPUT -p tcp -m state --state NEW -j LOG --log-prefix "[iptables] INPUT NEW: "

在这个案例中，通过计数和近一步的log，发现了是OUTPUT chain的最后一跳DROP规则被匹配上了，如下：

# iptables -A OUTPUT -m state --state INVALID -j DROP

问题的真凶在此时被找到了：iptables规则丢弃了kill进程后发出的FIN包，导致对端收不到，连接无法正常关闭。

到了这里，离最终的root cause还有两个疑问：

• 问题是否在全局必现？触发的条件是什么？
• 为什么FIN包被认为是INVALID状态？

何时触发

先来看第一个问题：问题是否在全局必现？触发的条件是什么？

对于ECS上与服务器建立TCP连接的进程，问题实际上不是每次必现的。建议用netcat来做测试，验证下是否是全局影响。通过测试，有如下发现：

1. 利用netcat做类似的操作，也能复现同样的问题，说明这个确实是全局影响，与特定进程或者连接无关。
2. 连接时间比较长时能复现，时间比较短时kill进程时能正常发FIN。

看下conntrack相关的内核参数设置，发现ECS环境的conntrack参数中有一个显著的调整：

net.netfilter.nf_conntrack_tcp_timeout_established = 120

这个值默认值是5天，阿里云官网文档推荐的调优值是1200秒，而现在这个ECS环境中的设置是120秒，是一个非常短的值。

看到这里，可以认定是经过nf_conntrack_tcp_timeout_established 120秒后，conntrack中的连接跟踪记录已经被删除，此时对这个连接发起主动的FIN，在netfilter中回被判定成INVALID状态。而客户