10.TCP协议-FIN_WAIT2

最新推荐文章于 2022-01-06 14:56:14 发布
最新推荐文章于 2022-01-06 14:56:14 发布
阅读量860 收藏
点赞数
CC 4.0 BY-SA版权
分类专栏： 计算机网络 计算机网络
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/Regemc/article/details/80686048
本文详细解释了TCP连接中FIN_WAIT2状态的意义及其可能产生的问题。重点介绍了主动关闭方在FIN_WAIT2状态下的行为，以及当对端长时间不响应时可能出现的情况。

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

1. FIN_WAIT2 状态

如果你完成了上一篇文章的实验，你肯定见过了 FIN_WAIT2 状态。

当主动关闭一方进入 FIN_WAIT2 状态时，只要对端还没有发送 FIN 段过来（处于 CLOSE_WAIT 状态，等等再关闭，我还有数据要发送），就会一直停留在这个状态。因此，FIN_WAIT2 状态会非常容易见到。

这里写图片描述 
图1 处于 FIN_WAIT2 状态 

很不幸，主动关闭一方有可能永远处于 FIN_WAIT2 状态，只要对方不发送 FIN 段的话（比如对端在 CLOSE_WAIT 状态时突然断电、网线掉了）。

在有些系统实现中，为了防止这种无限 FIN_WAIT2，设置了一个定时器。如果这个连接空闲 10 分钟 75 秒，TCP 将进入 CLOSED 状态。实际上，这是违反协议的，但又未尝不可呢？

7、FIN-WAIT-2
zhaoyangjian724的专栏
03-27 420
7、FIN-WAIT-2 处于 FIN-WAIT-1状态的连接收到 ACK 确认包以后进入FIN-WAIT-2状态，这个时候主动关闭方的 FIN 包已经被对方确认，等待被动关闭方发送 FIN 包。 客户端超时关闭,服务端在正在处理,没法关闭,客户端处于FIN-WAIT-2 客户端: node2:/root#netstat -an | grep 8080 tcp 0 ...
TCP状态迁移，CLOSE_WAIT & FIN_WAIT2 的问题解决
02-18
对于服务器挂起中的CLOSE_WAIT & FIN_WAIT2 解决方案。
13-TCP 协议（FIN_WAIT2）
进击的小学生
04-08 2625
1. FIN_WAIT_2 状态如果你完成了上一篇文章的实验，你肯定见过了 FIN_WAIT2 状态。当主动关闭一方进入 FIN_WAIT2 状态时，只要对端还没有发送 FIN 段过来（处于 CLOSE_WAIT 状态，等等再关闭，我还有数据要发送），就会一直停留在这个状态。因此，FIN_WAIT2 状态会非常容易见到。 图1 处于 FIN_WAIT2 状态 很不幸，主动关闭一方有可能永远处
TCP协议-状态机
Edidaughter的博客
10-29 2239
1.为什么使用TCP？ 2.TCP协议栈的实现 struct tcphdr{ unsighed short sport; unsighed short dport; unsighed int seqnum; unsighed int acknum; unsigned char hdrlen:4, resv:4; unsigned char cwr:1,
TCP套接口的FIN_WAIT_2状态超时
redwingz的博客
03-14 4186
PROC文件tcp_fin_timeout默认为60秒，内核中相应的变量为init_net.ipv4.sysctl_tcp_fin_timeout，不过其以jiffies表示，默认值为TCP_FIN_TIMEOUT，即（60 * HZ）。此值表示一个不再被应用层使用（执行了close调用）的TCP连接处于FIN_WAIT_2状态的时长，如果在此时间内未能接收到对端的FIN结束报文，内核将复位此连接...
FIN_WAIT_2
10-09 295
来自转载：http://blog.sina.com.cn/s/blog_8e5d24890102w9yi.html 上图对排除和定位网络或系统故障时大有帮助，但是怎样牢牢地将这张图刻在脑中呢？那么你就一定要对这张图的每一个状态，及转换的过程有深刻地认识，不能只 停留在一知半解之中。下面对这张图的11种状态详细解释一下，以便加强记忆！不过在这之前，先回顾一下TCP建立连接...
关于FIN_WAIT2
Micheal
01-15 1112
FIN_WAIT2问题 让我们热热身，通过一张旧图来回忆一下 TCP 关闭连接时的情况： TCP Close 按照正常的状态迁移路径，当 FIN_WAIT2 收到 FIN 包后会迁移到 TIME_WAIT 状态。如果没有收到 FIN 包，那么连接状态会如何迁移，我们不妨测试一下： #!/usr/bin/env python import socket import time s ...
TCP FIN_WAIT2定时器
Blue summer的博客
02-27 1067
注：本文分析基于3.10.107内核版本 之前我们一直考虑的是TCP建链过程中出现问题时，双方用户是如何感知，并处理的。在TCP建链的三次我手中主要是由超时重传定时器以及SYNACK定时器来进行链接状态的维护。下面我们来考虑一下在TCP四次挥手的断链过程中各个socket的状态维护和处理。 在具体分析之前，我们来看下这四次挥手时双方socket状态的转换过程。借用下百科上的图， 此次我们...
FIN_WAIT_2状态解释
花飘万家雪
11-03 8760
在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编程缺陷，...
TCP状态迁移，CLOSE_WAIT & FIN_WAIT2 的问题
土哥的BLOG
10-24 6100
From : http://hi.baidu.com/22000254/blog/item/c7601f018515ba0b728da515.html TCP状态迁移大家对netstat -a命令很熟悉吧，但是，你有没有注意到STATE一栏呢，基本上显示着established,time_wait,close_wait等，这些到底是什么意思呢，在这篇文章，我将会详细的阐述。大家
网络的FIN_WAIT_2状态解释和分析
kld208的专栏
08-09 462
[b]关于网络设备的FIN_WAIT_2状态解释[/b]出处：http://hi.baidu.com/netdemon1981/blog/item/584bfbb2aeb1d4acd9335ad9.html 在HTTP应用中，存在一个问题，SERVER由于某种原因关闭连接，如KEEPALIVE的超时，这样，作为主动关闭的SERVER一方就会进入 FIN_WAIT2状态，但TCP/IP协议栈有个问...
关于服务端的FIN_WAIT2
shellching的专栏
01-06 1965
服务端开启了TCP服务，客户端连接，正常的情况下当服务端closesocket后向客户端发送FIN，客户端回应ACK，此时服务端进入FIN_WAIT2状态，等待客户端发送FIN然后进入CLOSED。 这时，客户端还可以send一次数据，send完后，服务端收到后就会向客户端发送RST并进入CLOSED 若客户端始终不发送数据，并且也不Close，那么服务端的FIN_WAIT2会持续要一个默认超时（一般是60s），这个种残留链接太多的时候可能会消耗服务端资源，降低性能，甚至无法正常工作。 我们可以使用S
转 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。常连.
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状态，不能释
TIME_WAIT状态和FIN_WAIT_2状态
weixin_44810342的博客
12-25 912
TIME_WAIT状态 TIME_WAIT 状态，又称为 2MSL 等待状态。只有主动关闭一方才能进入 TIME_WAIT 状态。 MSL（Maximum Segment Lifetime）表示报文段最大生存时间 当 TCP 协议进入 TIME_WAIT 状态时，必须要在这个状态停留 2 倍 MSL 的时间。 tcp连接在TIME_WAIT状态必须存在2MSL才能进入CLOSE状态。 详情请看 用到2MSL原因 TCP在四次挥手中，可能出现最后一个ACK丢失，即客户端发送的ACK在网络中丢失
TCP连接中 FIN_WAIT_2 状态下的异常关闭
ArtAndLife的博客
03-17 1722
  正常情况下，主动关闭连接的一端（客户端）在 FIN_WAIT_2 状态等待一段时间后，会收到对端（服务器）的FIN报文，从而进入TIME_WAIT状态等待连接的真正关闭。（服务器何时发送FIN取决于服务器应用程序的处理，一般会在read返回0发现客户端已经关闭连接后，也调用close关闭连接）   然而有在某些异常情况下，可能处于 FIN_WAIT_2 状态的一端一直等不到对端的FIN。如果没有外力的作用，连接两端会一直分别处于 FIN_WAIT_2 和 CLOSE_WAIT 状态。这会造成系统资源..
TCP FIN_WAIT_2探究(2)
向往
05-17 353
我们知道，在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
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超时 | 否 |
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值