☰

如果一个端口持续（一天或多天）处于 FIN_WAIT1 状态，会发生什么情况？

tag-icon • tag-icon linux networking tcp network-protocols
如果一个端口持续（一天或多天）处于 FIN_WAIT1 状态，会发生什么情况？

当我尝试与服务器通信时遇到了问题。

如果我使用命令行：

netstat -np 10.aaa.bbb.12

其中 10.aaa.bbb.12 表示服务器地址；我获得了以下结果的摘录：

    tcp        0     87 10.xxx.yyy.4:59438          10.aaa.bbb.12:7955          FIN_WAIT1   -                   
    tcp        0     87 10.xxx.yyy.4:36100          10.aaa.bbb.12:7952          FIN_WAIT1   -                   
    tcp        0     87 10.xxx.yyy.4:59422          10.aaa.bbb.12:7955          FIN_WAIT1   -                   
    tcp        0     87 10.xxx.yyy.4:41678          10.aaa.bbb.12:7951          FIN_WAIT1   -                   
    tcp        0     87 10.xxx.yyy.4:60999          10.aaa.bbb.12:7953          FIN_WAIT1   -                   
    tcp        0     86 10.xxx.yyy.4:59456          10.aaa.bbb.12:7955          ESTABLISHED 21203/sender   
    tcp        0     87 10.xxx.yyy.4:41694          10.aaa.bbb.12:7951          FIN_WAIT1   -                   
    tcp        0     87 10.xxx.yyy.4:36084          10.aaa.bbb.12:7952          FIN_WAIT1   -                   
    tcp        0     87 10.xxx.yyy.4:60966          10.aaa.bbb.12:7953          FIN_WAIT1   -                   
    tcp        0     87 10.xxx.yyy.4:41711          10.aaa.bbb.12:7951          FIN_WAIT1   -                   
    tcp        0     86 10.xxx.yyy.4:32783          10.aaa.bbb.12:7953          ESTABLISHED 21269/sender   
    tcp        0     87 10.xxx.yyy.4:60983          10.aaa.bbb.12:7953          FIN_WAIT1   -                   
    tcp        0     86 10.xxx.yyy.4:41728          10.aaa.bbb.12:7951          ESTABLISHED 21225/sender   
    tcp        0     86 10.xxx.yyy.4:36118          10.aaa.bbb.12:7952          ESTABLISHED 21247/sender

港口FIN_WAIT1有这种状态从有一天。我不明白为什么。

上述状态的所有服务器端口均接受连接，并且服务器似乎接受了命令，但服务器并未像我们预期的那样做出回复。所有等待服务器的回复均超时。

我可以使用以下命令行来验证与服务器的连接：

nc 10.150.224.12 7955 -w 10 <ts.txt

文件 ts.txt 包含一个需要我们已知的特定答复的命令。

答案1

这似乎发生在服务器与客户端有活动连接并想要关闭 TCP 连接时（可能响应正常的应用层“退出”）。服务器向客户端发送一个设置了“FIN”位的数据包。此时，服务器处于该FIN_WAIT_1状态。当客户端收到 FIN 数据包时，它会进入 CLOSE_WAIT 状态并向服务器发送确认数据包，然后服务器将进入该FIN_WAIT_2状态。

这意味着您的客户端在没有有序关闭其 TCP 套接字的情况下就断开了。

最好的解决办法是修正应用程序。

立即和临时的解决方案是运行这个 ServerFault 脚本：

# record what tcp_max_orphans's current value
original_value=$(cat /proc/sys/net/ipv4/tcp_max_orphans)

#set the tcp_max_orphans to 0 temporarily
echo 0 > /proc/sys/net/ipv4/tcp_max_orphans

# watch /var/log/messages
# it will split out "kernel: TCP: too many of orphaned sockets"
# it won't take long for the connections to be killed

# restore the value of tcp_max_orphans whatever it was before. 
echo $original_value > /proc/sys/net/ipv4/tcp_max_orphans

# verify with 
netstat -an|grep FIN_WAIT1

您也可以设置 tcp_orphan_retries 位于 处 /proc/sys/net/ipv4/tcp_orphan_retries，以减少这些套接字保持此状态的时间。请注意 的值0实际上意味着8。

但同样，最好的解决方案是纠正应用程序以正确关闭。

相关内容