it-swarm.cn

netstat表示有大量TIME_WAIT连接

好的,这让我无所适从-我看到其中的1500-2500:

[email protected]:# netstat

Proto Recv-Q Send-Q Local Address           Foreign Address         State      
tcp        0      0 localhost:60930         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60934         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60941         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60947         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60962         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60969         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60998         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60802         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60823         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60876         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60886         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60898         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60897         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60905         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60918         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60921         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60673         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60680         localhost:sunrpc        TIME_WAIT  
[etc...]

[email protected]:# netstat | grep 'TIME_WAIT' |wc -l
1942

这个数字正在迅速变化。

我确实有一个非常严格的iptables配置,所以我不知道是什么原因引起的。有任何想法吗?

谢谢,

塔马斯

编辑:'netstat -anp'的输出:

Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 127.0.0.1:60968         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60972         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60976         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60981         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60980         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60983         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60999         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60809         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60834         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60872         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60896         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60919         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60710         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60745         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60765         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60772         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60558         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60564         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60600         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60624         127.0.0.1:111           TIME_WAIT   -               
28
KTamas

编辑: tcp_fin_timeout 不做控制TIME_WAIT持续时间,它在60s时被硬编码

正如其他人所提到的,在TIME_WAIT是TCP连接的正常部分。您可以通过检查/proc/sys/net/ipv4/tcp_fin_timeout

[[email protected] ~]# cat /proc/sys/net/ipv4/tcp_fin_timeout
60

并通过修改该值来更改它:

[[email protected] admin]# echo 30 > /proc/sys/net/ipv4/tcp_fin_timeout

或通过将其永久添加到/etc/sysctl.conf中

net.ipv4.tcp_fin_timeout=30

另外,如果您不使用RPC服务或NFS,则可以将其关闭:

/etc/init.d/nfsd stop

然后完全关闭

chkconfig nfsd off
22
Brandon

TIME_WAIT是正常的。这是套接字关闭后的状态,内核使用它来跟踪可能丢失的数据包,并在晚些时候出现。大量的TIME_WAIT连接是出现许多短暂连接的征兆,这没什么好担心的。

16
David Pashley

不重要这表明您正在打开和关闭许多Sun RCP TCP连接(每2-4分钟1500至2500个连接)。TIME_WAIT状态是socket会在关闭时进入,以防止错误的应用程序收到消息,就像套接字重用太快一样,还有其他一些有用的目的。

(当然,除非您实际上并没有运行任何应处理这么多RCP操作的东西,否则请担心。)

5
chaos

系统上的某件事正在系统内执行很多RPC(远程过程调用)(请注意,源和目标均为localhost)。对于NFS挂载,通常在lockd中会看到这种情况,但是对于其他RPC调用(例如rpc.statd或rpc.spray),也可能会看到这种情况。

您可以尝试使用“ lsof -i”来查看谁打开了这些套接字,并查看其作用。这可能是无害的。

4
Paul Tomblin

tcp_fin_timeout不控制TIME_WAIT延迟。您可以通过将ss或netstat与-o一起使用来查看倒数计时器,从而看到以下内容:

cat /proc/sys/net/ipv4/tcp_fin_timeout
3

# See countdown timer for all TIME_WAIT sockets in 192.168.0.0-255
ss --numeric -o state time-wait dst 192.168.0.0/24

NetidRecv-Q  Send-Q    Local Address:Port    Peer Address:Port                             
tcp  0       0         192.168.100.1:57516   192.168.0.10:80    timer:(timewait,55sec,0)   
tcp  0       0         192.168.100.1:57356   192.168.0.10:80    timer:(timewait,25sec,0)   
tcp  0       0         192.168.100.1:57334   192.168.0.10:80    timer:(timewait,22sec,0)   
tcp  0       0         192.168.100.1:57282   192.168.0.10:80    timer:(timewait,12sec,0)   
tcp  0       0         192.168.100.1:57418   192.168.0.10:80    timer:(timewait,38sec,0)   
tcp  0       0         192.168.100.1:57458   192.168.0.10:80    timer:(timewait,46sec,0)   
tcp  0       0         192.168.100.1:57252   192.168.0.10:80    timer:(timewait,7.436ms,0) 
tcp  0       0         192.168.100.1:57244   192.168.0.10:80    timer:(timewait,6.536ms,0)

即使将tcp_fin_timeout设置为3,TIME_WAIT的倒数计时仍从60开始。但是,如果将net.ipv4.tcp_tw_reuse设置为1(echo 1 > /proc/sys/net/ipv4/tcp_tw_reuse)然后,如果内核确定TCP段编号)中不会存在任何冲突,则内核可以在TIME_WAIT中重用套接字。

2
Greg Bray

我也有同样的问题。我花了几个小时来找出正在发生的事情。就我而言,原因是netstat尝试查找与IP对应的主机名(我假设它使用的是gethostbyaddr API)。我正在使用没有/etc/nsswitch.conf的嵌入式Linux安装。令我惊讶的是,该问题仅在您实际执行netstat -a时存在(通过在详细模式和调试模式下运行portmap可以发现此问题)。

现在发生了以下情况:默认情况下,查找功能还尝试联系ypbind守护程序(Sun Yellow Pages,也称为NIS)来查询主机名。要查询此服务,必须联系portmapper端口映射以获取该服务的端口。现在在我的情况下,通过TCP与portmapper进行了联系。然后,端口映射程序告诉libc函数,不存在这样的服务,并且TCP连接被关闭。众所周知,closed TCP连接进入某些状态的TIME_WAIT状态因此,netstat会在列出时捕获此连接,并且此具有新IP的新行会发出新请求,该请求会生成处于TIME_WAIT状态的新连接,依此类推...

为了解决此问题,请创建一个不使用rpc NIS服务的/etc/nsswitch.conf文件,即具有以下内容:

passwd:         files
group:          files
hosts:          files dns
networks:       files dns
services:       files
protocols:      files
netmasks:       files
1
leecher