首页 文章

设置TIME_WAIT TCP

提问于
浏览 次
63

我们正在尝试调整通过TCP接受消息的应用程序，并使用TCP进行一些内部消息传递 . 在进行负载测试时，我们注意到响应时间显着降低（然后完全停止），因为对系统进行了更多的同时请求 . 在此期间，我们看到很多TCP连接处于 TIME_WAIT 状态，有人建议将 TIME_WAIT 环境变量从默认的60秒降低到30 .

从what I understand开始， TIME_WAIT 设置实质上设置在关闭连接后TCP资源再次可供系统使用的时间 .

我不是一个“网络人”，对这些事情知之甚少 . 我需要很多联系帖子中的内容，但是“笨拙”了一下 .

  • 我想我明白为什么 TIME_WAIT 值不能设置为0，但可以安全地设置为5吗？ 10岁呢？是什么决定了这个值的"safe"设置？

  • 为什么此值为60的默认值？我猜想比我聪明的人有充分的理由选择这个作为合理的默认值 .

  • 我还应该了解覆盖这一 Value 的潜在风险和好处？

tcp network-protocols

7 回答

  • 3

    TCP连接由元组指定（源IP，源端口，目标IP，目标端口） .

    在会话关闭之后存在TIME_WAIT状态的原因是因为在你去往你的路上（或者你可能会请求某种响应），网络中可能仍有实时数据包输出 . 如果你要重新创建相同的元组并且其中一个数据包出现，它将被视为连接的有效数据包（并且可能由于排序而导致错误） .

    因此，TIME_WAIT时间通常设置为数据包最大年龄的两倍 . 此值是在网络丢弃数据包之前允许的数据包的最大年龄 .

    这保证了，在允许您创建与同一元组的连接之前，属于该元组的先前化身的所有数据包将会死亡 .

    这通常决定了你应该使用的最小值 . 最大数据包年龄由网络属性决定，一个例子是卫星寿命高于LAN生存期，因为数据包还有很长的路要走 .

    回复于
  • 90

    通常，只有发出“主动关闭”的 endpoints 才会进入TIME_WAIT状态 . 因此，如果可能，请让您的客户端发出活动关闭，这将使TIME_WAIT保留在客户端而不是服务器上 .

    有关详细信息，请参见此处：http://www.serverframework.com/asynchronousevents/2011/01/time-wait-and-its-design-implications-for-protocols-and-scalable-servers.html和http://www.isi.edu/touch/pubs/infocomm99/infocomm99-web/（后面也解释了为什么考虑到TIME_WAIT） .

    回复于
  • 9

    Pax对于TIME_WAIT的原因是正确的，以及为什么要注意降低默认设置 .

    更好的解决方案是改变用于套接字始发端的端口号 . 一旦你这样做，你就不会真正关心等待个别套接字的时间 .

    对于侦听套接字，尽管有TIME_WAIT套接字，但您可以使用SO_REUSEADDR来允许侦听套接字绑定 .

    回复于
  • -1

    在Windows中，您can change it through the registry：

    ; Set the TIME_WAIT delay to 30 seconds (0x1E)

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TCPIP\Parameters]
"TcpTimedWaitDelay"=dword:0000001E
    回复于
  • 2

    设置tcp_reuse比更改time_wait更有用，只要你有参数（内核3.2及更高版本，遗憾的是取消所有版本的RHEL和XenServer） .

    丢弃该值（特别是对于VPN连接的用户）可能导致在出站连接上不断重新创建代理隧道 . 使用默认的Netscaler（XenServer）配置（低于默认的Linux配置），Chrome有时必须重新创建代理隧道十几次以检索一个网页 . 不重试的应用程序（例如Maven和Eclipse P2）就会失败 .

    参数的原始动机（避免重复）由TCP RFC指定为冗余，该RFC指定所有TCP请求中包含时间戳 .

    回复于
  • 0

    我一直在使用带有20个线程的测试程序来加载测试服务器应用程序（在linux上） .

    在959,000个连接/关闭周期中，我在TIME_WAIT中有44,000个连接失败和数千个套接字 .

    我在关闭调用之前将SO_LINGER设置为0，并且在测试程序的后续运行中没有连接失败，并且在TIME_WAIT中没有少于20个套接字 .

    回复于
  • 19

    TIME_WAIT可能不是罪魁祸首 .

    int listen(int sockfd, int backlog);

    根据Unix网络编程卷1，积压被定义为已完成连接队列和未完成连接队列的总和 .

    假设积压为5 . 如果您有3个已完成的连接（ESTABLISHED状态）和2个未完成的连接（SYN_RCVD状态），则还有另一个带SYN的连接请求 . TCP堆栈只是忽略了SYN数据包，知道它将在其他时间重新传输 . 这可能会导致退化 .

    至少那是我一直在读的东西 . ;）

    回复于

相关问题