TCP连接中 FIN_WAIT_2 状态下的异常关闭

在这里插入图片描述

  正常情况下,主动关闭连接的一端(客户端)在 FIN_WAIT_2 状态等待一段时间后,会收到对端(服务器)的FIN报文,从而进入TIME_WAIT状态等待连接的真正关闭。(服务器何时发送FIN取决于服务器应用程序的处理,一般会在read返回0发现客户端已经关闭连接后,也调用close关闭连接)

  然而有在某些异常情况下,可能处于 FIN_WAIT_2 状态的一端一直等不到对端的FIN。如果没有外力的作用,连接两端会一直分别处于 FIN_WAIT_2 和 CLOSE_WAIT 状态。这会造成系统资源的浪费,需要对其进行处理。(注意内核协议栈就有参数提供了对这种异常情况的处理,无需应用程序操作)

  目前的做法是:如果应用程序调用的是完全关闭(而不是半关闭),那么内核将会起一个定时器,设置最晚收到对端FIN报文的时间。如果定时器超时后仍未收到FIN,且此时TCP连接处于空闲状态,则TCP连接就会从 FIN_WAIT_2 状态直接转入 CLOSED 状态,关闭连接。

  在Linux系统中可以通过参数 net.ipv4.tcp_fin_timeout 设置定时器的超时时间,默认为 60 s。

FIN_WAIT1 是 TCP 连接的一种状态,它表示连接关闭的阶段之一。当一方发送了 FIN(终止连接)报文后,进入 FIN_WAIT1 状态,等待对方的确认。 在 FIN_WAIT1 状态下,发送方仍然可以接收对方发送的数据。它等待对方发送 ACK(确认)报文作为对 FIN 报文的确认。如果接收到对方的 ACK 报文,连接将进入 FIN_WAIT2 状态。如果在一定时间内没有收到对方的 ACK 报文,或者收到了对方的 RST(复位)报文,则连接会直接关闭FIN_WAIT1 状态通常是一个短暂的状态,在正常情况下不会停留太久。如果连接长时间停留在 FIN_WAIT1 状态,可能是由于以下原因之一: 1. 对方没有发送 ACK 报文:对方可能由于某种原因未正确处理并发送 ACK 报文,导致连接无法继续进入 FIN_WAIT2 状态。可以通过网络抓包或日志来确认是否有 ACK 报文被丢失或未发送。 2. 对方在接收到 FIN 报文后长时间未响应:如果对方在接收到 FIN 报文后长时间没有响应,可能是由于对方应用程序的问题,导致无法及时发送 ACK 报文。 请注意,如果应用程序频繁地打开和关闭连接,并且使用相同的本地 IP 地址和端口号,可能会导致连接在 TIME_WAIT 状态下保持较长时间,进而导致 FIN_WAIT1 状态的持续时间延长。在这种情况下,可以尝试使用不同的本地 IP 地址和端口号来避免连接复用。 如果长时间停留在 FIN_WAIT1 状态引起了问题,可以考虑调整操作系统的参数或检查应用程序的代码逻辑,以确保连接能够正常关闭
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值