XDP是什么以及它如何帮助构建反DDoS保护？

XDP 介绍，以及它如何帮助构建反 DDoS 保护？

如果您运行公共 API、反向代理、游戏服务或任何其他面向互联网的工作负载，您可能会遇到一个痛点：服务器忙于处理本来就没有用的流量。应用程序失败不一定是因为它无法处理真实用户。它失败是因为主机花费 CPU 时间接收、解析、分类和将垃圾数据包深入 Linux，然后才有任何东西说”不”。许多 DDoS 问题就从这里开始：不是带宽问题，而是数据包处理成本问题。

这不仅仅关系到内核专家。开发人员、自托管者、VPS 和专用服务器运营商，甚至比较弹性选项的业务读者都会遇到同样的基本问题：坏流量在消耗应该属于真实工作的时间和资源之前，能有多早被拒绝？某些攻击会直接压垮上行链路本身，但许多有害情况会更早出现，表现为主机上的每秒数据包压力，远在线路完全饱和之前。

这就是 XDP 值得理解的地方。它不能替代上游缓解、防火墙或应用感知控制。它提供的是 Linux 数据包路径中一个更早的检查点。本文解释了什么是 XDP、为什么这个”更早”的位置对 DDoS 工作很重要，以及它在现实堆栈中的位置。要理解其余部分，您首先只需要一个非常小的词汇集。

2分钟内掌握的XDP关键词

围绕XDP的几个术语有重叠，乍一听比实际情况更令人生畏。这很正常。这个词汇表的目的不是把文章变成Linux内核课程。它只是提供足够的语言，帮助其余的解释清晰地传达。

如果你只从该表中记住一个心理捷径，那就是这个：eBPF是可编程机制，XDP是该机制可以运行的一个特定位置。有了这个基础，下一步是一个更简单、更有用的问题：XDP实际上在做什么？

XDP 实际上是什么

XDP 是 Linux 中的早期数据包处理钩子。它让系统在数据包到达网络接口时立即在该数据包上运行一个小的 eBPF 程序。在那一刻，Linux 可以做出快速决定：让数据包继续（XDP_PASS）、立即丢弃它（XDP_DROP）或以另一种定义的方式处理它。对于本文，重要的部分很简单：XDP 可以很早地说”让它通过”或”在这里停止它”。

Linux 在多个上下文中使用 eBPF，不仅仅是网络。XDP 是为网络构建的版本，专为非常早期处理传入数据包而构建。所以 XDP 不是 eBPF 的另一个词。它是一个 eBPF 基础工具，具有非常特定的角色。

这个角色使 XDP 对于反 DDoS 工作很有用。XDP 在数据包通过 Linux 网络路径的正常、更重的部分之前运行。因此，Linux 可以在花费更多精力进行防火墙、连接跟踪、套接字和最终应用程序本身之前对某些流量做出决定。这就是为什么 XDP 的真正优势不仅仅是过滤——而是更早地过滤。

此外，XDP 的用途不仅限于反 DDoS。它还可以支持流量转向和其他数据包处理任务。但反 DDoS 是最容易看到其价值的地方，因为好处归结为一个实际的想法：拒绝坏流量越早，服务器要做的无用功就越少。为了理解为什么这很重要，下一步是查看 XDP 在数据包接收路径中的确切位置。

心智模型：XDP 是门卫，不是前台

最简单的理解 XDP 的方式是把它看作一个门卫，而不是建筑物内部更深处的前台接待员。如果一个明显不受欢迎的访客在门口被拒之门外，建筑物就避免了一长串毫无意义的工作。没有人打开内门、把他们登记到系统中，或者陪他们走过走廊。如果等到前台才拒绝他们，建筑物已经在错误的人身上浪费了时间和注意力。

Linux 数据包处理的工作原理是一样的。在简化的接收路径中，数据包从 NIC 和驱动程序到达，进入 XDP，然后才继续进入更丰富的内核网络栈，该栈提供给 conntrack、防火墙、套接字，最后是应用程序。从视觉上看，路径是这样的：

NIC / driver
    ↓
XDP  ← earliest checkpoint
    ↓
kernel networking stack
    ↓
conntrack / firewall
    ↓
socket
    ↓
application

在本机模式下，XDP 可以在 Linux 分配和填充通常的 sk_buff 结构之前进行操作——这是栈的其余部分期望的更丰富的内核数据包对象。这个细节听起来很小，但它是性能故事的核心。如果数据包明显不需要，在 Linux 构建该普通结构之前将其丢弃意味着更少的 CPU 工作、更少的内存消耗和更少的下游压力。XDP_PASS 存在是因为并非每个数据包都是坏的；它是”继续”操作，让合法流量继续流动。XDP_DROP 是反 DDoS 明星，因为它在昂贵的部分开始之前就结束了旅程。其他操作如 REDIRECT 也存在，但对于这个解释来说并不是承重的。

一旦位置清楚了，反 DDoS 价值——以及局限性——就变得更容易现实地判断。

XDP 如何帮助抗 DDoS — 以及其限制从何开始

XDP 的抗 DDoS 案例很直接：这是一种廉价的方式来拒绝明显的垃圾流量，然后 Linux 才会在 conntrack、socket 处理和用户空间传递上花费资源。如果一个主机被高速流量轰炸，而这些流量本不应该到达应用程序，那么每个提前丢弃的数据包都是服务器稍后不必做的工作。这就是为什么 XDP 在问题的 L3/L4 边缘最强大：你已经不信任的源地址、你不想要的协议，或明显不符合工作负载的流量模式。

这在垃圾洪泛中最重要，其中痛苦的部分不是原始数据量，而是重复的数据包处理。反向代理、UDP 密集型服务或公共 API 可能在上行链路完全饱和之前就变得缓慢，如果主机忙于分类无用数据。XDP 为你提供了一种方式来在门口附近切断一些浪费。

📝 注意：XDP 保护主机资源的效果比保护饱和的上游链路更好。如果面向提供商的链路已经满了，主机级早期丢弃太晚了，无法单独修复网络路径。

这种区别是 XDP 属于分层设计而不是被放在神坛上的主要原因。下表是 XDP vs nftables vs 上游/提供商缓解 的实用版本：

换句话说，XDP 和 nftables 不是敌人。它们解决路径的不同部分。nftables 更丰富且有状态。xdp-filter — 本文中使用的演示工具 — 故意简单且无状态，这正是为什么它对展示 XDP 模型很有用，而不假装替代完整防火墙。如果你需要连接跟踪、分层允许列表、回复状态处理或应用感知规则，你已经在描述属于更深层的问题。

生产运营商确实使用 XDP 风格的丢弃，因为早期丢弃减少了下游工作。Cloudflare 的 L4Drop 故事是该模型在真实运营中变得吸引人的一个著名例子。但重要的教训不仅仅是标题数据包每秒数字。这是设计逻辑：更早拒绝坏流量，以便机器的其余部分可以继续更长时间地服务真实流量。

真实世界的结果在很大程度上取决于环境。NIC 和驱动程序支持、XDP 是在原生还是 skb 模式下运行，以及传入流量的形状都会影响你实际获得多少好处。这就是为什么来自供应商或超大规模提供商的标题数据包每秒数字最好被视为早期丢弃模型有效的证明，而不是每个 VPS 应该期望的数字。考虑到这一点，下一部分展示了通过几个安全的运营商快照在真实 Ubuntu 主机上 XDP 的样子。

XDP 在实践中的样子 — 命令快照

本部分是概念验证快照。目标是在 Ubuntu 24.04 上让 XDP 感觉真实，使用相关命令集：足以加载过滤器、检查附加内容、添加一条低风险规则，以及读取重要的计数器。

在继续进行 XDP 设置之前，你需要先发现并选择接口名称。

ip -br link

安装先决条件。

sudo apt update
sudo apt install -y xdp-tools

在下面的命令中，将 <ifname> 替换为你的实际网络接口名称，例如 eth0 或 ens3。

sudo xdp-filter load -m skb <ifname>

前两个命令负责安装所需的工具，确保环境拥有运行演示所需的一切。

第三个命令则以 skb 模式加载 xdp-filter，使用默认的 allow 策略。在用于本文的 Ubuntu 主机上，这产生了具有完整 tcp,udp,ipv6,ipv4,ethernet,allow 功能集的 xdpfilt_alw_all 变体。选择 -m skb 避免了假设你的 NIC 或驱动程序中的本地 XDP 支持，使其成为首次概念验证的更安全路径。

要验证程序是否真正附加，请运行：

sudo xdp-filter status
ip -details link show dev <ifname>

在 xdp-filter status 中，你希望看到你的接口以 skb mode 列出；在这里的测试主机上，加载的功能集显示为 tcp,udp,ipv6,ipv4,ethernet,allow。在 ip -details link show 中，xdpgeneric 附加和 xdp_dispatcher 程序确认该接口上的通用 XDP 处于活动状态。

⚠️ 警告：除非你有控制台恢复，否则不要在承载你的 SSH 会话的实时远程接口上测试拒绝默认策略或广泛的丢弃规则。本文坚持使用 allow 策略和一条文档地址规则，正是出于这个原因。

接下来，检查能力发现。这告诉你 NIC 和驱动程序在 XDP 表面上暴露的内容，而不是你最终的性能。

sudo xdp-loader features <ifname>

确切的输出因硬件而异，但代表性结果通常包含如下行：

这里最重要的是 NETDEV_XDP_ACT_BASIC，因为它告诉你路径暴露了核心 XDP 操作模型。额外的标志（如重定向支持）很有用，但对于简单的反 DDoS 概念验证不是必需的。

接下来，验证 XDP 加载器如何管理程序以及它运行的模式。

sudo xdp-loader status

在工作系统上，状态视图可能如下所示：

这是一个小但重要的操作员检查。它确认 XDP 不仅仅是一个存在于用户空间中的规则概念 — 接口上有一个加载的程序，模式列告诉你你是在查看 native 还是 skb。

现在使用文档 IP 地址添加一条安全示例规则。-s 标志很有帮助，因为它立即打印生成的规则状态，而不是让你得到无声的成功。

sudo xdp-filter ip -s -m src 192.0.2.1

代表性响应可能如下所示：

📝 注意：xdp-filter 默认为 allow 策略。换句话说，匹配规则的数据包被丢弃，不匹配规则的数据包继续通过正常路径。

这个例子故意很无聊。在反 DDoS 术语中，它也展示了最简单的早期丢弃规则版本：来自你不想要的源的流量可以在主机的其余部分投入大量工作之前被拒绝。

最后，在一个地方检查整体状态。

sudo xdp-filter status

在典型系统上，输出模式是最具信息性的。

这个状态视图是概念验证变得在操作上有用的地方。你可以在一个命令中看到加载的接口、活动模式、活动 xdp-filter 变体、有效功能集和每条规则的计数器状态。XDP_ABORTED（如果出现）主要是一个错误/调试桶，而不是你计划的操作。更重要的是，如果丢弃计数器保持在 0，这并不意味着过滤器失败。它只意味着在捕获窗口期间没有匹配的数据包命中规则。

💡 要点：将 xdp-filter 视为简单的、无状态的概念验证工具，而不是 nftables 的替代品。还要记住，在 XDP 层丢弃的数据包可能永远不会出现在通常的 tcpdump 路径中，这使得 XDP 本机状态输出和计数器成为更可靠的验证方法。如果你稍后想要实时视图，sudo xdp-filter poll -i 2000 是一个合理的可选下一步 — 但仅当接口已经有足够有趣的流量来使该输出有用时。

看到安全的演示使这个想法具体化。但真正的决定不是命令是否运行。而是这个额外的层是否值得你实际管理的基础设施类型上的操作复杂性。

何时值得考虑在 VPS 和专用服务器上使用 XDP

当公开面向的工作负载因为不需要的数据包而在应用程序能够正常响应之前损失大量 CPU 时间时，XDP 就变得有趣了。很好的候选对象包括公共 API、反向代理、网关、互联网暴露的 UDP 重型服务，以及定期看到足够垃圾流量来压力测试网络路径的主机，即使应用程序本身不是瓶颈。在这些环境中，更早的拒绝可以为真实服务器争取到实际的可用资源。

也有很多情况下，更简单的过滤就足够了。低流量网站、内部工具、测试环境，或者其真实需求是有状态主机防火墙而不是数据包速率缓解的服务通常不需要首先使用 XDP。如果 nftables 已经在没有明显数据包路径压力的情况下覆盖了风险，添加另一层可能会创建比价值更多的活动部件。

作为一个快速决策框架：

• 防火墙通常就足够了，当流量很轻、策略需要状态或更丰富的服务逻辑，以及主机在垃圾数据包上没有明显地消耗 CPU 时。
• XDP 值得评估，当不需要的流量经常到达主机，以至于早期丢弃可以保护 CPU、conntrack 和套接字容量时。
• 上游缓解仍然是必须的，当真实的故障模式是提供商链路饱和或更大的容量性洪泛，甚至在数据包到达你的服务器之前。

VPS 用户应该记住一个警告：虚拟 NIC 路径和提供商抽象即使在 skb 模式对演示工作良好时，也可能限制原生模式的预期。专用服务器通常让你对驱动程序、硬件和可观测性有更多的控制，所以有意义的原生模式支持的几率更好——但即使在裸金属上，XDP 仍然只是一层，不是整个答案。如果你在评估 AlexHost 或任何其他提供商，应该分别提出三个问题，而不是将它们合并在一起：存在什么上游 DDoS 处理、计划给你多少主机可用资源，以及该平台上现实的主机级控制是什么？

结论：XDP 是早期丢弃层，而非完整防护

理解 XDP 最清晰的方式是：它为 Linux 提供了一个快速的首道检查点来应对明显的恶意流量和数据包洪泛，这意味着它对服务器资源的保护优于对饱和上游链路的保护。这就是为什么 XDP 在反 DDoS 讨论中很重要。它不能替代上游缓解、有状态防火墙或应用感知控制。它的作用是让主机减少无谓的工作。

所以经验法则很简单。如果不需要的流量在真实工作负载能够响应之前浪费了主机 CPU，XDP 值得评估作为早期丢弃层。如果主要问题是链路满载或依赖于状态和应用逻辑的策略，XDP 应该位于上游缓解和更深层过滤之后，而不是作为完整答案放在前面。从这里自然的下一步将是关于编写自定义 XDP 程序或围绕相同早期丢弃理念构建更丰富的分层防御的后续讨论。