问题标签 [time-wait]

For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.

0 投票
1 回答
10263 浏览

http - Go 客户端程序生成大量处于 TIME_WAIT 状态的套接字

我有一个 Go 程序,它从多个 goroutine 生成大量 HTTP 请求。运行一段时间后,程序吐出错误:连接:无法分配请求的地址。

与 检查时netstat,我在 中获得大量 (28229) 连接TIME_WAIT

TIME_WAIT当我的 goroutines 的数量为 3 时,会发生大量套接字,并且当它为 5 时严重到足以导致崩溃。

我在 docker 下运行 Ubuntu 14.4 并运行 1.7 版

这是围棋程序。

这是服务器程序:

0 投票
0 回答
116 浏览

port - Logstash 在通过 UDP 514 捕获 syslog 时打开数千个端口

我最近开始使用 Logstash 从默认的 UDP 514 端口捕获系统日志数据。该程序正确运行并为我提供了我正在寻找的数据,但是,在运行时查看 netstat 时,它会打开服务器上的数千个端口并将它们留在 TIME_WAIT 状态。这很奇怪。我在网上查过,但没有找到对此的解释。

另一个有趣的地方是,所有这些端口似乎都是由 Windows 内核 PID 0 打开的,但实际上它们确实对应于 Logstash 进程,因为它们只在运行时出现,并在关闭 Logstash 后几分钟消失。

所以我的问题是,为什么会发生这种情况,如何防止 Logstash 打开所有这些端口?

我在 Logstash 运行时包含了 Netstat 输出的屏幕截图,以及下面的配置文件。

在此处输入图像描述

0 投票
1 回答
459 浏览

sockets - 在 localhost 上打开 ServerSocket 并立即关闭会导致 TIME_WAIT?

我在其中一个 java 库中看到以下逻辑来测试本地主机上套接字的打开:

我的问题是,当没有发送数据包并且套接字在打开后立即关闭时,这个套接字会导致本地主机上的 TIME_WAIT 状态吗?在这种情况下,如果应用程序尝试绑定到同一端口,如果在 2MSL 值内完成,是否会导致“地址已在使用错误”?

我写了一个像上面这样的小测试程序,但是当我在运行这个程序的 linux 机器上 netstat 或 ss 时,我根本看不到这个端口的 TIME_WAIT。即使没有使用套接字发送任何数据包,状态机也不应该应用吗?

0 投票
1 回答
1223 浏览

sockets - PhpStorm FTP 425 无法建立数据连接:无法分配请求的地址

PhpStorm FTP 上传失败。

我的 PhpStorm 在深度系统(Linux)上运行

我尝试更改端口数,但仍然无法上传。谁能帮我 ?

0 投票
1 回答
311 浏览

sockets - 为什么 SCTP 不需要 TIME_WAIT 状态?

我正在阅读“UNIX 网络编程:套接字 API”,它提到 SCTP 不需要像 TCP 那样的 TIME_WAIT 状态,因为它使用了验证标签。为什么会这样?我理解为什么验证标签解决了重复数据包的问题,​​因为接收者可以确定数据包是否是当前 SCTP 关联的一部分,但最终的 SCTP SHUTDOWN-COMPLETE 数据包肯定会丢失,就像 TCP 中的最终 ACK 一样丢失,因此执行主动关闭的对等方仍然必须保持某种状态来处理此事件,就像使用 TCP 一样。

0 投票
1 回答
741 浏览

linux - TIME_WAIT 状态占用的套接字

我可以使用“netstat -an cmd”在端口 9180 上看到 TIME_WAIT,而使用“lsof -i:9180”什么也看不到。

我的应用程序无法启动并报告套接字已被占用。

0 投票
1 回答
334 浏览

linux - Linux 上的 TIME_WAIT 和 EADDRINUSE

我有一个系统,其中在后台运行的服务器进程由控制程序控制。

控制程序是一个简单的脚本,它执行一个命令然后退出。对于 Run 命令,它会创建一个新的服务器进程;对于其他人(包括关机),它通过保留的控制端口将命令发送到服务器。

控制程序创建一个套接字,连接到服务器的控制端口,发送一个字符的数据(一个命令),从套接字读取答复,关闭套接字,向用户显示答复并退出。服务器接受控制套接字上的连接,读取数据字符,发送回复,关闭子套接字并继续侦听。当服务器关闭时,它也会关闭父控制套接字。

这已经在 Windows XP / Python 2.6.6 上运行了很多年。最近我们尝试移植到 Linux(Ubuntu 16.04.2 GNU/Linux 4.4.0-62-generic x86_64 / Python 2.7.12),但是重启命令(立即关机后运行)失败:当新的服务器进程尝试要将控制套接字绑定到控制端口,它会获取 EADDRINUSE。

netstat 的输出显示用于 Shutdown 命令的连接保持在 TIME_WAIT 状态,并持续了大约两分钟。

我已经查看了有关此主题的先前帖子。我尝试在服务器的控制套接字上设置 SO_REUSEADDR 和/或 SO_REUSEPORT。我已经尝试增强服务器和控制程序之间的协议,以确保控制程序首先关闭它的连接端,但到目前为止我还没有找到有效的组合。我想知道是否有任何解决方案。

鉴于服务器和控制程序都运行在同一台机器上,连接双方的详细信息将在操作系统的状态表中,并且必须在 TIME_WAIT 中保留一个或另一个。

控制程序的条目是否会阻止服务器绑定到端口?

我注意到在 Windows 上也有一个连接处于 TIME_WAIT 状态,但在 Windows 上不会阻止新的服务器进程绑定到同一个控制端口。

0 投票
1 回答
96 浏览

linux - 随机端口发起 TCP 请求

随机端口在centos 6.8上的两个服务器程序之间发起TCP请求。

一些 TIME_WAIT 总是存在,我不明白为什么。

53349和53391端口,TCP请求从哪里开始?请帮忙。

0 投票
1 回答
197 浏览

windows - 在哪些版本的 Windows(如果有)上,SO_EXCLUSIVEADDRUSE 可以防止重新绑定具有剩余连接的端口?

在 Windows 上考虑以下情况:

  1. 监听套接字 1SO_EXCLUSIVEADDRUSE设置了选项,并绑定到端口
  2. 侦听套接字 1 接收传入连接,它接受该连接以创建连接的套接字
  3. 监听套接字 1 已关闭,但连接的套接字保持打开状态(在某种意义上,可能是 ESTABLISHED 或 TIME_WAIT)
  4. 监听套接字 2SO_EXCLUSIVEADDRUSE设置了选项,并尝试绑定到与第一个监听套接字相同的端口。它成功了吗?

网上没有大量关于此的信息,但大多数人同意在最后一步中,bind总是会引发错误,因为SO_EXCLUSIVEADDRUSE阻止监听套接字 2 和连接的套接字共享端口。这很重要,因为SO_EXCLUSIVEADDRUSE它提供了一些重要的安全优势,但如果它破坏了端口重新绑定,那么就很难决定是否使用它。

当前的MSDN 文档清楚地表明,至少在某些情况下,一个挥之不去的连接可能会使第二个连接bind失败,尽管他们对究竟什么是“活动连接”含糊不清:

相反,设置了 SO_EXCLUSIVEADDRUSE 的套接字不一定能在套接字关闭后立即重用。例如,如果一个设置了 SO_EXCLUSIVEADDRUSE 的侦听套接字接受了一个连接,然后随后被关闭,则另一个套接字(也具有 SO_EXCLUSIVEADDRUSE)不能绑定到与第一个套接字相同的端口,直到原始连接变为非活动状态。

libuv 明确选择不使用SO_EXCLUSIVEADDRUSE——尽管有安全优势——因为他们说它会干扰TIME_WAIT处理

这篇 microsoft.com 2005 年的博客文章提供了更多细节,声称连接的套接字SO_EXCLUSIVEADDRUSE至少在某些情况下可以防止重新绑定(尽管不是TIME_WAIT):

虽然 SO_EXCLUSIVEADDRUSE 选项非常有用,但有一个重要的警告。如果至少有一个源自或被绑定到独占访问的端口上的连接处于活动状态,则所有与该端口的绑定都将失败。在这种情况下,“连接”定义为通过 connect、WSAConnect 或 ConnectEx 显式连接到对等点的套接字,其中设置了独占标志或从侦听套接字返回的连接(例如从接受、WSAAccept 或 AcceptEx ) 具有独占选项集(在侦听套接字上)。TCP 的活动端口定义为 ESTABLISHED、FIN_WAIT、FIN_WAIT_2 或 LAST_ACK 状态

所以我写了一个小脚本来为自己尝试:

https://gist.github.com/njsmith/8770bed5bbf2154940e8e3e7762e4ac3

事实上,当我在 Windows 10 上运行它时,我得到:

所以我的初步结论是 MSDN 和其他所有人都错了:只要原始侦听套接字关闭,SO_EXCLUSIVEADDRUSE实际上确实允许重新绑定一个端口,该端口具有与之关联的剩余连接套接字,无论是处于 ESTABLISHED 还是 TIME_WAIT 状态或什么状态。这是每个人都想要的,所以这很好。大概这在 2005 年不是真的,但从那时到现在,他们修复了它。

问题:

  • 我对这些结果的解释是否正确?
  • 是否还有另一种情况我错过了以前的连接可能导致SO_EXCLUSIVEADDRUSE bind常规连接失败的bind情况?(我希望如果 ESTABLISHED 套接字不会引起问题,那么什么都不会,但我可能会遗漏一些东西。)
  • 最重要的是:他们什么时候做出改变的?例如,我在 Windows 10 上进行了测试,但如果我的代码出于某种原因需要针对 Windows Vista,这是否可行?还是它总是这样工作并且文档总是错误的?
0 投票
1 回答
775 浏览

go - 使用 redigo 池时并发后的 TIME_WAIT 过多

我将 github.com/garyburd/redigo 用于我的应用程序 go 例程,同时读取和写入 Redis。我在 Singleton Pattern 中使用 redigo NewRedisClient(),并设置 MAXACTIVE=100, MAXIDLE=100, IDLETIMEOUT=60。

应用程序启动了,我发现 Redis 服务器有很多 TIME_WAIT 增长。喜欢:

而且我每次 pool.Get() 时都会打印活动计数和空闲计数,它显示:

为什么有这么多 TIME_WAIT ?我是否泄漏了一些连接?