主页 / server / 问题 / 23385
Accepted
KTamas
Asked: 2009-06-11 06:35:35 +0800 CST

大量的 TIME_WAIT 连接说 netstat

  • 772

好的，这让我毛骨悚然——我看到了大约 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   -
linux networking debian tcpip netstat

6 个回答

  1. Best Answer

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

    正如其他人所提到的，有一些连接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
    • 29

  2. TIME_WAIT 是正常的。这是套接字关闭后的一种状态，内核使用它来跟踪可能丢失并迟到的数据包。大量 TIME_WAIT 连接是获得大量短期连接的症状，不必担心。

    • 27

  3. 这不重要。这意味着您正在打开和关闭大量 Sun RCP TCP 连接（每 2-4 分钟有 1500-2500 个连接）。状态是套接字在关闭时进入的TIME_WAIT状态，以防止消息到达错误的应用程序，就像套接字重用过快时可能发生的那样，以及用于其他几个有用的目的。别担心。

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

    • 6

  4. 您系统上的某些东西正在您的系统中执行大量 RPC（远程过程调用）（注意源和目标都是 localhost）。这在 NFS 挂载的 lockd 中很常见，但您也可能在其他 RPC 调用（如 rpc.statd 或 rpc.spray）中看到它。

    您可以尝试使用“lsof -i”来查看谁打开了这些套接字并查看它在做什么。它可能是无害的。

    • 4

  5. tcp_fin_timeout不控制TIME_WAIT延迟。您可以通过使用带有 -o 的 ss 或 netstat 来查看倒数计时器：

    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 中不会有任何可能的冲突段编号。

    • 4

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

    现在发生的情况如下：默认情况下，查找函数还尝试联系 ypbind 守护进程（Sun Yellow Pages，也称为 NIS）以查询主机名。要查询此服务，必须联系 portmapper 端口映射以获取此服务的端口。现在我的端口映射器通过 TCP 联系上了。然后端口映射器告诉 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
    • 3

相关问题