tcp - 很多 TIME_WAIT 会导致服务器宕机吗？

Question

我已阅读相关问题:

What is the cost of many TIME_WAIT on the server side?

但我还是迷路了。我们有两台应用服务器和一台数据库服务器(都是云服务提供的虚拟机)。今天，数据库服务器在没有任何警告的情况下完全关闭。我们设法让云服务供应商将其恢复在线，并将我们的应用程序再次恢复到工作状态。

当被问及这样做的原因时，云服务供应商返回了一堆 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 连接的可能性，这是否会对服务器造成损害并且是否会使服务器逐渐停止？ 这就是拒绝服务攻击的发生方式吗？

Answer 1

必须跟踪每个 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 实现(服务器端)甚至不会创建 TCP 连接，直到看到 SYN/ACK(使用 TCP SYN cookie 来防止 DOS)。所以，这里缺少一些信息。

编辑:

尽管考虑得更多，但没有 TCP 级别的问题并不一定意味着您的供应商在推卸责任。 1500 个 TCP 连接数很低，但对于这个特定的数据库，也许不是。一些 RDMS 只允许相对较少的连接数(相对于 TCP 堆栈可以支持的连接数)。该值完全依赖于 RDMS，通常可以配置。

例如，我有一次超过了 MySQL 服务器允许的并发连接数，服务器拒绝处理任何更多数据(你可以称之为停止)，因为我没有正确关闭与 MySQL 的连接。可能是您的数据库能够很好地支持比您投入的更多的东西，但您使用连接的效率很低。