好吧，这正在爬我 – 我看到这些约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 这个数字正在迅速变化。
我有一个非常紧密的iptablesconfiguration，所以我不知道是什么原因造成的。 有任何想法吗？
谢谢，
塔马斯
编辑：'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 -
正如其他人所说，在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，则可以closures它：
/etc/init.d/nfsd stop
完全closures它
chkconfig nfsd off
TIME_WAIT是正常的。 这是一个closures套接字之后的状态，由内核用来跟踪可能已经丢失并晚到晚会的数据包。 大量的TIME_WAIT连接是获得大量短暂连接的症状，而不是担心。
你系统上的某些东西正在你的系统中做很多RPC（远程过程调用）（注意源和目的地都是本地主机）。 这通常被认为是lockingNFS挂载，但是你也可以看到它的其他RPC调用，如rpc.statd或rpc.spray。
您可以尝试使用“lsof -i”来查看谁打开了这些套接字并查看正在执行的操作。 这可能是无害的。
这并不重要。 所有这一切意味着您正在打开和closures大量Sun RCP TCP连接（每2-4分钟有1500-2500个连接）。 TIME_WAIT状态是套接字在closures时进入的状态，以防止消息到达错误的应用程序，就像套接字被重复使用得太快一样，以及其他一些有用的目的。 别担心。
（当然，除非你真的没有运行任何应该处理许多RCP操作的东西，那么，担心。）
我也有同样的问题。 我花了几个小时才知道发生了什么事情。 在我的情况下，这是因为netstat试图查找对应于IP的主机名（我假设它使用gethostbyaddr API）。 我正在使用没有/etc/nsswitch.conf的embedded式Linux安装。 令我惊讶的是，这个问题只存在于你正在做一个netstat -a（通过在详细和debugging模式下运行portmap来发现这个问题）。
现在发生的事情如下：默认情况下，查找函数也尝试联系ypbind守护进程（Sun Yellow Pages，也称为NIS）来查询主机名。 要查询此服务，必须联系portmapper portmap以获取此服务的端口。 现在我的案例中的端口映射程序通过TCP进行联系。 portmapper然后告诉libc函数不存在这样的服务，并且TCP连接被closures。 正如我们所知，封闭的TCP连接在一段时间内进入TIME_WAIT状态。 所以netstat在列表中捕获这个连接，并且这个带有新IP的新行发出一个新的请求，在TIME_WAIT状态下产生一个新的连接，等等。
为了解决这个问题，创build一个不使用rpc NIS服务的/etc/nsswitch.conf，即以下内容：
passwd: files group: files hosts: files dns networks: files dns services: files protocols: files netmasks: files