关于Socket通讯中的Close_wait状态

关于Socket通讯中的Close_wait状态

/ 编辑

编者按:使用Socket通讯,有时我们查看端口状态的时候,经常会发现Socket处于close_wait状态,从而影响系统性能,此文或许会给你一些答案。

最近遇到的一个关于socket.close的问题,在某个应用服务器出现的状况(执行netstat -np | grep tcp): 

tcp        0      0 10.224.122.16:50158         10.224.112.58:8788          CLOSE_WAIT

tcp        0      0 10.224.122.16:37655         10.224.112.58:8788          CLOSE_WAIT

tcp        1      0 127.0.0.1:32713             127.0.0.1:8080              CLOSE_WAIT

tcp       38      0 10.224.122.16:34538         10.224.125.42:443           CLOSE_WAIT

tcp       38      0 10.224.122.16:33394         10.224.125.42:443           CLOSE_WAIT

tcp        1      0 10.224.122.16:18882         10.224.125.10:80            CLOSE_WAIT

tcp        1      0 10.224.122.16:18637         10.224.125.10:80            CLOSE_WAIT

tcp        1      0 10.224.122.16:19655         10.224.125.12:80            CLOSE_WAIT

........................................

 

总共出现了200CLOSE_WAITsocket.而且这些socket长时间得不到释放.下面我们来看看为什么会出现这种大量socketCLOSE_WAIT情况

 

首先我们要搞清楚的是,这个socket是谁发起的,我们可以看到122.16这台机器开了很多端口,而且端口号都很大,125.12 或者125.10上的端口都是很常见服务器端口,所以122.16上这么多CLOSE_WAIT

socket是由122.16开启的,换句话说这台机器是传统的客户端,它会主动的请求其他机器的服务端口.

 

要搞清楚为什么会出现CLOSE_WAIT,那么首先我们必须要清楚CLOSE_WAIT的机制和原理.

 

假设我们有一个client, 一个server.

 

client主动发起一个socket.close()这个时候对应TCP来说,会发生什么事情呢?如下图所示.

 

271750025368258.gif

 

 

client首先发送一个FIN信号给server, 这个时候client变成了FIN_WAIT_1的状态, server端收到FIN之后,返回ACK,然后server端的状态变成了CLOSE_WAIT.

接着server端需要发送一个FINclient,然后server端的状态变成了LAST_ACK,接着client返回一个ACK,然后server端的socket就被成功的关闭了.

 

从这里可以看到,如果由客户端主动关闭一链接,那么客户端是不会出现CLOSE_WAIT状态的.客户端主动关闭链接,那么Server端将会出现CLOSE_WAIT的状态.

而我们的服务器上,是客户端socket出现了CLOSE_WAIT,由此可见这个是由于server主动关闭了server上的socket.

 

那么当server主动发起一个socket.close(),这个时候又发生了一些什么事情呢.

271750029583430.gif

 

从图中我们可以看到,如果是server主动关闭链接,那么Client则有可能进入CLOSE_WAIT,如果Client不发送FIN,那么client就一直会处在CLOSE_WAIT状态(后面我们可以看到有参数可以调整这个时间).

 

那么现在我们要搞清楚的是,在第二中场景中,为什么Client不发送FIN包给server.要搞清楚这个问题,我们首先要搞清楚server是怎么发FIN包给client,其实server就是调用了

socket.close方法而已,也就是说如果要client发送FIN,那么client就必须调用socket.close,否则就client就一直会处在CLOSE_WAIT

 

 

 

 

 





转载于:https://www.cnblogs.com/dimmacro/p/4460848.html

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
网络编程,当客户端向服务器发送请求后,服务器会创建一个套接字用于处理该请求,并在处理完成后关闭该套接字。如果客户端在服务器关闭套接字之前关闭了连接,服务器上的套接字就会进入CLOSE_WAIT状态。这种情况下,如果服务器上存在大量CLOSE_WAIT状态的套接字,就会导致服务器出现性能问题。 要快速释放CLOSE_WAIT状态的套接字,有以下几种方法: 1. 调整TCP的超时参数 可以通过修改TCP的超时参数来加速CLOSE_WAIT状态的套接字释放。具体来说,可以通过调整以下参数: - tcp_fin_timeout:控制发送FIN包后等待对方回复ACK包的时间,默认为60秒,可以缩短该时间来加速CLOSE_WAIT状态的套接字释放。 - tcp_keepalive_time:控制多长时间后发送TCP的Keepalive包,用于检测连接是否已经断开,默认为7200秒,可以缩短该时间来加速CLOSE_WAIT状态的套接字释放。 2. 使用SO_REUSEADDR选项 可以在服务器程序设置SO_REUSEADDR选项,该选项可以让套接字在关闭后立即释放。具体来说,可以在服务器程序添加以下代码: ``` int reuse = 1; setsockopt(sockfd, SOL_SOCKET, SO_REUSEADDR, &reuse, sizeof(reuse)); ``` 3. 调整系统内核参数 可以通过修改系统内核参数来加速CLOSE_WAIT状态的套接字释放。具体来说,可以调整以下参数: - net.ipv4.tcp_fin_timeout:与tcp_fin_timeout参数含义相同,控制发送FIN包后等待对方回复ACK包的时间。 - net.ipv4.tcp_keepalive_time:与tcp_keepalive_time参数含义相同,控制多长时间后发送TCP的Keepalive包。 - net.ipv4.tcp_max_tw_buckets:控制系统最多允许多少个同时处于TIME_WAIT状态的套接字,默认为180000,可以适当增大该值来减少CLOSE_WAIT状态的套接字数量。 以上是一些快速释放CLOSE_WAIT状态的套接字的方法,具体方法应根据实际情况选择。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值