FIN_WAIT?TCP 连接响应问题

最新推荐文章于 2025-04-15 09:00:00 发布
最新推荐文章于 2025-04-15 09:00:00 发布
阅读量2.7k 收藏
点赞数
CC 4.0 BY-SA版权
分类专栏： CPP 文章标签： tcp windows 服务器 测试 网络
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/forestcell/article/details/2496937
本文探讨了C/S架构中TCP连接的管理问题，特别是针对一端非正常断开连接时另一端如何进行有效的处理。文章通过实际案例分享了如何使用recv函数来判断连接状态，并避免由此引发的ioctl错误。

最近解决一些TCP连接的问题，主要现象如下：

C/S，其中一端断开，另一端没有及时处理close，就会出现这个现象。还得会用netstat -anp tcp看这个。

原先的代码就一直这么用的。但是作为服务器，这样使用就有问题了。没有处理的连接，非正常关闭，会导致这个错误，多了windows就会提示ioctl，messagebox标题为一个IP的错误。开始不知道是这个原因。随着测试的深入，才发现这个问题。

找了半天，最后终于在合适的位置找到了个可以使用recv判断的地方。

学到一些东西，呵呵。做网络这么久，才深入研究这个，有点儿汗~~~

下面为一张TCP连接的状态转换图：

 

大量TIME_WAIT、CLOSE_WAIT状态TCP连接解决
悦分享
12-10 473
为了确保数据能够完成传输。关闭连接时，当收到对方的FIN报文通知时，它仅仅表示对方没有数据发送给你了；但未必你所有的数据都全部发送给对方了所以你可以未必会马上会关闭SOCKET,也即你可能还需要发送一些数据给对方之后，再发送FIN报文给对方来表示你同意现在可以关闭连接了，所以它这里的ACK报文和FIN报文多数情况下都是分开发送的。可能有人会有疑问，tcp我握手的时候为何ACK(确认)和SYN(建立连接)是一起发送。挥手的时候为什么是分开的时候发送呢.
TCP四次挥手和TIME_WAIT
啊浪的博客
10-06 1601
FIN_WAIT_1 : FIN_WAIT_1和FIN_WAIT_2状态的真正含义都是表示等待对方的FIN报文。而这两种状态的区别是： FIN_WAIT_1状态实际上是当SOCKET在ESTABLISHED状态时，它想主动关闭连接，向对方发送了FIN报文，此时该SOCKET即进入到FIN_WAIT_1状态。而当对方回应ACK报文后，则进入到FIN_WAIT_2状态，当然在实际的正常情...
TCP在FIN_WAIT1状态到底能持续多久以及TCP假连接问题
热门推荐
TCP/IP
08-16 4万+
近期遇到一个问题，简单点说，主机A上显示一条ESTABLISHED状态的TCP连接到主机B，而主机B上却没有任何关于主机A的连接信息，经查明，这是由于主机A和主机B的发送/接收缓冲区差异巨大，导致主机B进程退出后，主机A暂时憋住，主机B频繁发送零窗口探测，FIN_WAIT1状态超时，进而连接被销毁，然而主机A并不知情导致。 正好昨天也有人咨询另外一个类似的问题，那么就抽昨晚和今天早上的时间，写一...
linux tcp fin wait1,关于FIN_WAIT1
weixin_32104797的博客
05-15 1060
前些天，一堆人在 TCPCopy 社区里闲扯蛋，有人提了一个问题：FIN_WAIT1 能持续多久？引发了一场讨论，期间我得到斌哥和多位朋友的点化，受益良多。让我们热热身，通过一张旧图来回忆一下 TCP 关闭连接时的情况：TCP Close看图可知，主动关闭的一方发出 FIN，同时进入 FIN_WAIT1 状态，被动关闭的一方响应 ACK，从而使主动关闭的一方迁移至 FIN_WAIT2 状态，接着被...
TCP连接的状态详解以及故障排查
weixin_30245867的博客
08-20 2907
我们通过了解TCP各个状态，可以排除和定位网络或系统故障时大有帮助。（总结网络上的内容） 1、TCP状态 linux查看tcp的状态命令： 1）、netstat -nat 查看TCP各个状态的数量 2）、lsof -i:port 可以检测到打开套接字的状况 3)、 sar -n SOCK 查看tcp创建的连接数 4)、tcpdum...
linux tcp fin wait1,Linux tcp状态 FIN_WAIT1、TIME_WAIT、ESTABLISHED
weixin_39952182的博客
05-15 598
命令：netstat -n | awk ‘/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}’显示服务器各种状态及其数量1、time_wait状态过多。原因：最可能的原因是服务器keepalive没有开，导致每次请求都要建立新的tcp连接，请求完成以后关闭，增加了很多time_wait的状态。另，keepalive可能会增加一部分内存的开销，但是问题...
解决Linux服务器中TCP的FIN_WAIT2，CLOSE_WAIT状态连接过多的问题
HelloBiu的博客
12-29 7905
解决Linux服务器中TCP的FIN_WAIT2，CLOSE_WAIT状态连接过多的问题
TCP连接CLOSE_WAIT和TIME_WAIT状态学习总结
点点滴滴
04-08 4926
0、引言 生产环境中，运行一段时间后，发现经常出现残留着大量的TCP链接，如下图所示，这些残留的TCP链接占用着系统的资源，一旦数量过大的话，会导致系统资源耗尽，甚至崩溃，急需排查解决。 2、TCP/IP的连接和断开过程 2.1 三次握手建立连接 第一次握手：建立连接时，客户端A发送SYN包（SYN=j）到服务器B，并进入SYN_SEND状态，等待服务器B确认。 第二次握手：服务器B收到S...
CLOSE_WAIT网络连接无法释放问题解决
07-31
在客户端主动断开连接时，客户端会发送FIN包给服务器端，服务器端则会响应ACK包，并进入CLOSE_WAIT状态。但是，如果服务器端没有正确关闭连接，那么连接将保持CLOSE_WAIT状态，而客户端则会等待服务器端的响应。 ...
计算机网络第5版课后习题答案详细(谢希仁)
05-23
计算机网络第5版课后习题答案详细(谢希仁)，详细计算机网络第5版课后习题答案详细(谢希仁)
关于FIN_WAIT1
bytxl的专栏
06-18 2万+
前些天，一堆人在 TCPCopy 社区里闲扯蛋，有人提了一个问题：FIN_WAIT1 能持续多久？引发了一场讨论，期间我得到斌哥和多位朋友的点化，受益良多。 让我们热热身，通过一张旧图来回忆一下 TCP 关闭连接时的情况： TCP Close 看图可知，主动关闭的一方发出 FIN，同时进入 FIN_WAIT1 状态，被动关闭的一方响应 ACK，从而
关于FIN_WAIT1---TCP四次挥手的状态
$firecat利白的代码足迹$
01-26 3093
https://huoding.com/2014/11/06/383 前些天，一堆人在 TCPCopy 社区里闲扯蛋，有人提了一个问题：FIN_WAIT1 能持续多久？引发了一场讨论，期间我得到斌哥和多位朋友的点化，受益良多。 让我们热热身，通过一张旧图来回忆一下 TCP 关闭连接时的情况： TCP Close 看图可知，主动关闭的一
tcp shutdown, fin_wait1, fin_wait2, close_wait, last_ack, 谢特！
TCP/IP
10-31 2万+
状态很奇怪，人们很难接受一个连接在非 ESTABLISHED 状态下正常传输数据，这会引来一堆咨询，但根据 TCP 状态机，这又是合理的，client 单向关闭了发送，FIN 就过去了，server 回复了 FIN，进入 CLOSE_WAIT，client 收到回复进入 FIN_WAIT_2，而 server 在 CLOSE_WAIT 下发数据，client 在 FIN_WAIT_2 下是完全合理的。但如果应用程序希望如此呢？TCP 的 RFC793 并未规定状态超时时间，为完整闭环这是合理的。
linux出现大量 FIN_WAIT1
04-15 743
在Linux系统中，出现大量的FIN_WAIT1状态通常与TCP连接关闭过程中的问题有关。
【网络编程】TCP 连接的四种 WAIT 状态
_山月
09-12 2217
文章以【网络编程】TCP socket 单机通信实验 为基础。对 TCP 连接中的四种 WAIT 状态进行分析实验。
Windows上关于time_wait及fine_time_wait2连接较多的处理
末日黄昏的博客
10-16 2662
FiNE_TIME_2： HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters 创建一个DWORD的键，命名为：TCPFinWait2Delay，键入一个30--300的值 注意：如果 TCPFinWait2Delay 值不存在，必须创建它作为 REG_DWORD 的注册表值。此注册表值控制它被迫关闭 (s ...
TCP套接口的FIN_WAIT_2状态超时
redwingz的博客
03-14 4213
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协议实践过程中现象解释
zxgmlcj的博客
09-03 655
原文地址：https://blog.youkuaiyun.com/dog250/article/details/81697403 之前遇到过客户端A与服务端B连接建立成功后，因未知原因，导致客户端A已经不存在对应连接，而服务器B对应连接一直存在，永不释放，后来排查是因为客户端A对应的socket不存在，而没有通知服务器B，又因服务端B未设置keepalive，服务器B对应的socket永久存在，这就是 TCP 假连接 主机A显示ESTABLISHED状态的TCP连接到主机B，而主机B没有任何关于主机A的连接信息。由
tcp的状态FIN_WAIT_2 是什么意思
最新发布
07-24
<think>我们正在讨论TCP协议的状态。FIN_WAIT_2状态是TCP连接终止过程中的一个状态。 根据TCP协议，当一端（我们称为A）发送了FIN（表示要关闭连接）并收到另一端的ACK（确认）后，进入FIN_WAIT_1状态。 然后，当A收到另一端（B）发送的FIN时，它会发送ACK确认，并进入TIME_WAIT状态。但是，在FIN_WAIT_1状态中，如果A先收到B的ACK（对A的FIN的确认）而不是FIN，那么A就会进入FIN_WAIT_2状态。 在FIN_WAIT_2状态，A等待B发送FIN（表示B也关闭了连接）。一旦收到B的FIN，A就发送ACK，并进入TIME_WAIT状态。 因此，FIN_WAIT_2状态表示：主动关闭方（A）已经发送了FIN并且收到了被动关闭方（B）对此FIN的ACK，现在正在等待被动关闭方（B）发送FIN。 需要注意的是，被动关闭方（B）在收到FIN后，会发送ACK，然后继续发送自己的FIN（假设它也要关闭连接）。在B发送FIN之前，主动关闭方A将一直处于FIN_WAIT_2状态。 如果被动关闭方（B）不发送FIN（比如应用程序没有关闭连接），那么主动关闭方（A）将一直停留在FIN_WAIT_2状态，直到超时（超时时间由系统配置，通常为几分钟）。 在lwIP中，我们可以通过配置`TCP_FIN_WAIT_TIMEOUT`来设置超时时间（单位为TCP轮询周期，通常为250ms，所以默认值一般为240*250ms=60秒）。 另外，在FIN_WAIT_2状态下，连接是半关闭的：主动关闭方A已经不能发送数据，但还可以接收来自B的数据（直到B关闭连接）。 下面是一个简单的状态转换图（从主动关闭方的角度）： ESTABLISHED -> FIN_WAIT_1（发送FIN后） -> 收到ACK -> FIN_WAIT_2 -> 收到FIN -> 发送ACK -> TIME_WAIT（等待2MSL）-> CLOSED 如果被动关闭方在发送ACK后，没有发送FIN，那么主动关闭方将一直停留在FIN_WAIT_2直到超时，然后进入CLOSED状态。 在lwIP中，我们可以通过配置选项来调整超时时间，例如： #define TCP_FIN_WAIT_TIMEOUT 240 // 240 * 250ms = 60 seconds 另外，在lwIP中，如果处于FIN_WAIT_2状态的连接超时，tcp_slowtmr()函数会将其关闭。 现在，根据要求，在回答后提出3-5个相关问题。</think>### TCP状态 FIN_WAIT_2 详解 FIN_WAIT_2 是TCP连接终止过程中的一个中间状态，发生在**主动关闭方**的流程中。具体含义如下： #### 状态定义 - **位置**：主动关闭方（先发送FIN包的一端）的状态序列 - **触发条件**：当主动关闭方已发送FIN包并收到对方对FIN的ACK确认后进入 - **状态转换**： ``` ESTABLISHED → FIN_WAIT_1 → FIN_WAIT_2 → TIME_WAIT → CLOSED ``` #### 核心特征 1. **半关闭状态**： - 主动关闭方已停止发送数据 - 但仍能接收对方发送的数据 - 类似单向通信通道 2. **等待对象**： ```mermaid graph LR A[主动关闭方] -- FIN --> B((被动关闭方)) B -- ACK --> A A[FIN_WAIT_2] -- 等待 --> B[FIN包] ``` 3. **超时机制**： - 默认超时时间：Linux系统为60秒（可通过`sysctl net.ipv4.tcp_fin_timeout`修改） - 超时后自动转为CLOSED状态 #### 典型场景 ```c // 主动关闭方代码示例 close(socket_fd); // 发送FIN包 // 此时进入FIN_WAIT_1 // 收到对端ACK后 → FIN_WAIT_2 // 等待对端FIN包... ``` #### 问题排查要点 1. **长时间滞留原因**： - 被动关闭方未发送FIN（应用未调用close()） - 网络丢包导致FIN未到达 - 对端崩溃无法响应 2. **检测命令**： ```bash netstat -ant | grep FIN_WAIT2 ss -o state fin-wait-2 # Linux ``` 3. **lwIP特殊处理**： ```c // lwipopts.h 配置 #define TCP_FIN_WAIT_TIMEOUT 60000 // 超时时间(ms) ``` 在`tcp_slowtmr()`中实现超时检测： ```c case FIN_WAIT_2: if (++pcb->tmr > tcp_fin_wait_2_timeout) { tcp_pcb_remove(&tcp_active_pcbs, pcb); tcp_free(pcb); } ``` #### 与相关状态对比 | 状态 | 角色 | 等待对象 | 可接收数据 | |------|------|----------|------------| | FIN_WAIT_1 | 主动方 | FIN+ACK 或 ACK | 否 | | **FIN_WAIT_2** | 主动方 | FIN | 是 | | CLOSE_WAIT | 被动方 | 应用close() | 是 | | TIME_WAIT | 主动方 | 2MSL超时 | 否 |
评论 1
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值