我已阅读相关问题:
但我还是迷失了方向。我们有两台应用程序服务器和一台数据库服务器(都是云服务提供的虚拟机)。今天，数据库服务器在没有任何警告的情况下完全关闭。我们设法让云服务供应商将其恢复到在线状态，并将我们的应用程序再次恢复到工作状态。
当被问及其原因时，云服务供应商返回了一堆 TCP 统计信息(大约 1500 行)，如下所示(出于隐私原因进行了屏蔽):
ipv4 2 tcp 6 98 TIME_WAIT src=x.x.x.x dst=y.y.y.y sport=z dport=5432 packets=p bytes=b src=y.y.y.y dst=x.x.x.x sport=5432 dport=z packets=p bytes=b [ASSURED] mark=0 secmark=0 use=2
供应商声称服务器出现问题并因传入连接过多而自行关闭，大量 TIME_WAIT 连接就证明了这一点。
但是，没有说明收集统计数据的时间范围。如果它们是在很长的时间范围内收集的，则统计数据不能用于声称存在大量此类连接。
此类声明仅对在特定时间点(而非时间范围)完成的快照统计有效，其中明显存在大量连接TIME_WAIT 在给定时间点的状态。 我说得对吗？
即使我们承认在快照时间点确实存在大量 TIME_WAIT 连接的可能性，这是否会对服务器造成损害？是否会使服务器崩溃突然停止？拒绝服务攻击就是这样发生的吗？
最佳答案
每个 TIME_WAIT 状态都必须被跟踪，简单明了。当数据包返回 TIME_WAIT 连接时，这种状态维护(想想:每个连接使用的物理内存)允许 TCP 堆栈将传入数据包与已关闭的连接关联起来。如果不是 SYN，则该数据包将被忽略。如果它是 SYN，则某些(大多数？)实现允许 TIME_WAIT 暗杀。
很简单，是的，太多并发关闭的连接可能会使系统过载，因为 TIME_WAIT 持续几分钟左右。
关于此类攻击的可能性，是的，这当然是可能的。然而，它很可能是分布式拒绝服务 (DDOS)，而不是普通的 DOS。这是因为要将连接置于 TIME_WAIT 状态，连接必须完全打开 (SYN + SYN/ACK + ACK)，然后关闭 (FIN + FIN/ACK + ACK)，并且只有少数机器不会这样做能够以这种方式淹没服务器。但考虑到打开 TCP 连接需要几毫秒的时间，而 TIME_WAIT 通常会持续几分钟，因此存在潜在的问题。
但是，这很大程度上会导致供应商的 TCP 实现。 1500 听起来不像是大量的 TIME_WAIT 状态，而且这似乎无关。如果服务器由于并发连接过多而丢弃连接，那么您需要了解当时的事件负载，而不是 TIME_WAIT。现代 TCP 实现(服务器端)在看到 SYN/ACK 之前甚至不会创建 TCP 连接(使用 TCP SYN cookie 来防止 DOS)。因此，这里缺少一些信息。
编辑:
尽管更多地考虑这一点，但不存在 TCP 级问题并不一定意味着您的供应商正在推卸责任。 1500 个 TCP 连接是非常低的，但对于这个特定的数据库来说，也许并非如此。一些 RDMS 只允许相对较少数量的连接(相对于 TCP 堆栈可以支持的数量)。该值完全依赖于 RDMS，通常可以配置。
例如，我曾经超出了 MySQL 服务器允许的并发连接数，并且服务器拒绝处理更多数据(您可以称之为磨机停机)，因为我没有正确关闭与 MySQL 的连接。也许您的数据库能够很好地支持比您所提供的更多的功能，但您使用连接的效率很低。
关于tcp - 大量的 TIME_WAIT 会导致服务器瘫痪吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/22351193/