XDP是什么，它如何帮助构建反DDoS防护？

XDP 简介，以及它如何帮助构建 Anti-DDoS 防护？

如果您运行公共 API、反向代理、游戏服务或任何其他面向互联网的工作负载，您可能会遇到一个令人头疼的问题：服务器忙于处理那些从一开始就毫无用处的流量。应用程序出现故障，未必是因为它无法处理真实用户的请求，而是因为主机在将垃圾数据包更深入地传递到 Linux 之前，就已经耗费了 CPU 时间来接收、解析、分类和传输这些数据包，而此时还没有任何机制说”不”。许多 Anti-DDoS 问题正是从这里开始的：不是带宽问题，而是数据包处理成本问题。

这不仅仅关乎内核专家。开发者、自托管用户、VPS 和独立服务器运营商，乃至比较弹性方案的商业读者，都会遇到同一个基本问题：恶意流量能在多早的阶段被拒绝，以避免消耗本应属于真实业务的时间和资源？某些攻击会直接压垮上行链路，但许多有害情况更早以每秒数据包压力的形式出现在主机上，远在线路完全饱和之前。

这正是 XDP 值得了解的原因。它不能替代上游缓解措施、防火墙或应用感知控制。它所提供的是 Linux 数据包路径中一个更早的检查点。本文将解释 XDP 是什么、为什么这个”更早”的位置对 Anti-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 在 Anti-DDoS 工作中发挥作用。XDP 在数据包进入 Linux 网络路径中正常的、更繁重的部分之前运行。因此，Linux 可以在花费更多精力进行防火墙处理、连接跟踪、套接字处理以及最终传递给应用程序之前，对某些流量做出决策。这就是为什么 XDP 的真正优势不仅仅在于过滤——而在于更早地过滤。

此外，XDP 的用途不仅限于 Anti-DDoS，它还可以支持流量引导和其他数据包处理任务。但 Anti-DDoS 是最容易看到其价值的场景，因为其优势归结为一个实际理念：恶意流量被拒绝得越早，服务器需要做的无用工作就越少。要理解为什么这如此重要，下一步需要了解 XDP 在数据包接收路径中的确切位置。

思维模型：XDP 是大门，而非前台

理解 XDP 最简单的方式是将其视为大门处的安保人员，而非楼内深处的前台接待。如果一个明显不受欢迎的访客在大门处被拒之门外，整栋楼就避免了一系列毫无意义的工作：无需打开内门、无需将其登记入系统、无需引导其穿过走廊。如果等到前台才拒绝他们，楼内已经在这个错误的人身上花费了时间和精力。

Linux 数据包处理的工作方式相同。在简化的接收路径中，数据包从 NIC 和驱动到达，经过 XDP，然后才继续进入更丰富的内核网络栈，该栈负责连接跟踪、防火墙、套接字，最终到达应用程序。从视觉上看，路径如下所示：

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

在 native 模式下，XDP 可以在 Linux 分配和填充通常的 sk_buff 结构之前采取行动——sk_buff 是栈其余部分所期望的更丰富的内核数据包对象。这个细节听起来微不足道，但它是性能故事的核心。如果数据包明显是不需要的，在 Linux 构建该正常结构之前将其丢弃意味着更少的 CPU 工作、更少的内存消耗以及更少的下游压力。XDP_PASS 的存在是因为并非每个数据包都是坏的；它是”继续”动作，让合法流量保持流动。XDP_DROP 是 Anti-DDoS 的明星，因为它在昂贵的处理开始之前就终止了旅程。其他动作如 REDIRECT 也存在，但它们对本文的解释不起关键作用。

一旦理解了 XDP 的位置，Anti-DDoS 的价值——以及其局限性——就变得更容易实际评估了。

XDP 如何帮助 Anti-DDoS——以及其局限性从哪里开始

XDP 在 Anti-DDoS 方面的优势很直接：它是一种廉价的方式，在 Linux 花费资源进行连接跟踪、套接字处理和用户空间传递之前，拒绝明显的垃圾流量。如果主机正在被高速率的、永远不应该到达应用程序的流量轰炸，每个被提前丢弃的数据包都是服务器不再需要在后续处理的工作。这就是为什么 XDP 在问题的 L3/L4 边缘最为强大：您已经不信任的源地址、您不想要的协议，或者对于工作负载明显不合法的流量模式。

这在垃圾洪水攻击中最为重要，因为痛苦的部分不是原始数据量，而是重复的数据包处理。反向代理、UDP 密集型服务或公共 API 可能在上行链路完全饱和之前就变慢，因为主机忙于分类无意义的内容。XDP 为您提供了一种在接近入口处切断部分浪费的方法。

📝 注意：XDP 保护主机资源的效果优于保护已饱和的上游链路。如果提供商面向的链路已经满载，主机级别的早期丢弃本身无法修复网络路径。

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

换句话说，XDP 和 nftables 并非对立关系，它们解决路径的不同部分。nftables 功能更丰富且有状态。xdp-filter——本文中使用的演示工具——有意设计得简单且无状态，这正是它在展示 XDP 模型时有用的原因，而不是假装要替代完整的防火墙。如果您需要连接跟踪、分层允许列表、回复状态处理或应用感知规则，您描述的问题已经属于比这个演示工具更深层次的范畴。

生产运营商确实使用 XDP 风格的丢弃，因为早期丢弃可以减少下游工作。Cloudflare 的 L4Drop 案例是该模型在实际运营中为何变得有吸引力的著名例子。但重要的教训不仅仅是标题上的每秒数据包数字，而是设计逻辑：更早拒绝恶意流量，让机器的其余部分能够更长时间地为真实流量提供服务。

实际结果在很大程度上取决于环境。NIC 和驱动支持、XDP 是否以 native 模式还是 skb 模式运行，以及传入流量的形态，都会影响您实际获得的收益。这就是为什么来自供应商或超大规模云服务商的标题每秒数据包数字最好被视为早期丢弃模型有效的证明，而不是每台 VPS 都应该期望的数字。有了这个认识，下一节将通过几个安全的运营商快照展示 XDP 在真实 Ubuntu 主机上的样子。

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

本节是一个概念验证快照。目标是让 XDP 在 Ubuntu 24.04 上通过相关命令集变得真实可感：足以加载过滤器、检查已附加的内容、添加一条低风险规则，并读取重要的计数器。

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

ip -br link

安装必要的依赖项。

sudo apt update
sudo apt install -y xdp-tools

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

sudo xdp-filter load -m skb <ifname>

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

第三条命令以 skb 模式和默认 allow 策略加载 xdp-filter。在本文使用的 Ubuntu 主机上，这产生了具有完整 tcp,udp,ipv6,ipv4,ethernet,allow 功能集的 xdpfilt_alw_all 变体。选择 -m skb 可以避免假设您的 NIC 或驱动支持 native 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 程序确认该接口上的 generic XDP 处于活动状态。

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

接下来，检查能力发现信息。这告诉您 NIC 和驱动在 XDP 表面上暴露了什么，而不是您最终的性能表现。

sudo xdp-loader features <ifname>

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

这里最重要的是 NETDEV_XDP_ACT_BASIC，因为它告诉您该路径暴露了核心 XDP 动作模型。重定向支持等额外标志很有用，但对于简单的 Anti-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 策略。换句话说，匹配规则的数据包会被丢弃，不匹配规则的数据包则继续通过正常路径。

这个示例有意设计得平淡无奇。从 Anti-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、连接跟踪和套接字容量时。
• 上游缓解仍然是必须的：当真正的故障模式是提供商链路饱和或更大规模的容量洪水，在数据包到达您的服务器之前就已发生时。

VPS 用户应牢记一点：即使 skb 模式在演示中运行良好，虚拟 NIC 路径和提供商抽象也可能限制 native 模式的预期效果。独立服务器通常让您对驱动、硬件和可观测性有更多控制，因此在那里获得有意义的 native 模式支持的可能性更大——但即使在裸金属上，XDP 仍然只是一层，而非完整答案。如果您正在评估 AlexHost 或任何其他提供商，请分别提出三个问题，而不是将它们混在一起：存在哪些上游 DDoS 处理机制、该方案给您提供多少主机余量，以及在该平台上哪些主机级别的控制是现实可行的？

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

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

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