2

我已阅读相关问题：

TIME_WAIT服务器端的许多成本是多少？

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

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

4

1 回答 1

2

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

编辑：

尽管对此进行了更多考虑，但缺少 TCP 级别的问题并不一定意味着您的供应商正在转移责任。1500 TCP 连接是非常低的，但对于这个特定的数据库，也许不是。一些 RDMS 只允许相对较少的连接数（相对于 TCP 堆栈可以支持的内容）。此值完全依赖于 RDMS，通常可以配置。

例如，我曾经超过了 MySQL 服务器允许的并发连接数，并且服务器拒绝处理任何更多数据（您可以称之为停止），因为我没有正确关闭与 MySQL 的连接。可能是您的数据库能够支持的比您投入的更多，但是您使用连接的效率低下。

于 2014-03-12T13:02:00.567 回答