我知道将 tcp_max_tw_buckets 设置为一个相对较小的数字（例如 30000 或 50000）是很正常的，以避免主机有大量时间等待状态连接而应用程序无法打开新连接的情况。这是很多提到的东西。比如这样的问题：How to reduce number of sockets in TIME_WAIT?
正如我之前知道的那样，time-wait 是一种避免 TCP 数据包out of order 的状态，使用some other approach 来应对它可能会更好。如果你把它设置为一个小数字，事情可能会出错。
我觉得我卡在某个地方，我必须将 tcp_max_tw_buckets 设置为一个很小的数字，并且不知道我应该避免它的具体场景。
所以我的问题是将 tcp_max_tw_buckets 设置为非常小的值有什么副作用，我可以使用实验室环境设置一个特定的场景，少量的 tcp_max_tw_buckets 会导致麻烦吗？
【问题讨论】：
标签： linux sockets networking tcp
正如您在this Kernel source 中看到的那样，该选项可防止套接字正常终止。就套接字状态而言，您已将此连接的等待时间减少到零。
那么接下来会发生什么？首先，您会在服务器上看到错误消息。剩下的就是来自您的客户端的后续连接的竞争条件。 rfc 1337 的第 2 部分随后介绍了您可能会看到的内容。简而言之，某些连接可能会出现以下症状。
但是，证明这一点可能很困难。如同一 RFC 中所述：
三个危害 H1、H2 和 H3 已在一个股票 Sun OS 4.1.1 TCP 上进行了演示，该 TCP 在模拟环境中大量复制段。这种环境比大多数真正的 TCP 必须应对的危险要大得多，并且对条件进行了仔细调整，以为失败创造必要条件。
【讨论】：
您的问题的真正答案是，避免 TIME_WAIT 状态的正确方法是成为接收第一个关闭的结束。
在服务器的情况下，这意味着在您发送响应后，您应该循环等待同一个套接字上的另一个请求，当然读取超时，因此通常是客户端将关闭第一的。这样 TIME_WAIT 状态出现在客户端，它是相当无害的，因为客户端没有大量的出站连接。
【讨论】：
Connection: close引用rfc2616 section 14.10 Connection，使用该header客户端可以释放本地打开的端口，减少time-wait状态的连接数。我理解你的建议是最终的解决方案，但由于资源和时间有限，我不得不忍受这种情况很长时间，所以我真的需要直接回答我的问题。
Connection: close，暂时不会更改。