close wait在英文中我们很少看到,但它却确确实实地存在着,它的意思是什么呢?下面是我给大家整理的close wait什么意思,供大家参阅!
close wait什么意思等待结束
TIME WAIT和CLOSE WAIT状态区别在服务器的日常维护过程中,会经常用到下面的命令:
它会显示例如下面的信息:
[plain] view plain copy
netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'
TIME_WAIT 814
CLOSE_WAIT 1
FIN_WAIT1 1
ESTABLISHED 634
SYN_RECV 2
LAST_ACK 1
常用的三个状态是:ESTABLISHED 表示正在通信,TIME_WAIT 表示主动关闭,CLOSE_WAIT 表示被动关闭。
TCP协议规定,对于已经建立的连接,网络双方要进行四次握手才能成功断开连接,如果缺少了其中某个步骤,将会使连接处于假死状态,连接本身占用的资源不会被释放。网络服务器程序要同时管理大量连接,所以很有必要保证无用连接完全断开,否则大量僵死的连接会浪费许多服务器资源。在众多TCP状态中,最值得注意的状态有两个:CLOSE_WAIT和TIME_WAIT。
TIME_WAIT
TIME_WAIT 是主动关闭链接时形成的,等待2MSL时间,约4分钟。主要是防止最后一个ACK丢失。 由于TIME_WAIT 的时间会非常长,因此server端应尽量减少主动关闭连接
CLOSE_WAIT
CLOSE_WAIT是被动关闭连接是形成的。根据TCP状态机,服务器端收到客户端发送的FIN,则按照TCP实现发送ACK,因此进入CLOSE_WAIT状态。但如果服务器端不执行close(),就不能由CLOSE_WAIT迁移到LAST_ACK,则系统中会存在很多CLOSE_WAIT状态的连接。此时,可能是系统忙于处理读、写 *** 作,而未将已收到FIN的连接,进行close。此时,recv/read已收到FIN的连接socket,会返回0。
为什么需要 TIME_WAIT 状态?
假设最终的ACK丢失,server将重发FIN,client必须维护TCP状态信息以便可以重发最终的ACK,否则会发送RST,结果server认为发生错误。TCP实现必须可靠地终止连接的两个方向(全双工关闭),client必须进入 TIME_WAIT 状态,因为client可能面 临重发最终ACK的情形。
为什么 TIME_WAIT 状态需要保持 2MSL 这么长的时间?
如果 TIME_WAIT 状态保持时间不足够长(比如小于2MSL),第一个连接就正常终止了。第二个拥有相同相关五元组的连接出现,而第一个连接的重复报文到达,干扰了第二个连接。TCP实现必须防止某个连接的重复报文在连接终止后出现,所以让TIME_WAIT状态保持时间足够长(2MSL),连接相应方向上的TCP报文要么完全响应完毕,要么被 丢弃。建立第二个连接的时候,不会混淆。
TIME_WAIT 和CLOSE_WAIT状态socket过多
如果服务器出了异常,百分之八九十都是下面两种情况:
1.服务器保持了大量TIME_WAIT状态
2.服务器保持了大量CLOSE_WAIT状态,简单来说CLOSE_WAIT数目过大是由于被动关闭连接处理不当导致的。
因为Linux分配给一个用户的文件句柄是有限的,而TIME_WAIT和CLOSE_WAIT两种状态如果一直被保持,那么意味着对应数目的通道就一直被占着,而且是“占着茅坑不使劲”,一旦达到句柄数上限,新的请求就无法被处理了,接着就是大量Too Many Open Files异常,Tomcat崩溃。
netstat listening close wait established等是什么意思端口占用查询命令“netstat”详解 Netstat用于显示与IP、TCP、UDP和ICMP协议相关的统计数据,一般用于检验本机各端口的网络连接情况。 如果你的计算机有时候接收到的数据报导致出错数据或故障,你不必感到奇怪,TCP/IP可以容许这些类型的错误,并能够自动重发数据报。但如果累计的出错情况数目占到所接收的IP数据报相当大的百分比,或者它的数目正迅速增加,那么你就应该使用Netstat查一查为什么会出现这些情况了。 Netstat 详细参数列表 C:\>netstat /? 显示协议统计信息和当前 TCP/IP 网络连接。 NETSTAT [-a] [-b] [-e] [-n] [-o] [-p proto] [-r] [-s] [-v] [interval] -a 显示所有连接和监听端口。 -b 显示包含于创建每个连接或监听端口的可执行组件。在某些情况下已知可执行组件 拥有多个独立组件,并且在这些情况下包含于创建连接或监听端口的组件序列被显示。 这种情况下,可执行组件名在底部的 [] 中,顶部是其调用的组件,等等,直到 TCP/IP 部分。注意此选项可能需要很长时间,如果没有足够权限可能失败。 -e 显示以太网统计信息。此选项可以与 -s 选项组合使用。 -n 以数字形式显示地址和端口号。 -o 显示与每个连接相关的所属进程 ID。 -p proto 显示 proto 指定的协议的连接proto 可以是 下列协议之一: TCP、UDP、TCPv6 或 UDPv6。 如果与 -s 选项一起使用以显示按协议统计信息,proto 可以是下列协议之一: IP、IPv6、ICMP、ICMPv6、TCP、TCPv6、UDP 或 UDPv6。 -r 显示路由表。 -s 显示按协议统计信息。默认地,显示 IP、 IPv6、ICMP、ICMPv6、TCP、TCPv6、UDP 和 UDPv6 的统计信息-p 选项用于指定默认情况的子集。 -v 与 -b 选项一起使用时将显示包含于 为所有可执行组件创建连接或监听端口的 组件。 interval 重新显示选定统计信息,每次显示之间 暂停时间间隔(以秒计)。按 CTRL+C 停止重新 显示统计信息。如果省略,netstat 显示当前 配置信息(只显示一次) (Win2000) C:\>netstat /? Displays protocol statistics and current TCP/IP network connections. NETSTAT [-a] [-e] [-n] [-s] [-p proto] [-r] [interval] -a Displays all connections and listening ports. -e Displays Ethernet statistics. This may be combined with the -s option. -n Displays addresses and port numbers in numerical form. -p proto Shows connections for the protocol specified by protoproto may be TCP or UDP. If used with the -s option to display per-protocol statistics, proto may be TCP, UDP, or IP. -r Displays the routing table. -s Displays per-protocol statistics. By default, statistics are shown for TCP, UDP and IPthe -p option may be used to specify a subset of the default. interval Redisplays selected statistics, pausing interval seconds between each display. Press CTRL+C to stop redisplaying statistics. If omitted, netstat will print the current configuration information once. Netstat的一些常用选项 netstat -s——本选项能够按照各个协议分别显示其统计数据。如果你的应用程序(如Web浏览器)运行速度比较慢,或者不能显示Web页之类的数据,那么你就可以用本选项来查看一下所显示的信息。你需要仔细查看统计数据的各行,找到出错的关键字,进而确定问题所在。 netstat -e——本选项用于显示关于以太网的统计数据。它列出的项目包括传送的数据报的总字节数、错误数、删除数、数据报的数量和广播的数量。这些统计数据既有发送的数据报数量,也有接收的数据报数量。这个选项可以用来统计一些基本的网络流量。 netstat -r——本选项可以显示关于路由表的信息,类似于后面所讲使用route print命令时看到的 信息。除了显示有效路由外,还显示当前有效的连接。 netstat -a——本选项显示一个所有的有效连接信息列表,包括已建立的连接(ESTABLISHED),也包括监听连接请求(LISTENING)的那些连接,断开连接(CLOSE_WAIT)或者处于联机等待状态的(TIME_WAIT)等 netstat -n——显示所有已建立的有效连接。 接下来我们来看一下,微软是怎么说的? 微软公司故意将这个功能强大的命令隐藏起来是因为它对于普通用户来说有些复杂。我们已经知道:Netstat它可以用来获得你的系统网络连接的信息(使用的端口,在使用的协议等 ),收到和发出的数据,被连接的远程系统的端口,Netstat在内存中读取所有的网络信息。 在Internet RFC标准中,Netstat的定义是: Netstat是在内核中访问网络及相关信息的程序,它能提供TCP连接,TCP和UDP监听,进程内存管理的相关报告。 看其中有个localaddress 和一个foreignaddress如果没打开任何网络连接,却有established说明就有问题,注意,你得保证没有你开的任何的网络连接,包括后台进程,如果还是有established说明才有问题。
在开发网络服务器应用系统的时候,有时会碰到服务器有大量的socket处于CLOSE_WAIT状态,也无法关闭,导致服务器无法接受新的用户请求,最终导致服务器奔溃,系统重启才能解决。
为什么会出现大量的CLOSE_WAIT状态呢?
要解决这个问题,我们得先介绍一下socket断开过程中的四次挥手。
由于TCP连接是全双工的,因此每个方向都必须单独进行关闭。
假设终止命令由client端发起。
当clien端传输完成数据,或者需要断开连接时:
两个基本问题:
至此似乎明白了为什么会出现CLOSE_WAIT的状态:如果Server端一直没有向client端发送FIN消息(调用close() API),那么这个CLOSE_WAIT会一直存在下去。
从上面我们看到出现CLOSE_WAIT,说明Server端没有发起close() *** 作,这基本上是用户server端程序的问题了;通常情况下,Server都是等待Client访问,如果Client退出请求关闭连接,server端自觉close()对应的连接。
当然这也可能是业务实现上的需要,暂时不发送FIN,因为服务器可能还有数据要发往客户端,等发送完所有应用数据最后再发送FIN消息了;这个场景并不是这里我们讨论的大量COLSE_WAIT的问题了,因为这个还是可控的。
我们要讨论的场景是什么?我们先介绍两个系统调用,前面也提到并且用到的close(socket)和shutdown(socket,HOW)接着往下分析。
我们知道一个进程打开一个socket,然后此进程fork出子进程的时候,父进程已打开的socket是会被继承的,即子进程能够继续访问这个socket。其结果就是,一个socket被两个进程打开,一个父进程和一个子进程,此时socket的引用计数会变成2。
据此分析,很大可能性是用户服务器的程序实现有问题导致的大量CLOSE_WAIT的socket,比如父进程打开了socket,然后通过fork出子进程来处理业务,父进程继续对网络请求进行监听,永远不会终止;当客户端发FIN过来的时候,处理业务的子进程处理此FIN消息,调用close()对本端进行关闭,然而这个close()调用只是把socket的引用计数器减1,因为父进程还在运行,socket并没关闭,这样就导致系统中又多了一个CLOSE_WAIT的socket,长此以往,就这样了。
多说两句关于TIME_WAIT的状态,这个发生在client端,而且是不可避免的,其时间长度是固定的2MSL,到期自动转为CLOSED,不会导致系统资源耗尽的问题。
MSL是一个系统级参数,可调。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)