客户端会否出现CLOSEWAIT状态

Question

发现客户端偶尔会出现类似死机的状态，信息通道完全堵死，只有手工干预（启动）才能再连接。这会不会就是所谓的IDL状态。

Answer 1

那还是程序的问题 CLOSE_WAIT只要你服务端close了客户端不就出现了 
服务端close你还维持什么通信信道 直接close打法得了
你客户端要是在此状态下 一直不close就是你自己的问题咯
比方一个男的已经软了 自认为做完了 就起身走人并且说“下次见” 女的听了无动于衷 保持着ml的姿势很长时间 你说能怪这男的吗？

Answer 2

问题是服务端并未发出close之类的信息。客户端自行决定自己的“怠机”状态。

Answer 3

根据TCP协议 CLOSE_WAIT就是要對方主動close 導致發過來一個FIN 而且你这边回一个ACK 你才会变成此状态 你做的假设实际上不存在 
如果实在找不到你这边在CLOSE_WAIT后为什么没调closesocket也不知道那一端啥时候close了 你可以让自己这边的socket定时检查状态 如果发现谁CLOSE_WAIT状态维持了太长时间 基本就可以认定它僵在那里了 那就一个closesocket送它上路

Answer 4

客户端不是我编的，无法修改。我想知道的是客户端的状态，客户端有时会僵在那里，必须重启才行，IP又是通的。这种“僵状态”是否一定是CLOSE_WAIT，或还有其他情况也会导致僵在那里。

Answer 5

这个和是不是客户端没有关系，如果是被动关闭的，会出现close_wait

Answer 6

出现close_wait是你无法控制的，如果对数据完整性(最后n包是否可达)要求不高的话，可以设置socket属性直接发RESET过去就好了（设置Linger），就不会出现close_wait了。
4楼说的检测close_wait状态并且用closesocket送它上路，出现close_wait的状态不是closesocket能控制的

Answer 7

问一下1、根据原理，如果对方是close_wait状态，应该不会接受本方发出的任何信息了，同死机状态一样，即使本方重新打开监听，也无法重新连接，对吧。2、从本方角度来说，如何防止对方出现close_wait状态。发现有时即使本方未关闭连，对方也会出现close_wait状态，导致close_wait状态的原因好像不仅仅是一方关闭另一方出现close_wait状态那么简单。

Answer 8

1.没明白你问的意思，close_wait只是单个socket的状态，不会影响其他的，只是会占用系统资源，并且程序不退出永远无法消退，多了的话，你就申请不出socket了。
2.现实上来讲你永远无法防止对方不出现close_wait，除非你设置linger强制关闭。因为你的FIN,ACK总有可能发不到对端，所以TCP为了保证不让自己陷入发送->应答，等待应答的应答，这种逻辑死循环，close4次握手的最后两次，发出去就不管了，只是等待自己状态改变而已。

Answer 9

我遇到一种现象，本地是服务端，远方是客户端，正常时远方客户端会不断地与服务端联系，即使暂时中断也会很快地恢复连接。但远方客户端偶尔会出现一种近乎死机的close_wait，僵在那里，无法发起与服务端连接，只能重启。期间，远方客户端并无人工干预。