TCP连接中10.10.12.217发[FIN,ACK]后10.12.10.1回[RST,ACK]原因排查

现象梳理 #

初始状态：10.12.10.1（持续发送端）每秒向10.10.12.217（接收端）发送数据，TCP连接稳定。
异常流程：10.10.12.217多次发起[FIN,ACK]报文，随后10.12.10.1回复[RST,ACK]终止连接。

一、10.10.12.217主动发FIN/ACK的核心原因 #

• 应用层主动触发关闭：接收端的业务进程可能因崩溃（OOM被系统查杀、代码未捕获异常）、配置变更（比如缩短了连接超时阈值）、业务逻辑误判（认为数据接收完成，主动调用close()/shutdown(SHUT_WR)），触发内核发送FIN包发起连接关闭。
• 内核层面的超时/资源限制：
  • TCP保活配置过严：如果接收端开启了TCP保活，但发送端的数据包因网络抖动丢包，接收端判定连接空闲超时，主动发FIN。
  • 资源耗尽：接收端套接字的接收缓冲区被填满且应用长期未读取，或主机文件句柄耗尽，内核强制关闭连接释放资源。
• 网络层异常触发：接收端收到的数据包存在大量乱序、校验错误，内核判定连接不可用，主动发起关闭。

二、10.12.10.1回复RST/ACK的原因 #

发送端此时仍在持续发送数据，TCP栈处于ESTABLISHED状态。收到FIN包后，发送端会进入CLOSE_WAIT状态，但如果应用进程继续调用send()写数据，内核会直接返回RST包——因为此时应用层仍期望继续传输，不接受被动关闭请求；或者发送端应用未正确处理连接关闭事件（比如忽略了ECONNRESET错误），强行写数据触发RST。

三、责任主机的判断逻辑 #

• 核心触发点在10.10.12.217：它是主动发起连接关闭的一方，优先排查其应用或系统层面的问题。如果是应用主动关闭/崩溃，责任在接收端的业务或运维；如果是内核超时/资源耗尽，需优化接收端的系统配置或资源分配。
• 发送端的RST是被动响应：除非发送端应用存在逻辑缺陷（比如忽略连接关闭信号，强行写数据），否则RST只是对接收端主动关闭的异常反馈，不是故障根源。

四、排查实操建议 #

针对10.10.12.217 #

• 查应用日志：确认进程是否有崩溃日志、主动关闭连接的业务记录，或EPIPE/ECONNABORTED等错误。
• 系统资源排查：
  • 用top/free检查内存使用率，确认是否出现OOM；
  • 用lsof -i :<目标端口>查看套接字状态，netstat -s统计TCP错误（比如缓冲区溢出、超时次数）；
• TCP配置检查：查看sysctl参数，重点确认net.ipv4.tcp_keepalive_time（保活超时）、net.ipv4.tcp_fin_timeout（FIN等待超时）、net.ipv4.tcp_window_scaling（窗口缩放）是否合理。

针对10.12.10.1 #

• 查应用发送日志：确认收到FIN后是否仍在调用send()，是否有ECONNRESET错误记录。
• 抓包验证：用tcpdump -i any host 10.12.10.1 and host 10.10.12.217 -w send_rst.pcap捕获完整流量，分析RST发送前的数据包交互细节。

通用排查 #

在两台主机同时抓包，对比时间线，确认FIN包发送前是否存在丢包、乱序，或接收端是否在发送FIN前出现系统/应用事件（比如进程重启）。

内容的提问来源于stack exchange，提问作者K. Standeven