linux产生大量CLOSE_WAIT且进程名为- 问题

博客讲述了作者在实现一个ONVIF相机模拟器时遇到的问题,当部分相机拉取流媒体时,系统出现大量CLOSE_WAIT状态的连接。分析发现,这可能是由于一个进程中同时绑定多个端口进行数据收发,影响了accept函数的调用,导致系统无法正确关闭连接。最终通过在子进程中处理流媒体服务解决了问题。

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

背景:

        写了个简单的onvif相机模拟器,流程是绑定1000个端口作为onvif相机注册信令交换,又绑定一个端口作为rtsp流媒体服务,onvif信令是http请求会经常建立http短链接,奇怪的事是:当部分相机拉着流时,系统就会出现大量CLOSE_WAIT的链接,显示的进程为 -,且存在待接收数据。没有拉流就不会有,有的CLOSE_WAIT也会消失。

执行 netstat -nap|grep CLOSE_WAIT如下:

先的时候没发现这个规律,很是头疼一直找是不是什么地方漏close socket了。

抓包分析:

        抓包来看客户端链接tcp 3次握手正常,客户端发来数据,服务器始终无响应,客户端关闭链接。onvif信令和流媒体服务是不同的线程,cpu没有饱和。

怀疑点:

        客户端链接上以后,系统底层完成了tcp 3次握手链接,发起软中断信号等待应用程序调用accept函数接收句柄,但当前线程受其他数据收发影响,导致accept函数不能返回底层建好的链接。程序中定时轮循调用1000个端口绑定的socket accetp,accetp始终返回负数。

        【更新】可能是linux系统限制了socket打开数量,由于已经绑定了1024端口且接收了多个socket,所以再收到链接时系统不能再分配socket。

修改解决:

        fork一个子进程,让流媒体服务的流数据收发到另一个进程就好了。

结论:

        一个进程中绑定多个端口时,数据的收发可能影响accept函数返回socket句柄,导致系统产生大量CLOSE_WAIT句柄,此类CLOSE_WAIT句柄进程名为 - ,排查CLOSE_WAIT原因时需要考虑。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值