tcp TIME-WAIT的实际好处以及在生产环境中的影响
一些理论
我已经在tcp TIME-WAIT （ 这里和那里 ）读了一些东西，我读到的是一个设置为2 x MSL （最大段寿命）的值，它在“连接表”中保持连接一段时间保证“在你允许创build与同一个元组的连接之前，所有属于该元组以前化身的数据包都将被删除” 。
由于在连接处于TIME-WAIT或不再存在的情况下，收到的段（除了特定情况下的SYN）将被丢弃，为什么不立即closures连接呢？
Q1：这是否是因为在TIME-WAIT （即有性能优势）时处理旧连接中的段所涉及的处理较less而处理较less以在同一元组上创build新连接？
- 在小型私人networking上encryptionLAN和wifistream量
- 安装Solaris 11，没有更新？
- 防止用户删除SQL数据
- 我还能做些什么来保护我的Linux服务器？
- b / w MMC.exe和certmgr.msc有什么区别
如果上面的解释不成立，我看到TIME-WAIT有用的唯一原因是如果一个客户发送一个连接的SYN ，然后它为同一个元组上的旧连接发送剩余的段，在这种情况下，接收者将重新打开连接，但得到坏段，并将不得不终止它。
Q2：这个分析是否正确？
问题3：使用TIME-WAIT还有其他好处吗？
一些实践
我一直在查看我pipe理的生产服务器上的munin图表。 这里是一个： 
正如你所看到的， TIME-WAIT与ESTABLISHED有更多的连接，大部分时间是其中的两倍，在有些情况下是四倍。
问题4：这是否对性能有影响？
问题5：如果是这样，是否明智/build议减lessTIME-WAIT值（以及什么）？
Q6：这个TIME-WAIT / ESTABLISHED连接的比例是正常的吗？ 这可能与恶意连接尝试有关吗？
总之，不要担心TIME_WAIT 。 开销几乎没有，通常没有问题。
在繁忙的服务器上，端口耗尽是可能的，在这种情况下， net.ipv4.tcp_tw_reuse = 1的sysctl选项允许内核根据需要重新使用仍在TIME_WAIT旧端口。
TIME_WAIT是TCP规范的一部分，可以捕获可能仍然在传输中的数据包（请记住，并非所有的连接都是可靠的，而这正是TCP旨在解决的问题）。 对于大多数现代用途，超时值可能非常高，但通常不会干扰除netstat输出以外的其他任何内容。
如果你自己控制套接字，而且确定你没有等待数据（例如你是最终的发送者，或者你不关心响应），你可以在设置SO_NOLINGER选项后closures套接字，这将终止与RST的连接，并立即丢弃该套接字。
所以你的问题：
Q1，Q2，Q3：这是为了收集迟到的数据包，“以防万一”，因为链接可能是不可靠的。 这是规范的一部分，它可以防止丢包，调整它并没有真正的好处。
Q4：没有
Q5：别担心，如果需要的话，你可以select强制重新使用这些套接字。
问题5： TIME_WAIT和ESTABLISHED不相关，除了有更短暂的连接之外，这个比例会更大。 这可能是恶意的原因，但它不仅仅是“过度的networking活动”。
有关TIME_WAIT有限经验的一些答案：
1/2/3）看到这个SO问题和这个页面是对TIME_WAIT的一个很好的解释。 性能问题和更高质量的服务确保连接中的所有TCP数据包都能够正确接收。
4/5）与TIME_WAIT相关的一个性能问题是，在一个非常繁忙的服务器上，如果TIME_WAIT状态太多，最终可能会耗尽可用的连接。 如果您遇到这个问题，您可以尝试减lessTIME_WAIT值，但这可能属于“我知道我在做什么”调整类别。 看到这个问题了解更多的细节。
6）TIME_WAIT的默认值“应该”大约为240s（或120s的MSL的两倍）。 因此，build立/等待连接的比例将取决于您的传入连接速率以及它们保持打开的时间。 例如，我检查了一些我的繁忙的服务器，比例范围从1.3到400，所有这些我都会根据服务器和收到的stream量来考虑。