关于服务端的FIN_WAIT2

原创 于 2022-01-06 14:56:14 发布 · 1.9k 阅读 · 2 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#服务器 #网络 #tcp/ip

本文探讨了如何通过SO_LINGER选项控制TCP连接关闭流程，特别提到使用OVERLAPPED结构影响残留连接的行为。通过设置SO_LINGER改变closesocket后的RST行为，并介绍了非标准方法如ReadFile配合OVERLAPPED在异常情况下的处理。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

服务端开启了TCP服务，客户端连接，正常的情况下当服务端closesocket后向客户端发送FIN，客户端回应ACK，此时服务端进入FIN_WAIT2状态，等待客户端发送FIN然后进入CLOSED。

这时，客户端还可以send一次数据，send完后，服务端收到后就会向客户端发送RST并进入CLOSED

若客户端始终不发送数据，并且也不Close，那么服务端的FIN_WAIT2会持续要一个默认超时（一般是60s），这个种残留链接太多的时候可能会消耗服务端资源，降低性能，甚至无法正常工作。

我们可以使用SO_LINGER来改变关闭连接的行为

struct linger  lg;
lg.l_onoff = 1;
lg.l_linger = 0;
setsockopt(sk, SOL_SOCKET, SO_LINGER, (char*)&lg, sizeof(lg));      

l_onoffl_lingerclosesocket行为发送队列底层行为
l零忽略立即返回。保持直至发送完成。系统接管套接字并保证将数据发送至对端。
非零零立即返回。立即放弃。直接发送RST包，自身立即复位，不用经过2MSL状态。对端收到复位错误号。
非零非零阻塞直到l_linger时间超时或数据发送完成。(套接字必须设置为阻塞zhuan)在超时时间段内保持尝试发送，若超时则立即放弃。超时则同第二种情况，若发送完成则皆大欢喜。

另外，除了SO_LINGER的方式，还有一种知其然不知其所以然的方法，这是在调试一个服务程序时发现的，没搞清楚其内部原由：

使用ReadFile对Socket发起一次读取，其中使用到OVERLAPPED数据结构，这里非常关键

OVERLAPPED ov;

ov.hEvent = 0;                //必须置零

ov.OffsetHigh=0;           //必须置零

DWORD nRead = 0;

char chBuf[100];

BOOL blRet = ReadFile(sk, chBuf, 10,(LPDWORD)(&nRead), &ov);//肯定读不到数据

closesocket(sk); //此时关闭socket，可以直接发送RST，而不经过四次握手

7、FIN-WAIT-2
zhaoyangjian724的专栏
03-27 415
7、FIN-WAIT-2 处于 FIN-WAIT-1状态的连接收到 ACK 确认包以后进入FIN-WAIT-2状态，这个时候主动关闭方的 FIN 包已经被对方确认，等待被动关闭方发送 FIN 包。 客户端超时关闭,服务端在正在处理,没法关闭,客户端处于FIN-WAIT-2 客户端: node2:/root#netstat -an | grep 8080 tcp 0 ...
fin_wait2 ， close_wait
zhaoyangjian724的专栏
11-19 185
服务端: node1:/root/test#cat t200.py # coding = utf-8 # -*- coding:utf-8 -*- import socket import time import datetime ip_port = ('192.168.137.2',8080) BUFSIZE = 9000 SEND_BUF_SIZE = 200 RECV_BUF_SIZE = 100 s=socket.socket(socket.AF_INET,socket.SOCK_STREAM..
FIN_WAIT_2
10-09 291
来自转载：http://blog.sina.com.cn/s/blog_8e5d24890102w9yi.html 上图对排除和定位网络或系统故障时大有帮助，但是怎样牢牢地将这张图刻在脑中呢？那么你就一定要对这张图的每一个状态，及转换的过程有深刻地认识，不能只 停留在一知半解之中。下面对这张图的11种状态详细解释一下，以便加强记忆！不过在这之前，先回顾一下TCP建立连接...
Socket连接出现大量的FIN_WAIT_2状态
热门推荐
xiaofei0859的专栏
12-02 4万+
<br />笔者完成的Socket Server端控件，经常在使用几个月后出现大量的FIN_WAIT_2状态的端口不能释放，造成服务器不能在有端口资源供给客户端建立新的连接，这一现象只出现在对方是UNIX的用户（移动的BOSS系统），笔者自己开发的Socket客户端控件从来没有出现过这个现象。<br />经过研究Socket的状态图<br />得出结论是Server端强制断开Socket时向客户端发送了FIN请求，客户端已经没有能力继续回复ACK，造成了服务器端大量的端口处在FIN_WAIT_2状态，不能释
关于FIN_WAIT2
Micheal
01-15 1106
FIN_WAIT2问题 让我们热热身，通过一张旧图来回忆一下 TCP 关闭连接时的情况： TCP Close 按照正常的状态迁移路径，当 FIN_WAIT2 收到 FIN 包后会迁移到 TIME_WAIT 状态。如果没有收到 FIN 包，那么连接状态会如何迁移，我们不妨测试一下： #!/usr/bin/env python import socket import time s ...
13-TCP 协议（FIN_WAIT2）
进击的小学生
04-08 2613
1. FIN_WAIT_2 状态如果你完成了上一篇文章的实验，你肯定见过了 FIN_WAIT2 状态。当主动关闭一方进入 FIN_WAIT2 状态时，只要对端还没有发送 FIN 段过来（处于 CLOSE_WAIT 状态，等等再关闭，我还有数据要发送），就会一直停留在这个状态。因此，FIN_WAIT2 状态会非常容易见到。 图1 处于 FIN_WAIT2 状态 很不幸，主动关闭一方有可能永远处
TCP状态迁移，CLOSE_WAIT & FIN_WAIT2 的问题解决
02-18
"TCP 状态迁移，CLOSE_WAIT & FIN_WAIT2 的问题解决" TCP 状态迁移是 TCP 协议中的一种机制，它用于描述 TCP 连接的不同状态。在 TCP 连接中，客户端和服务器端都可以处于不同的状态，例如 ESTABLISHED、CLOSE_WAIT...
网络的FIN_WAIT_2状态解释和分析
weixin_34072857的博客
01-07 9059
网络的FIN_WAIT_2状态解释和分析 一、总结 一句话总结：出现fin_wait_2一般为客户端，如果为服务端出现，则表明是服务端主动发起的断开 还是要系统的学，这样很有问题，学不到什么，系统看书看视频才行 主动 断开 系统 看书 视频     1、FIN_WAIT_2状态出现的原因是什么？ server 关闭连接 server FIN_WAIT_2 SERVER由于某种原...
为什么kill进程后socket一直处于FIN_WAIT_1状态
阿里云云栖号
06-05 1588
本文介绍一个因为conntrack内核参数设置和iptables规则设置的原因导致TCP连接不能正常关闭(socket一直处于FIN_WAIT_1状态)的案例，并介绍conntrack相关代码在conntrack表项超时后对新报文的处理逻辑。 案例现象 问题的现象： ECS上有一个进程，建立了到另一个服务器的socket连接。 kill掉进程，发现tcpdump抓不到FIN包发出，导致服务...
服务端time_wait多问题解决方案汇总
sskywatcher的博客
08-03 1154
问题描述 TCP会话中,首先发起关闭连接(调用 close() 系统调用)的一方在收到对端的 ACK\FIN+ACK 之后会进入到 TIME_WAIT 状态.服务器进入该该状态后,对于从相同的对端 ip 和端口的 tcp 发过来的数据包进行丢弃(Drop)处理.在 linux 系统中,该状态正常会持续1分钟的时间,该事件是硬编码的,不可以调整. 问题一: 此时如果有大量的并发客户端通过一个 SNAT 设备向服务器发起连接,由于客户端的 IP 经过 SNAT 设备,其源 ...
FIN_WAIT_2状态解释
花飘万家雪
11-03 8749
在HTTP应用中，存在一个问题，SERVER由于某种原因关闭连接，如KEEPALIVE的超时，这样，作为主动关闭的SERVER一方就会进入 FIN_WAIT2状态，但TCP/IP协议栈有个问题，FIN_WAIT2状态是没有超时的（不象TIME_WAIT状态），所以如果CLIENT不关闭，这个FIN_WAIT_2状态将保持到系统重新启动，越来越多的FIN_WAIT_2状态会致使内核crash。 　　产生原因： 1。常连接并且当连接一直处于IDLE状态导致SERVER CLOSE时，CLIENT编程缺陷，...
转 FIN_WAIT_2 tcp状态多原因剖析和解决
fei33423的专栏
03-14 2万+
a.客户端状态迁移 CLOSED->SYN_SENT->ESTABLISHED （ps：主动结束连接）->FIN_WAIT_1->FIN_WAIT_2 （如果另一方程序健壮，会发送fin过来 ）->TIME_WAIT->CLOSED b. 服务器状态迁移CLOSED->LISTEN->SYN收到 ->ESTABLISHED->CLOSE_WAIT（如果本程序健壮，会发送fin给另一方 ）->
网络分析流量FIN_WAIT_2状态解释
企业实战系列集 ●●● https://ximenjianxue.blog.youkuaiyun.com
06-09 1万+
在HTTP应用中，存在一个问题，SERVER由于某种原因关闭连接，如KEEPALIVE的超时，这样，作为主动关闭的SERVER一方就会进入 FIN_WAIT2状态，但TCP/IP协议栈有个问题，FIN_WAIT2状态是没有超时的（不象TIME_WAIT状态），所以如果CLIENT不关闭，这个FIN_WAIT_2状态将保持到系统重新启动，越来越多的FIN_WAIT_2状态会致使内核crash。 出现fin_wait_2一般为客户端，如果为服务端出现，则表明是服务端主动发起的断开。 可能产生原因： 1。常连.
TCP套接口的FIN_WAIT_2状态超时
redwingz的博客
03-14 4142
PROC文件tcp_fin_timeout默认为60秒，内核中相应的变量为init_net.ipv4.sysctl_tcp_fin_timeout，不过其以jiffies表示，默认值为TCP_FIN_TIMEOUT，即（60 * HZ）。此值表示一个不再被应用层使用（执行了close调用）的TCP连接处于FIN_WAIT_2状态的时长，如果在此时间内未能接收到对端的FIN结束报文，内核将复位此连接...
TCP连接中 FIN_WAIT_2 状态下的异常关闭
ArtAndLife的博客
03-17 1699
  正常情况下，主动关闭连接的一端（客户端）在 FIN_WAIT_2 状态等待一段时间后，会收到对端（服务器）的FIN报文，从而进入TIME_WAIT状态等待连接的真正关闭。（服务器何时发送FIN取决于服务器应用程序的处理，一般会在read返回0发现客户端已经关闭连接后，也调用close关闭连接）   然而有在某些异常情况下，可能处于 FIN_WAIT_2 状态的一端一直等不到对端的FIN。如果没有外力的作用，连接两端会一直分别处于 FIN_WAIT_2 和 CLOSE_WAIT 状态。这会造成系统资源..
FIN_WAIT_2状态下的连接与Apache
冰峰 的专栏
12-04 1368
摘自Apache官方文档：http://www.souzz.net/online/ApacheManual/misc/fin_wait_2.html警告：此文档没有考虑到Apache HTTP服务器 2.0 版本中的变化并为之作完全更新。 其中某些信息可能仍然有效，但使用时请小心。从Apache 1.2 beta测试版开始，人们就一直在报告说是处于
TCP FIN_WAIT_2探究(2)
向往
05-17 348
我们知道，在TCP_WAIT_2阶段，如果收到fin 置位，ack num 为snd_nxt,seq num为rcv_next的数据长度为零的tcp报文，则进入time-wait阶段，但是如果TCP_WAIT_2阶段收到一个非上述条件的报文，应该怎么处理呢，这个问题在rfc793和rfc1121以及rfc5961中都有答案，但是rfc793和rfc1121和rfc5961在某些点上存在冲突，另外，linux是采用哪种标准执行呢，这些问题我们依次分情况说明。 一个tcp 报文，主要元素如下，seq_num、a
9.9 FIN_WAIT2定时器
Remy的学习记录
04-10 1526
9.9.1 Why         如果应用进程调用close系统调用关闭socket，但此时socket与对端的通信尚未完成，则这个socket被称为“孤儿socket”。如果孤儿socekt进入FIN_WAIT2状态（或socket进入FIN_WAIT2状态后再成为孤儿socket），会等待对端发送FIN以彻底结束连接。但如果对端一直不发送FIN则这个孤儿socekt会一直存在，从而一直占用
上述问题，tcp连接断开是服务端一直卡在fin_wait1阶段无法退出
最新发布
03-10
<think>好的，用户现在的问题是关于之前的TCP连接断开问题，但这次是服务端卡在FIN_WAIT1状态无法退出。需要详细分析原因和解决方案。 首先，我得回忆一下TCP关闭连接的过程。正常情况是四次挥手：主动关闭方发送FIN，进入FIN_WAIT1，然后收到对方的ACK后进入FIN_WAIT2，再收到对方的FIN后发送ACK，进入TIME_WAIT。如果服务端卡在FIN_WAIT1，说明它发送了FIN但没有收到对方的ACK，或者对方没有发送FIN。 接下来，用户提到是服务端卡在这个状态，所以可能服务端是主动关闭连接的一方。比如，服务端先调用了close()。这时候，服务端发送FIN，等待ACK，但一直没收到，导致停留在FIN_WAIT1。 可能的原因有几个： 1. 对方没有回复ACK：可能客户端崩溃、网络问题或者客户端没有正确处理关闭流程，导致ACK丢失或未发送。 2. 对方的ACK丢失：服务端发送FIN后，客户端回了ACK，但ACK在网络中丢失，服务端没收到，一直等待。 3. 客户端没有发送FIN：如果是服务端主动关闭，客户端在收到FIN后应该发送ACK，然后客户端进入CLOSE_WAIT状态，并继续处理数据，最后发送自己的FIN。如果客户端没有发送FIN，服务端可能一直等待，不过正常情况下，服务端在收到ACK后会进入FIN_WAIT2，而不是一直卡在FIN_WAIT1，所以可能问题出在ACK未到达。 需要再仔细分析状态转换。FIN_WAIT1的状态会持续直到收到ACK，如果没收到，会超时重传FIN。根据系统配置，重试次数和超时时间可能不同，但最终会关闭连接。如果服务端一直卡住，可能是对方一直没响应，或者系统配置问题导致重试次数过多，或者资源泄漏。 解决方案方面： - 检查客户端是否正常响应ACK。可能需要客户端正确处理关闭，确保发送ACK。 - 设置SO_LINGER选项，调整关闭行为，避免长时间等待。 - 调整内核参数，比如缩短FIN超时时间，或者增加重试次数。 - 确保服务端正确处理异常情况，比如强制关闭socket，释放资源。 - 网络问题排查，确保ACK能够到达服务端。 另外，用户可能遇到的情况是，当Wi-Fi断开时，客户端突然下线，导致无法发送ACK，服务端卡在FIN_WAIT1。此时可能需要应用层的心跳机制，或者设置超时，及时释放资源。 需要给出具体的解决步骤，比如代码示例如何设置SO_LINGER，调整内核参数的方法，以及如何处理客户端异常断开的情况。同时，用户可能需要工具来监控TCP状态，比如使用netstat或者adb命令查看连接状态，帮助诊断问题。</think>当服务端在关闭TCP连接时卡在`FIN_WAIT1`状态无法退出，通常是由于TCP连接的**被动关闭方未正确响应ACK**或**网络异常导致ACK丢失**。以下是详细分析和解决方案： --- ### 一、`FIN_WAIT1`状态机制 1. **TCP四次挥手流程** - 主动关闭方（服务端）发送`FIN`报文，进入`FIN_WAIT1`状态； - 被动关闭方（客户端）收到`FIN`后，回复`ACK`，服务端进入`FIN_WAIT2`； - 客户端发送自己的`FIN`，服务端回复`ACK`后进入`TIME_WAIT`，最终关闭连接。 2. **卡在`FIN_WAIT1`的原因** - **客户端未回复`ACK`**：客户端崩溃、未正确处理关闭逻辑，或网络丢包导致`ACK`未送达； - **客户端未发送`FIN`**：客户端未完全关闭连接（如未调用`close()`）； - **服务端配置问题**：系统内核参数限制（如`tcp_fin_timeout`过短）。 --- ### 二、问题排查步骤 #### 1. 确认网络连通性 - 使用`ping`或`tcpdump`检查客户端与服务端之间的网络是否通畅； - 通过`adb shell netstat -anp | grep <端口>`（Android）或`netstat -ano`（PC）查看连接状态。 #### 2. 检查客户端行为 - 客户端是否正常调用`close()`释放Socket； - 客户端是否因线程阻塞、异常未处理导致未响应`ACK`。 #### 3. 分析服务端代码 - 服务端关闭Socket时是否调用了`shutdownOutput()`和`close()`； - 是否存在未关闭的输入/输出流导致资源泄漏。 --- ### 三、解决方案 #### 1. 客户端强制确认`ACK` 确保客户端收到`FIN`后立即回复`ACK`： ```java // 客户端代码示例 try { socket.shutdownInput(); // 关闭输入流，触发ACK socket.close(); } catch (IOException e) { e.printStackTrace(); } ``` #### 2. 服务端设置`SO_LINGER`选项 通过`SO_LINGER`强制缩短关闭等待时间： ```java // 服务端代码示例（Java） Socket socket = serverSocket.accept(); socket.setSoLinger(true, 0); // 第二个参数为超时时间（秒），0表示直接丢弃未发送数据 ``` #### 3. 调整系统内核参数（需Root权限） 修改`tcp_fin_timeout`缩短`FIN_WAIT1`超时（默认值因系统而异）： ```bash # Android通过adb修改（临时生效） adb shell "echo 10 > /proc/sys/net/ipv4/tcp_fin_timeout" ``` #### 4. 服务端容错处理 添加超时机制，避免无限等待`ACK`： ```java // 服务端Socket设置超时 socket.setSoTimeout(5000); // 5秒超时 try { // 读取数据或等待ACK } catch (SocketTimeoutException e) { socket.close(); // 超时后强制关闭 } ``` #### 5. 心跳保活机制 通过应用层心跳检测，及时清理僵死连接： ```java // 服务端定期发送心跳包 while (true) { try { socket.getOutputStream().write("HEARTBEAT\n".getBytes()); Thread.sleep(30000); // 每30秒一次 } catch (Exception e) { socket.close(); // 异常时主动关闭 break; } } ``` --- ### 四、进阶优化 1. **使用连接池** 复用长连接，避免频繁创建/销毁Socket（如OkHttp连接池）。 2. **监控TCP状态** 通过`ss -t4 state <状态名>`（Linux）或第三方库（如Netty的`ChannelTracker`）实时监控连接状态。 3. **防御性代码设计** - 在`finally`块中确保关闭Socket； - 使用`try-with-resources`（Java 7+）自动释放资源： ```java try (Socket socket = serverSocket.accept(); InputStream is = socket.getInputStream()) { // 业务逻辑 } catch (IOException e) { e.printStackTrace(); } ``` --- ### 五、验证方法 1. **抓包分析** 使用Wireshark或`tcpdump`验证`FIN`和`ACK`的交互流程： ```bash adb shell tcpdump -i wlan0 -s0 -v 'port <端口>' ``` 2. **日志追踪** 在服务端和客户端添加关键日志： ```java Log.d("SocketClose", "FIN sent, entering FIN_WAIT1"); Log.d("SocketClose", "ACK received, entering FIN_WAIT2"); ``` 3. **压力测试** 模拟网络抖动、客户端崩溃等场景，验证服务端是否能正常回收资源。 --- 通过以上方法，可有效解决服务端因`FIN_WAIT1`状态卡顿导致的端口占用问题，同时提升TCP连接的健壮性。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值