tcp 服务端FIN_WAIT_2 状态下,客户端操作的抛错实验

本文探讨了TCP连接中客户端发送数据后意外关闭连接导致的异常处理机制,以及服务器端如何响应并进入关闭状态的过程。重点分析了客户端通过RST指令使连接从CLOSE_WAIT状态直接进入CLOSE状态的原理。

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


import java.io.BufferedWriter;
import java.io.InputStream;
import java.io.OutputStream;
import java.io.OutputStreamWriter;
import java.net.Socket;
//客户端

public class Client {
  //private static String text="您好";

  public static void main(String[] args) {
     //Connection reset 连接被重置
    try{
    //创建套接字的连接对象
    Socket socket = new Socket("127.0.0.1",9090);
    OutputStream os = socket.getOutputStream();
    InputStream inputStream = socket.getInputStream();
    OutputStreamWriter osw = new OutputStreamWriter(os);
    BufferedWriter bdw = new BufferedWriter(osw);
    //
    String text="12\n";  //断点
    bdw.write(text, 0, text.length());
    bdw.flush();
    byte[] b=new byte[1];
    int read = inputStream.read(b);  // 代码1
   

    System.out.println("client");
//    bdw.close();
    }catch(Exception e){
      e.printStackTrace();
    }finally {
        System.out.println("server close");

    }
  }

}



client执行到断点处后,杀掉server进程。 这个时候操作系统会 自动帮你发送 tcp fin 命令。 这个是让人难以理解的。

通过 查看端口状态可知 服务端处于 FIN_WAIT_2 ,客户端处于CLOSE_WAIT  ,同时可知 [连接和进程是独立的]

 (更多 tcp 状态转移知识 可查看 http://blog.youkuaiyun.com/fei33423/article/details/50889385)

➜  ~ netstat -an | grep 127.0.0.1
tcp4       0      0  127.0.0.1.9090         127.0.0.1.49171        FIN_WAIT_2
tcp4       0      0  127.0.0.1.49171        127.0.0.1.9090         CLOSE_WAIT

第一个write 不报错,这个是很让人匪夷所思的。 通过抓包可知,服务端返回 rst ( tcp rst 标记位)

      rst是操作系统 tcp协议栈自动发送的

并且可以看到端口消失了。

说明客户端通过rst指令可以从close_wait进入到close状态.

服务端可以从fin_wait_2状态 直接走到close状态.(不排除,抛exception后, 进程被关闭了客户端发送fin)


 ➜  ~ netstat -an | grep 127.0.0.1


代码1 处会抛异常。

java.net.SocketException: Connection reset
    at java.net.SocketInputStream.read(SocketInputStream.java:196)
    at java.net.SocketInputStream.read(SocketInputStream.java:122)
    at java.net.SocketInputStream.read(SocketInputStream.java:108)
    at com.alibaba.rocketmq.common.admin.Client.main(Client.java:28)


如果把代码1 替换未 下面代码。

第一个write 依然不报错

第二个write会报如下错误。


bdw.write(text, 0, text.length());
    bdw.flush();


java.net.SocketException: Broken pipe
    at java.net.SocketOutputStream.socketWrite0(Native Method)
    at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:113)
    at java.net.SocketOutputStream.write(SocketOutputStream.java:159)
    at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221)
    at sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:291)
    at sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:295)
    at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:141)
    at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:229)
    at java.io.BufferedWriter.flush(BufferedWriter.java:254)
    at com.alibaba.rocketmq.common.admin.Client.main(Client.java:28)



public class server {

    public static void main(String[] args) {
        try {
            ServerSocket server = new ServerSocket(9090);
            System.out.println("server:等待客户端连接");
            Socket socket = server.accept();
            System.out.println(socket.getRemoteSocketAddress() + "连接上服务器");

            InputStream is = socket.getInputStream();
            byte[] b = new byte[1];
            while (true) {
                int read = is.read(b);
                if(read!=-1){
                        System.out.println("line:" + b[0]);
                }else{
                        System.out.println("-1");
                }
            }
        } catch (Exception e) {
            e.printStackTrace();
        } finally {
            System.out.println("server close");
        }
    }

}


<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、付费专栏及课程。

余额充值