你的解释很好！我想我理解你的问题。

DDoS 缓解通常通过在您的互联网连接上游放置缓解设备/系统来工作。您可以为这些服务与 Prolexic 等 DDoS 缓解服务签订合同，或者您可以与已经包含来自任何供应商的 DDoS 缓解的云提供商合作。

从您的服务器在物理级别上缓解 DDoS 是不可能的，因为数据包可能会淹没网络上的下一个跃点，例如您的 ISP 本地交换机。因此，您可以随心所欲地丢弃数据包，它们仍然从 ISP 切换到您的网络并利用您的带宽。因此，为了减轻攻击，需要在上游丢弃数据包。

对于较小的网站，您可以使用 CloudFlare 之类的代理服务——事实上，在它们达到非常大的规模之前，这是许多人的首选解决方案。CloudFlare 通过控制域的 DNS 来工作。然后，它通过其网络和服务器代理所有网络流量，这些网络和服务器都经过了严格的防御，可以抵御 DDoS 攻击，还可以拦截其他常见的黑客攻击，例如 XSS 和 SQL 注入。然后将合法流量转发到您的 Web 服务器，同时将可疑流量丢弃在上游，让您不受潜在 DDoS 影响的影响。

一般来说，您可以做三件事来减轻数据包的泛滥。

1. 确保您的服务器不需要过多的资源来处理传入的数据包。一个体面的服务器可以轻松响应 1 Gbit/s 的回显请求。但是，如果来自未确认源地址的传入 UDP 数据包将启动需要大量内存和 CPU 能力的计算，并最终使用多个 UDP 数据包将响应传输回客户端，那么您的服务器将是一个简单的目标。您的应用程序不是您需要注意的唯一事情。如果您有防火墙规则，还请注意那里的每个数据包涉及多少处理。
2. 有足够的带宽。由于无论您对它们做什么，您收到的数据包都会消耗您的传入带宽，因此拥有足够的传入带宽至关重要。
3. 针对流量向后推过滤器。这需要您的供应商的合作。如果有容易识别的模式可以用来区分合法流量和洪水，那么可以更早地应用过滤器，这样您的链接就不会过载。

当您受到直接攻击和成为反射攻击的受害者时，上述缓解措施均适用。由于它们的性质反射攻击可能更强大，但您也可以采取更多措施来对抗反射攻击。

了解反射攻击

首先，重要的是要了解反射攻击是如何工作的，这样当你被它击中时你就有机会认出它。

1. 攻击者向某些服务发送带有欺骗源 IP 地址的数据包。
2. 服务处理请求并向欺骗的源 IP 发送大于请求的回复。
3. 最终目标收到的数据包比攻击者能够直接产生的数据包更大。
4. Target 将错误消息发送回服务，因为无法识别回复。
5. 服务忽略错误消息，因为它们与任何正在进行的操作无关（从服务的角度来看，此请求已在步骤 2 处理并被遗忘）。

步骤 2 中提到的服务器也称为反射器。通常，攻击的目标是运行基于 UDP 的服务的反射器。DNS 通常是有针对性的，滥用 EDNS 和 DNSSEC 的攻击可能特别有效。NTP 也被证明至少在一个场合是一种非常有效的反射器。

如果管理员不了解发生了什么，反射器的管理员和目标的管理员很容易互相指责。让两个受害者互相指责，并且每个人都假设另一个受害者是攻击者，这不是很有效率。理想情况下，这两个管理员合作减轻攻击。

如果您是反射攻击的最终目标，您通常会处理大量反射器。单独与每个反射器的管理员合作可能效率不高。还要记住，尽管反射器的管理员没有恶意，但他们可能很懒惰。

针对反射攻击的附加措施

对反射攻击的保护已经从协议设计开始。当客户端地址尚未确认时，向该 IP 地址发送回的数据包或字节数不要超过从该 IP 地址收到的数据，这一点至关重要。反射攻击对于回复大于请求的协议是有效的。

在 TCP 上运行的协议不需要考虑这个问题。TCP 握手比大多数协议更能抵抗反射攻击。只有在比 TCP 更低的层或在 UDP 等更轻的层上工作的协议才需要防止反射。

在实现一个已经指定的协议时，您首先需要充分了解该协议，以准确了解它在哪些地方可以防止反射，在哪些地方没有。协议中指定的任何反射保护都必须安全地实现（这几乎肯定意味着您需要使用一个好的随机数生成器）。

此外，您需要了解您正在实施的协议中缺少反射保护的地方。在这种情况下，您需要小心在代码中实施缓解措施。

在上面对反射攻击期间发生的情况的解释中，最后一步是服务忽略了错误消息。该服务可以使用此类错误消息作为潜在正在进行的反射攻击的指示，并采取必要的对策，而不是忽略它。遗憾的是，这种对策并不普遍（我不知道是否有人应用过）。

作为部署可能用作反射器的服务的管理员，您需要了解自己在做什么。仅在需要时才部署此类服务。注意任何正在进行的反射攻击，并尽可能使用带有反反射措施的实现。

一般来说，作为管理员，请确保您的系统发送正确的 ICMP 错误消息以响应意外或定向到无效 IP、协议号或端口号的数据包。还要确保 ICMP 错误消息受到速率限制。

为每个以封闭端口为目标的传入数据包发送 ICMP 错误消息可能会出现问题。这是因为 ICMP 错误消息包含触发数据包的副本，因此将比原始数据包大（除非结果变得太大以至于将被截断）。通过发送比接收更多的字节，您不仅有可能将传入的洪水变成传出的洪水，而且您还有一个可以用作反射器的主机。

只为一半的数据包发送 ICMP 错误消息就足以确保传出字节和数据包的数量小于传入的数量。因此，它可以防止 ICMP 错误消息被用作反射向量。并且仍然有足够的错误回复，它们可以有意义地用作缓解措施的一部分。

不要完全禁用 ICMP 错误消息。这将使您和您的用户更难调试连接问题。在某些情况下，禁用的 ICMP 错误消息甚至会成为连接问题的原因。它还将防止缓解上述反射攻击。如果即使是一小部分反射器实现了这样的缓解措施，也足以让 ICMP 错误消息变得有价值。