XDP vs DPDK für die Anti-DDoS-Filterung: was sollte man wählen?

Was XDP wirklich ist

XDP, also eXpress Data Path, führt ein eBPF-Programm sehr früh im Linux-Netzwerk-Stack in der Nähe des Treibers aus. Das Ziel ist einfach: Pakete prüfen, bevor sie den kompletten Kernel-Pfad durchlaufen, und schnell entscheiden, ob sie akzeptiert, umgeleitet oder verworfen werden.

Für Anti-DDoS ist XDP als frühe Pre-Filtering-Schicht sehr attraktiv. Solange die Entscheidungslogik kompakt und deterministisch bleibt, kann XDP einen Teil der Last mit geringer Latenz, relativ wenig Betriebsaufwand und einem sauberen Linux-nativen Deployment übernehmen.

Wo XDP glänzt

Einfache Drops, Allowlists, grundlegende Rate-Kontrollen, kurze Signaturen und sehr frühe Validierung im RX-Pfad.

Operativer Vorteil

Linux-nativer Stack, saubereres Deployment, weniger bewegliche Teile und ein sehr starkes Verhältnis aus Einfachheit und Performance.

Wichtigste Erkenntnis

XDP ist hervorragend darin, offensichtlich schlechten Traffic sehr schnell zu verwerfen, solange die Logik kompakt bleibt.

Was DPDK zusätzlich bringt

DPDK verlagert die Paketverarbeitung in den Userspace und umgeht einen großen Teil des klassischen Kernel-Netzwerkpfads. Dadurch bekommt man deutlich feinere Kontrolle über Buffer, Queues, Batching, Memory-Layout und Verarbeitungsschritte.

Für Anti-DDoS wird DPDK interessant, wenn reichere Pipelines nötig sind: tieferes Parsing, Korrelation mehrerer Signale, dynamische Regeln, protokollspezifische Logik, spezialisierte Proxys, Encapsulation-Handling oder fortgeschrittene Telemetrie.

Wo DPDK stark ist

Reichere Pipelines, aggressives Batching, komplexe Verarbeitungsschritte und Custom-Architekturen bei sehr hohem PPS.

Was man dafür eintauscht

Mehr Kontrolle, aber auch mehr Deployment-Komplexität, Debugging-Aufwand und operative Last.

Die richtige Einordnung

DPDK ist nicht automatisch besser. Es wird dann besser, wenn das Problem den komfortablen Bereich von XDP klar überschreitet.

Wann XDP ausreicht

XDP reicht oft aus, wenn das Hauptziel darin besteht, offensichtliches Angriffsrauschen sehr früh zu reduzieren: einfache Floods, bekannte Signaturen, Pre-Filtering für Gaming-Traffic, das Säubern einer Edge-Front oder das Entlasten vor einer zweiten Schicht.

Der Schlüssel ist Ehrlichkeit bei der Komplexität. Je mehr Zustände, Ausnahmen und tiefes Parsing in ein eBPF-Programm gepresst werden, desto schmerzhafter wird die langfristige Wartung. Es geht nicht nur um Zyklen pro Paket, sondern auch darum, wie sicher und vorhersehbar sich das System weiterentwickeln lässt.

Auch der eBPF-Verifier ist wichtig. Er schützt den Kernel, was ein großer Vorteil ist, bringt aber reale Grenzen bei Schleifen, Programmgröße, bestimmten Speicherzugriffen und der allgemeinen Programmform. In der Praxis können sehr ambitionierte Filter unangenehm schwer sauber weiterzuentwickeln sein.

• Das Hauptziel ist schnelles Droppen sehr früh im Stack.
• Die Entscheidungskriterien bleiben relativ kompakt und deterministisch.
• Linux soll im Zentrum des Betriebs bleiben.
• Kosten und Einfachheit sind wichtiger als die reichste Pipeline überhaupt.
• Eine zweite Schicht kann übernehmen, wenn tiefere Logik erforderlich wird.

Wann eine schwerere Architektur nötig ist

Sobald mehr Kontext, mehr Entscheidungszweige und mehr aktive Verarbeitung nötig sind, ist eine Userspace-Architektur oft die gesündere Wahl. Das gilt besonders für protokollspezifisches Filtering, Custom-Anti-DDoS-Proxys, dynamische Regel-Orchestrierung oder Logik, die rohe Paket-Performance mit höherem Verhalten kombiniert.

Genau hier verlieren viele Teams Zeit: Sie versuchen, alles in XDP zu pressen, und bauen am Ende eine komplizierte Engine in einem Modell nach, das dafür nicht ideal war. Das Ergebnis ist nicht immer schneller und oft schwerer zu warten.

Mehrere Signale

Mehrere Felder, Offsets, Längen, Zustände oder sich ändernde Protokollmuster in Kombination.

Fortgeschrittenes Custom-Filtering

Games, spezialisierte Proxys, dedizierte L4/L7-Logik, reichere Encapsulation und komplexere Routing-Workflows.

Sehr hohes PPS mit längerer Pipeline

Wenn die Herausforderung nicht mehr nur frühes Droppen ist, sondern mehrere Stufen effizient und vorhersehbar auszuführen.

Team ist dafür bereit

DPDK ergibt Sinn, wenn die Organisation diese Plattform realistisch betreiben und weiterentwickeln kann.

Wo das beste Kosten/Leistungs-Verhältnis meist liegt

In vielen realen Deployments liegt das beste Kosten/Leistungs-Verhältnis weder bei reinem XDP noch bei reinem DPDK. Es entsteht, wenn die richtige Menge an Komplexität in die richtige Schicht gelegt wird. Konkret: offensichtlichen Junk früh verwerfen, schwere Logik nur dort einsetzen, wo sie klaren Mehrwert bringt, und keine teure Plattform überall mitschleppen.

Für kleine bis mittlere Deployments kann eine Custom-XDP-Schicht hervorragende Rendite liefern. Für größere Designs kann ein dedizierter Pre-Filtering-Server einen großen Teil des Angriffsrauschens absorbieren und saubereren Traffic an eine spezialisiertere Schicht zurückgeben. Das ist oft rationaler, als eine sehr schwere Architektur zu früh auszurollen.

Kleiner bis mittlerer Bedarf

Custom XDP ist oft der stärkste Einstiegspunkt, wenn die Logik scharf abgegrenzt ist und das Budget zählt.

Skalierungsphase

Dediziertes Pre-Filtering ist sinnvoll, wenn Kosten isoliert und der Haupt-Stack sauberer gehalten werden sollen.

Großer und spezieller Bedarf

DPDK wird wirtschaftlich sinnvoll, wenn die Reichhaltigkeit der Pipeline die schwerere Plattform wirklich rechtfertigt.

Warum manche Teams bewusst bei Custom XDP bleiben

Einige Architekturen sind objektiv besser mit Custom XDP bedient. Wenn die Hauptanforderung Fast-Path-Filtering, frühe Sortierung und Nähe zu einer Linux-Umgebung ist, die das Team bereits beherrscht, vermeidet XDP einen großen Teil der operativen Schulden eines schwereren Userspace-Stacks.

Das gilt besonders dann, wenn das Team kernel-zentrierte Workflows, Linux-Observability, Distribution-Tooling, Automatisierungsgewohnheiten und ein einfacheres Betriebsmodell bewahren will. In diesem Kontext ist XDP kein schwacher Kompromiss, sondern kann die stärkste Engineering-Entscheidung sein.

• Weniger Systemkomplexität für eine sehr starke frühe Filtering-Schicht.
• Saubereres Deployment auf exponierten Frontends oder dedizierten Pre-Cleaning-Servern.
• Eine gute Ergänzung für eine spätere zweite Schicht, statt alles auf einmal zu ersetzen.
• Relevant für Custom-Filtering anhand einfacher Protokollmerkmale oder bekannter Signaturen.

Mein Standpunkt: keine Religion wählen, sondern eine Rolle

Mein Standpunkt ist einfach: XDP ist hervorragend, wenn es eine klare Rolle bekommt, und DPDK wird hervorragend, wenn das Problem sein Gewicht klar rechtfertigt. Die schlechteste Entscheidung ist, eines von beiden außerhalb des Kontexts zu überverkaufen.

Wenn der Hauptbedarf sehr frühes und effizientes Pre-Filtering ist, kann XDP der beste Hebel sein. Wenn eine breitere, reichere und besser kontrollierbare Engine gebraucht wird, übernimmt DPDK logisch die Führung. Und in vielen ernsthaften Umgebungen ist die beste Antwort hybrid.

FAQ