27

问题总结

我们有一个设置，其中很多（每秒 800 到 2400 个传入连接到 linux 机器，我们在客户端和服务器之间有一个 NAT 设备。所以系统中剩下这么多 ​​TIME_WAIT 套接字。为了克服这个问题，我们已将 tcp_tw_recycle 设置为 1，但这导致了 comming 连接的丢失。在浏览网络后，我们确实找到了为什么会发生 tcp_tw_recycle 和 NAT 设备丢失帧的参考。

尝试解决

然后我们尝试将 tcp_tw_reuse 设置为 1，它工作正常，没有任何问题，使用相同的设置和配置。

但是文档说，当通过 TCP 状态感知节点（例如防火墙、NAT 设备或负载平衡器）的连接可能会看到丢帧时，不应使用 tcp_tw_recycle 和 tcp_tw_reuse。连接越多，您就越有可能看到此问题。

查询

1) tcp_tw_reuse 可以用在这种场景吗？2）如果不是，linux代码的哪一部分阻止了tcp_tw_reuse被用于这种情况？3）一般tcp_tw_recycle和tcp_tw_reuse有什么区别？

4

1 回答 1

56

默认情况下，当tcp_tw_reuse和tcp_tw_recycle都被禁用时，内核将确保处于该状态的套接字TIME_WAIT将保持该状态足够长的时间——足够长的时间以确保属于未来连接的数据包不会被误认为是旧连接的延迟数据包。

当您启用tcp_tw_reuse时，处于状态的套接字TIME_WAIT可以在过期之前使用，并且内核将尝试确保没有关于 TCP 序列号的冲突。如果您启用tcp_timestamps（又名 PAWS，用于防止包装序列号），它将确保不会发生这些冲突。但是，您需要在两端启用 TCP 时间戳（至少，这是我的理解）。有关血腥细节，请参阅tcp_twsk_unique 的定义。

当您启用tcp_tw_recycle时，内核变得更加激进，并且将对远程主机使用的时间戳做出假设。它将跟踪每个具有连接TIME_WAIT状态的远程主机使用的最后一个时间戳），如果时间戳正确增加，则允许重新使用套接字。但是，如果主机使用的时间戳发生变化（即及时回溯），SYN数据包将被静默丢弃，连接将无法建立（您将看到类似于“连接超时”的错误）。如果您想深入研究内核代码，tcp_timewait_state_process 的定义可能是一个很好的起点。

现在，时间戳永远不应该回到过去；除非：

  • 主机重新启动（但是，当它重新启动时，TIME_WAIT套接字可能已经过期，所以这不是问题）；
  • IP 地址很快被其他东西重用（TIME_WAIT连接会保留一点，但其他连接可能会被击中TCP RST，这将释放一些空间）；
  • 网络地址转换（或 smarty-pants 防火墙）参与连接的中间。

在后一种情况下，您可以在同一 IP 地址后面拥有多个主机，因此，不同的时间戳序列（或者，所述时间戳在防火墙的每个连接处是随机的）。在这种情况下，一些主机将随机无法连接，因为它们被映射到TIME_WAIT服务器的存储桶具有较新时间戳的端口。这就是为什么文档告诉您“NAT 设备或负载平衡器可能会因为设置而开始丢帧”。

有些人建议不要tcp_tw_recycle理会，但启用tcp_tw_reuse并降低tcp_fin_timeout. 我同意 ：-）

于 2012-10-04T02:00:23.817 回答