netstat表示有大量TIME

28

好的，这使我无所适从-我看到其中大约1500-2500：

root@wherever:# 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...]

root@wherever:# 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   -

— 塔玛斯
source

1

您是否在导出NFS的同一台计算机上安装了NFS？

— Paul Tomblin，2009年

@保罗汤布林：号

— KTamas

1

好吧，您应该查看“已建立的连接”以找出它是哪个程序。“ rcpinfo -p”还可以帮助找出与portmapper通信的内容。

— cstamas

对于那些在尝试找到一种方法来调整Windows下的延迟的方法时，可以通过注册表设置来完成。

— Synetech

22

编辑： tcp_fin_timeout 不控制TIME_WAIT持续时间，它在60s时被硬编码

正如其他人提到的那样，建立一些连接TIME_WAIT是TCP连接的正常部分。您可以通过检查/proc/sys/net/ipv4/tcp_fin_timeout以下内容来查看时间间隔：

[root@host ~]# cat /proc/sys/net/ipv4/tcp_fin_timeout
60

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

[root@dev 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

— 布兰登
source

是的，我的ipconfig脚本已经将其降低到30。我在/etc/init.d/中没有nfsd，但是我确实正在运行portmap，将其停止，现在TIME_WAIT下降到了几个实例（1-5）。谢谢。

— KTamas，2009年

18

嗯，tcp_fin_timeout与处于time_wait状态的套接字无关。这会影响fin_wait_2。

— diq

2

为diq的评论+1。他们没有关系。

— mcauth 2014年

1

正确...即使使用以下命令更改了tcp_fin_timeout，您也可以看到套接字从60开始递减：ss --numeric -o state time-wait dst 10.0.0.100

— Greg Bray

16

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

— 大卫·帕什利
source

这个答案简短而甜蜜。这很有帮助。最后一句话让我有些困惑，但是我想说的是，您需要了解为什么要创建这么多连接。如果要编写一个生成大量请求的客户端，则可能要确保将其配置为重用现有连接，而不是为每个请求创建新连接。

— nobar

短汗，不完整。TIME_WAIT取决于上下文。如果其中有很多，则可能是有人在攻击您的服务器。

— MindaugasBernatavičius15

5

不重要这说明您正在打开和关闭许多Sun RCP TCP连接（每2-4分钟1500至2500个）。TIME_WAIT状态是套接字在关闭时所处的状态，以防止消息到达错误的应用程序，就像套接字重新使用太快时可能会发生的情况一样，并用于其他一些有用的目的。不用担心

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

— 混沌
source

我主要运行courier-imap和postfix。

— KTamas，2009年

4

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

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

— 保罗·汤姆林
source

那里没什么异常，我确实看到了用于端口映射的TCP *：sunrpc（LISTEN），但猜测是正常的。

— KTamas，2009年

重复进行此操作，直到看到谁在打开连接。

— Paul Tomblin，2009年

netstat -epn --tcp将显示相同的信息。除非您使用NFS，否则可能没有什么理由使用portmap。您可以删除它。

— David Pashley 2009年

我确实没有使用NFS，但是apt-get remove portmap想要删除“ fam”，它可能是由courier-imap安装的libfam0自动安装的。apt-cache说'fam'是libfam0的推荐软件包。

— KTamas

2

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），则内核可以在TIME_WAIT中重用套接字，前提是它确定TCP中不会存在任何可能的冲突。段编号。

— 格雷格·布雷
source

1

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

现在发生了以下情况：默认情况下，查找功能还尝试联系ypbind守护程序（Sun Yellow Pages，也称为NIS）来查询主机名。要查询此服务，必须联系portmapper端口映射以获取该服务的端口。现在在我的情况下，通过TCP与portmapper进行了联系。然后，端口映射程序告诉libc函数不存在此类服务，并且TCP连接被关闭。众所周知，关闭的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

— 里彻
source

netstat表示有大量TIME_WAIT连接