- 浏览: 700087 次
- 性别:
- 来自: 北京
文章分类
- 全部博客 (239)
- 系统架构设计 (16)
- java collection framework (2)
- java分布式 (4)
- java多线程 (0)
- 故障处理及调优 (16)
- 软件开发过程及管理 (28)
- OS (5)
- 常用算法 (3)
- design pattern (8)
- transaction (7)
- java apps (48)
- corejava (7)
- java and DB (10)
- cache (0)
- webservice (14)
- web前端 (25)
- 报表 (4)
- 日志系统设计 (3)
- Oracle (4)
- mysql (11)
- xml (11)
- 数据源配置管理 (3)
- 企业数据存储 (4)
- php (2)
- 测试 (1)
最新评论
-
orangebook:
对于初学者来说,这样编写可能会误导,理解更烦锁。
观察者模式(发布-订阅) -
liudajiang:
呵呵 startThreads(rand ...
实践缩小Java synchronized 粒度 -
zengwenbo5566:
谢谢博主,学习了
解决getOutputStream() has already been called for this response -
u011335423:
大神厉害啊 可以了
解决getOutputStream() has already been called for this response -
xiang37:
...
解决getOutputStream() has already been called for this response
最近遇到的一个关于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
........................................
总共出现了200个CLOSE_WAIT的socket.而且这些socket长时间得不到释放.下面我们来看看为什么会出现这种大量socket的CLOSE_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来说,会发生什么事情呢?如下图所示.
client首先发送一个FIN信号给server, 这个时候client变成了FIN_WAIT_1的状态, server端收到FIN之后,返回ACK,然后server端的状态变成了CLOSE_WAIT.接着server端需要发送一个FIN给client,然后server端的状态变成了LAST_ACK,接着client返回一个ACK,然后server端的socket就被成功的关闭了.
从这里可以看到,如果由客户端主动关闭一链接,那么客户端是不会出现CLOSE_WAIT状态的.客户端主动关闭链接,那么Server端有可能会出现CLOSE_WAIT的状态.而我们的服务器上,是客户端socket出现了CLOSE_WAIT,由此可见这个是由于server主动关闭了server上的socket.那么当server主动发起一个socket.close(),这个时候又发生了一些什么事情呢.
从图中我们可以看到,如果是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(但事实上不同操作系统这点的实现还不一样).
下面我们来做几个实验
实验一:
环境:
服务器端:win7+tomcat,tomcat的keep-alive的时间为默认的15s.
客户端:mac os
实验步骤:服务器启动后,客户端向服务器发送一个get请求,然后客户端阻塞,等待服务器端的socket超时.通过netstat -np tcp可以看到的情况是发送get请求时,服务器和客户端链接是ESTABLISHED, 15s之后,客户端变成了CLOSE_WAIT,而服务器端变成了FIN_WAIT_2.这一点也在我们的预料之中,而这个时候由于客户端线程阻塞,客户 端socket空置在那里,不做任何操作,2分钟过后,这个链接不管是在win7上,还是在mac os都看不到了.可见,FIN_WAIT_2或者CLOSE_WAIT有一个timeout.在后面的实验,可以证明,在这个例子中,其实是 FIN_WAIT_2有一个超时,一旦过了2分钟,那么win7会发一个RST给mac os要求关闭双方的socket.
实验二
服务器端:ubuntu9.10+tomcat,tomcat的keep-alive的时间为默认的15s.
客户端:mac os
实验步骤:服务器启动后,客户端向服务器发送一个get请求,然后客户端阻塞,等待服务器端的socket超时.通过netstat -np tcp(ubuntu使用netstat -np|grep tcp)可以看到的情况是发送get请求时,服务器和客户端链接是ESTABLISHED, 15s之后,客户端变成了CLOSE_WAIT,而服务器端变成了FIN_WAIT_2.这一点也也在我们的预料之中,而这个时候由于客户端线程阻塞,客 户端socket空置在那里,不做任何操作,1分钟过后,ubuntu上的那个socket不见了,但是mac os上的socket还在,而且还是CLOSE_WAIT,这说明,FIN_WAIT_2确实有一个超时时间,win7上的超时操作可以关闭mac os上的socket,而ubuntu上的FIN_WAIT_2超时操作却不能关闭mac os上的socket(其状一直是CLOSE_WAIT).
实验三
服务器端:mac os+tomcat,tomcat的keep-alive的时间为默认的15s.
客户端:mac os
实验步骤:服务器启动后,客户端向服务器发送一个get请求,然后客户端阻塞,等待服务器端的socket超时.通过netstat -np tcp可以看到的情况是发送get请求时,服务器和客户端链接是ESTABLISHED, 15s之后,客户端变成了CLOSE_WAIT,而服务器端变成了FIN_WAIT_2.这一点也在我们的预料之中,而这个时候由于客户端线程阻塞,客户 端socket空置在那里,不做任何操作,4分钟过后,mac os服务器端上的那个socket不见了,但是mac os客户端上的socket还在,而且还是CLOSE_WAIT,这说明,FIN_WAIT_2确实有一个超时时间,win7上的超时操作可以关闭mac os上的socket,而ubuntu和mac os上的FIN_WAIT_2超时操作却不能关闭mac os上的socket.
总结, 当服务器的内核不一样上FIN_WAIT_2的超时时间和操作是不一样的.
经查:控制FIN_WAIT_2的参数为:
/proc/sys/net/ipv4/tcp_fin_timeout
如 果套接字由本端要求关闭,这个参数决定了它保持在FIN-WAIT-2状态的时间。对端可以出错并永远不关闭连接,甚至意外当机。缺省值是60秒。2.2 内核的通常值是180秒,你可以按这个设置,但要记住的是,即使你的机器是一个轻载的WEB服务器,也有因为大量的死套接字而内存溢出的风险,FIN- WAIT-2的危险性比FIN-WAIT-1要小,因为它最多只能吃掉1.5K内存,但是它们的生存期长些。参见tcp_max_orphans。
实验四
服务器端:ubuntu9.10+tomcat,tomcat的keep-alive的时间为默认的15s.
客户端:mac os
实验步骤:服务器启动后,客户端向服务器发送一个get请求,然后关闭客户端关闭socket.通过netstat -np tcp可以看到的情况是发送get请求时,服务器和客户端链接是ESTABLISHED, 客户端拿到数据之后,客户端变成了TIME_WAIT,而服务器端变成了已经看不到这个socket了.这一点也也在我们的预料之中,谁主动关闭链接,那 么谁就需要进入TIME_WAIT状态(除非他的FIN_WAIT_2超时了),大约1分钟之后这个socket在客户端也消失了.
实验证明TIME_WAIT的状态会存在一段时间,而且在这个时间端里,这个FD是不能被回收的.但是我们的问题是客户端有很多CLOSE_WAIT,而且我们的服务器不是windows,而是linux,所以CLOSE_WAIT有没有超时时间呢,肯定有,而且默认情况下这个超时时间应该是比较大的.否则不会一下子看到两百个CLOSE_WAIT的状态.
客户端解决方案:
1.由于socket.close()会导致FIN信号,而client的socket CLOSE_WAIT就是因为该socket该关的时候,我们没有关,所以我们需要一个线程池来检查空闲连接中哪些进入了超时状态(idleTIME),但进入超时的socket未必是CLOSE_WAIT的状态的.不过如果我们把空闲超时的socket关闭,那么CLOSE_WAIT的状态就会消失.(问 题:像HttpClient这样的工具包中,如果要检查链接池,那么则需要锁定整个池,而这个时候,用户请求获取connection的操作只能等待,在 高并发的时候会造成程序响应速度下降,具体参考IdleConnectionTimeoutThread.java(HttpClient3.1))
2.经查,其实有参数可以调整CLOSE_WAIT的持续时间,如果我们改变这个时间,那么可以让CLOSE_WAIT只保持很短的时间(当然这个参数不只作用在CLOSE_WAIT上,缩短这个时间可能会带来其他的影响).在客户端机器上修改如下:
sysctl -w net.ipv4.tcp_keepalive_time=60(缺省是2小时,现在改成了60秒)
sysctl -w net.ipv4.tcp_keepalive_probes=2
sysctl -w net.ipv4.tcp_keepalive_intvl=2
我们将CLOSE_WAIT的检查时间设置为30s,这样一个CLOSE_WAIT只会存在30S.
3. 当然,最重要的是我们要检查客户端链接的空闲时间,空闲时间可以由客户端自行定义,比如idleTimeout,也可由服务器来决定,服务器只需要每次在 response.header中加入一个头信息,比如说名字叫做timeout头,当然一般情况下我们会用keep-alive这个头字段, 如果服务器设置了该字段,那么客户端拿到这个属性之后,就知道自己的connection最大的空闲时间,这样不会由于服务器关闭socket,而导致客 户端socket一直close_wait在那里.
服务器端解决方案
4.前面讲到客户端出现CLOSE_WAIT是由于服务器端Socket的读超时,也是TOMCAT中的keep-alive参数.那么如果我们把这个超时时间设置的长点,会有什么影响?
如果我们的tomcat既服务于浏览器,又服务于其他的 APP,而且我们把connection的keep-alive时间设置为10分钟,那么带来的后果是浏览器打开一个页面,然后这个页面一直不关闭,那么 服务器上的socket也不能关闭,它所占用的FD也不能服务于其他请求.如果并发一高,很快服务器的资源将会被耗尽.新的请求再也进不来. 那么如果把keep-alive的时间设置的短一点呢,比如15s? 那么其他的APP来访问这个服务器的时候,一旦这个socket, 15s之内没有新的请求,那么客户端APP的socket将出现大量的CLOSE_WAIT状态.
所以如果出现这种情况,建议将你的server分开部署,服务于browser的部署到单独的JVM实例上,保持keep-alive为15s,而服务于架构中其他应用的功能部署到另外的JVM实例中,并且将keep-alive的时间设置的更长,比如说1个小时.这样客户端APP建立的connection,如果在一个小时之内都没有重用这条connection,那么客户端的 socket才会进入CLOSE_WAIT的状态.针对不同的应用场景来设置不同的keep-alive时间,可以帮助我们提高程序的性能.
5.如果我们的应用既服务于浏览器,又服务于其他的APP,那么我们还有一个终极解决方案.那就是配置多个connector, 如下:
<!-- for browser --> <Connector port="8080" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" /> <!-- for other APP --> <Connector port="8081" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" keepAliveTimeout="330000" />
访问的时候,浏览器使用8080端口,其他的APP使用8081端口.这样可以保证浏览器请求的socket在15s之内如果没有再次使用,那么 tomcat会主动关闭该socket,而其他APP请求的socket在330s之内没有使用,才关闭该socket,这样做可以大大减少其他APP上 出现CLOSE_WAIT的几率.
你一定会问,如果我不设置keepAliveTimeout又怎么样呢,反正客户端有idleTimeout,客户端的close_wait不会持 续太长时间,请注意看上图中标红的地方,一个是close_wait,还有一个是time_wait状态,也就是说谁主动发起请求,那么它将会最终进入 time_wait状态,据说windows上这个time_wait将持续4分钟,我在linux上的测试表明,linux上它大概是60s左右,也就 是说高并发下,也就是服务器也需要过60s左右才能真正的释放这个FD.所以我们如果提供http服务给其他APP,那么我们最好让客户端优先关闭 socket,也就是将客户端的idleTimeout设置的比server的keepalivetimeout小一点.这样保证time_wait出现 在客户端. 而不是资源较为紧张的服务器端.
总结:
本文中ahuaxuan给大家揭示了TCP层client和server端socket关闭的一般流程,并且指出异常情况下client和server端 各自会发生的情况,包含了在不同平台上出现了的不同情况, 同时说明了在应用层上我们可以做什么样的逻辑来保证socket关闭时对server端带来最小的影响.
其他资料:
/proc/sys/net/ipv4/tcp_keepalive_time
当keepalive起用的时候,TCP发送keepalive消息的频度。缺省是2小时。
/proc/sys/net/ipv4/tcp_keepalive_intvl
当探测没有确认时,重新发送探测的频度。缺省是75秒。
/proc
/sys/net/ipv4/tcp_keepalive_probes
在认定连接失效之前,发送多少个TCP的keepalive探测包。缺省值是
9。这个值乘以tcp_keepalive_intvl之后决定了,一个连接发送了keepalive之后可以有多少时间没有回应。
/proc/sys/net/ipv4/tcp_max_orphans
系
统中最多有多少个TCP套接字不被关联到任何一个用户文件句柄上。如果超过这个数字,孤儿连接将即刻被复位并打印出警告信息。这个限制仅仅是为了防止简单
的DoS攻击,你绝对不能过分依靠它或者人为地减小这个值,更应该增加这个值(如果增加了内存之后)。
This limit exists only
to prevent simple DoS attacks, you _must_ not rely on this or lower the
limit artificially, but rather increase it (probably, after increasing
installed memory), if network conditions require more than default
value, and tune network services to linger and kill such states more
aggressively. 让我再次提醒你:每个孤儿套接字最多能够吃掉你64K不可交换的内存。
/proc/sys/net/ipv4/tcp_orphan_retries
本端试图关闭TCP连接之前重试多少次。缺省值是7,相当于50秒~16分钟(取决于RTO)。如果你的机器是一个重载的WEB服务器,你应该考虑减低这个值,因为这样的套接字会消耗很多重要的资源。参见tcp_max_orphans。
/proc/sys/net/ipv4/tcp_max_syn_backlog
记
录的那些尚未收到客户端确认信息的连接请求的最大值。对于有128M内存的系统而言,缺省值是1024,小内存的系统则是128。如果服务器不堪重负,试
试提高这个值。注意!如果你设置这个值大于1024,最好同时调整include/net/tcp.h中的TCP_SYNQ_HSIZE,以保证
TCP_SYNQ_HSIZE*16 ≤tcp_max_syn_backlo,然后重新编译内核。
/proc/sys/net/ipv4/tcp_max_tw_buckets
系
统同时保持timewait套接字的最大数量。如果超过这个数字,time-wait套接字将立刻被清除并打印警告信息。这个限制仅仅是为了防止简单的
DoS攻击,你绝对不能过分依靠它或者人为地减小这个值,如果网络实际需要大于缺省值,更应该增加这个值(如果增加了内存之后)。
发表评论
-
java服务,cpu高,内存高,telnet不通排查及分析
2013-12-22 12:29 3095记录上周五的一个java服务的异常排查及分析过程,以备将来 ... -
QPS、PV和需要部署机器数量计算公式
2013-07-31 16:39 1715QPS = req/sec = 请求数/秒 【QPS ... -
java自带监视工具使用_jmap_jhat
2013-07-06 17:50 883jmap命令(Java Memory Map)1.介绍打 ... -
java自带监视工具使用_jps_jstack
2013-07-06 17:32 1863jps命令(Java Virtual Machin ... -
处理OutOfMemoryError: PermGen space
2013-07-06 12:15 1423前两天后台系统内存溢出错误,查看tomcat日志,看到如下 ... -
Heap OOM故障实例2_websphere应用部署
2013-03-20 18:21 2056根据用户需求,将公司 ... -
Heap OOM故障实例1
2013-02-25 15:43 1372故障描述: 线上系统运行过程中出现OOM异常,导致jvm ... -
visualVM远程监视安装
2012-08-10 14:44 10941. 通过jstatd启动RMI服务 ... -
tomcat内存配置及项目实践
2010-04-29 16:07 1693最近在做一个数据请求 ... -
利用JProfiler对应用服务器内存泄漏问题诊断一例-2
2009-09-10 17:22 3171实施情况 采用的方案:某某软件商采用了新的会话登录信息 ... -
利用JProfiler对应用服务器内存泄漏问题诊断一例-1
2009-09-10 17:16 1576在中间件应用服务器 ... -
jconsole+tomcat配置说明-3-基于jdk1.5
2009-09-07 16:33 4512Figure 15: List of All Logger N ... -
jconsole+tomcat配置说明-2-基于jdk1.5
2009-09-07 16:18 1728Figure 9: Threads Tab. ... -
jconsole+tomcat配置说明-1-基于jdk1.5
2009-09-07 16:08 2739JConsole是JDK自带的东西,功能虽然没有一些商业软件那 ... -
监控和剖析数据库操作 -- P6Spy、SQL Profiler、IronTrack SQL 使用简
2008-12-31 16:37 1862俞 黎敏 (mailto:YuLimin@163. ...
相关推荐
CLOSE_WAIT是一个常见的TCP连接状态,指的是服务器端的连接在客户端关闭后还未释放的情况。这种情况经常出现于客户端主动断开连接,但服务器端没有正确关闭连接的情况下。这种情况可能会导致服务器端出现大量未释放...
"TCP 状态迁移,CLOSE_WAIT & FIN_WAIT2 的问题解决" TCP 状态迁移是 TCP 协议中的一种机制,它用于描述 TCP 连接的不同状态。在 TCP 连接中,客户端和服务器端都可以处于不同的状态,例如 ESTABLISHED、CLOSE_WAIT...
"Close_Wait"状态在TCP连接管理中是一个关键的概念,我们先来深入理解这个状态以及它在计算机网络中的意义。TCP(传输控制协议)是一种面向连接的、可靠的、基于字节流的传输层通信协议,它确保数据在互联网上可靠地...
当TCP连接出现“Close_Wait”状态时,通常意味着客户端已经关闭了发送方向服务器的数据传输,但服务器仍有数据需要发送给客户端。这个状态是TCP连接关闭过程中的一个中间状态,体现了TCP的四次挥手(FIN-ACK-FIN-ACK...
在TCP/IP协议栈中,CLOSE_WAIT是一个非常关键的连接状态,它涉及到客户端和服务器之间的通信。这个状态在处理网络连接时可能出现的问题时尤其重要。本文将深入探讨CLOSE_WAIT错误的含义、原因以及如何解决。 首先,...
在TCP/IP协议栈中,"Close_Wait"是一种连接状态,表示一个方向的连接已经关闭,而另一个方向仍然保持开放,等待应用层关闭。当服务器接收到客户端的FIN(结束)标志,它会进入Close_Wait状态,表示服务器已经接收到...
这也是为什么有些人会建议调整sysctl.conf中的tcp_tw_reuse和tcp_tw_recycle参数,试图复用TIME_WAIT连接或快速回收它们。 然而,直接调整这些参数并不总是最佳解决方案,因为它们可能引入其他问题,比如导致连接...
6. `net.ipv4.tcp_tw_reuse`:允许重用TIME_WAIT状态的连接,加速新连接的建立。 7. `net.ipv4.tcp_tw_recycle`:开启TIME_WAIT连接的快速回收。 8. `net.ipv4.tcp_fin_timeout`:减少FIN-WAIT-2状态的持续时间,更...
- `tcp_tw_recycle`:当设置为1时,开启time_wait状态的快速回收,但需双方都开启`tcp_timestamps`。 - `tcp_timestamps`:时间戳选项,用于协助快速回收和序列号校验,若此选项设为1,`tcp_tw_recycle`才能生效。 -...
4. **开启tcp_tw_recycle和tcp_timestamps**: 开启这两个内核选项,可以加速TIME_WAIT状态的回收,但可能导致某些连接问题,比如穿越NAT的连接可能失败,因为TCP时间戳可能不被所有网络设备支持。 5. **启用tcp_...
通过修改`net.ipv4.tcp_fin_timeout`参数,可以调整TIME_WAIT状态的默认超时时间。 ```bash net.ipv4.tcp_fin_timeout=30 ``` 这里将TIME_WAIT状态的超时时间设置为30秒,需要注意的是,过短的时间可能导致...
- `net.ipv4.tcp_tw_reuse=1`:允许将处于TIME_WAIT状态的端口重用,加快端口的回收利用。 - `net.ipv4.tcp_tw_recycle=1`:加速TIME_WAIT状态的回收过程。 - `net.ipv4.tcp_fin_timeout=30`:缩短TIME_WAIT状态...
TCP_SYNC基础 TCP SYNC 基础知识详解 TCP 状态迁移是一个复杂的过程,很多人对 netstat -a 命令很熟悉,但是,对 STATE 一栏的理解却鲜为人知。本文将详细阐述 TCP 状态迁移的知识点。 TCP 连接建立 TCP 连接...
* `net.ipv4.tcp_tw_recycle = 1`:表示开启 TCP 连接中 TIME-WAIT sockets 的快速回收,默认为 0,表示关闭。 * `net.ipv4.tcp_fin_timeout = 30`:修改系统默认的 TIMEOUT 时间。 2. 执行 `/sbin/sysctl -p` 命令...
TCP_FIN_TIMEOUT参数定义了TIME_WAIT状态的持续时间,默认为60秒。将其缩短至30秒可以更快地释放TIME_WAIT状态的连接,但这也意味着任何潜在的网络延迟数据包可能在新连接建立前被丢弃,因此需谨慎调整。 ### 5. ...
在处理TCP连接时,需要特别关注close()函数的使用,因为它可能直接影响到TIME_WAIT状态的处理。 `c-means`可能是指一种基于C语言的聚类算法,虽然在这个上下文中没有直接关联,但如果你正在学习C语言编程,并试图将...
2. **允许TCP TIME_WAIT套接字复用**:设置`net.ipv4.tcp_tw_reuse = 1`,允许在某些条件下复用TIME_WAIT套接字,减少其占用的端口资源。 3. **加速TIME_WAIT套接字回收**:设置`net.ipv4.tcp_tw_recycle = 1`,...
3. `net.ipv4.tcp_tw_recycle = 1`:快速回收TIME_WAIT套接字,但注意此选项可能在某些网络环境下导致问题,如NAT环境。 4. `net.ipv4.tcp_fin_timeout = 30`:设置FIN_WAIT-2状态的持续时间,减少等待时间。 5. `...
- `tcp_tw_recycle`:开启此选项可以加速TIME_WAIT连接的回收。但是,这可能导致一些兼容性问题,比如与NAT设备或防火墙的交互可能受到影响,因此在启用时需谨慎。 - `tcp_tw_reuse`:允许在协议安全的情况下复用...