我已阅读相关问题：
但我还是迷路了。我们有两个应用服务器和一个数据库服务器（都是由云服务提供的虚拟机）。今天数据库服务器完全关闭而没有任何警告。我们设法让云服务供应商在线备份，我们又将应用程序恢复到工作状态。
当被问及其原因时，云服务供应商返回了一堆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连接数量很多就证明了这一点。
但是，没有迹象表明收集统计数据的时间范围。如果他们被收集在一个很长的时间范围中，则统计数据不能用于声称存在大量此类连接。
此类声明只适用于在特定时间点（非时间范围）内完成的快照统计信息，其中很明显大量连接位于{ {1}}在给定的时间点陈述。 我是对的吗？
即使我们在快照时间点确实存在大量TIME_WAIT连接的可能性，这对服务器是否有害，是否会使服务器停止运行这是拒绝服务攻击的发生方式吗？
答案 0 :(得分：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。现代TCP实现（服务器端）甚至不会创建TCP连接，直到看到SYN / ACK（使用TCP SYN cookie来阻止DOS）。所以，这里有一些缺失的信息。
编辑：
虽然更多地考虑到这一点，但缺乏TCP级别的问题并不一定意味着您的供应商正在转移责任。 1500 TCP连接非常低，但对于这个特定的数据库，可能不是。一些RDMS仅允许相对较少数量的连接（相对于TCP堆栈可以支持的连接）。该值完全取决于RDMS，通常可以配置。
例如，我曾经超过了MySQL服务器的允许并发连接数，服务器拒绝处理更多数据（你可以称之为暂停），因为我没有正确关闭与MySQL的连接。可能是您的数据库能够支持超过您投入的数据库，但您使用这些连接效率低下。