XDP și eBPF pentru procesarea pachetelor de înaltă performanță

XDP (eXpress Data Path) și eBPF (extended Berkeley Packet Filter) permit Linux să proceseze pachetele de rețea înainte ca stiva de rețea normală a kernelului să fie implicată. În loc să aloce structuri de memorie pentru fiecare pachet primit, XDP interceptează traficul chiar la nivelul driverului NIC, decide ce să facă cu acesta și îl respinge, îl redirecționează sau îl redirecționează. Rezultatul este o procesare a pachetelor de milioane de pachete pe secundă pe nucleu, cu o fracțiune din suprasarcina CPU a instrumentelor tradiționale precum iptables.

Cum funcționează împreună eBPF și XDP

eBPF este o mașină virtuală din interiorul kernelului Linux. Aceasta rulează cod byte personalizat care a fost verificat din punct de vedere al siguranței (fără bucle infinite, fără acces neautorizat la memorie) și apoi compilat JIT în instrucțiuni native ale procesorului. Programele au un domeniu de aplicare limitat. Acestea nu pot apela funcții arbitrare ale kernelului, ci doar un set de ajutoare predefinite pentru sarcini precum căutări în hărți și redirecționarea pachetelor.

Pentru gestionarea stării, eBPF utilizează hărți, care sunt stocări de tip cheie/valoare (tabele hash, matrice, arbori LPM) care persistă pe parcursul sosirii pachetelor. Hărțile pot fi citite și scrise din spațiul utilizatorului, astfel încât puteți actualiza listele de blocare sau regulile de rutare fără a reîncărca programul.

XDP este un punct de conectare eBPF. Se atașează la calea de recepție a driverului NIC, înainte ca kernelul să aloce o sk_buff structură (obiectul de metadate de 200-300 de octeți pe pachet de care depinde stiva de rețea tradițională). Omiterea acelei alocări este sursa câștigului de performanță.

XDP rulează în trei moduri:

• Modul nativ: rulează în interiorul driverului NIC. Cea mai bună performanță.
• Modul descărcat: rulează pe ASIC-ul NIC-ului. Eliberează complet CPU-ul.
• Modul generic: rulează după sk_buff alocare. Util pentru testarea pe hardware neacceptat, dar fără beneficii de performanță.

După procesarea fiecărui pachet, programul XDP returnează un verdict:

XDP vs iptables: Benchmark-uri de performanță

Cifrele sunt clare. iptables gestionează aproximativ 200.000 de pachete pe secundă pe nucleu. nftables îmbunătățește această valoare la aproximativ 400.000 pps. XDP în modul nativ procesează între 10 și 40 de milioane de pps pe nucleu pe același hardware.

Motivul este simplu: un XDP_DROP costă o verificare de limite și o valoare de returnare. Un iptables DROP necesită sk_buff alocare, traversarea lanțului netfilter, căutarea de urmărire a conexiunii, acțiunea DROP în sine și apoi dezalocarea. La 100 Gbps cu pachete de 64 de octeți, un server se confruntă cu 148 de milioane de pachete pe secundă, rămânând aproximativ 100 de nanosecunde per pachet. La această scară, sk_buff alocarea devine gâtul de sticlă.

Economiile de CPU sunt la fel de semnificative. Trecerea unei liste de blocare de la iptables la XDP într-un singur test de performanță a redus utilizarea CPU pentru întreruperile software de la 28% la 3% la 1 milion de pps. Spațiul de manevră astfel eliberat poate rula procese de aplicații, baze de date sau mașini virtuale pe același server.

Atenuarea atacurilor DDoS și securitate

Cel mai puternic caz de utilizare a XDP în domeniul găzduirii este atenuarea atacurilor DDoS. Deoarece funcționează la nivel de driver, pachetele rău intenționate sunt respinse înainte de a ajunge la stiva de rețea a kernelului. Un singur nucleu care rulează XDP poate respinge 26 de milioane de pachete pe secundă.

Cloudflare utilizează un sistem bazat pe XDP numit L4Drop pentru atenuarea atacurilor DDoS volumetrice încă din 2018. Sistemul procesează și respinge traficul de atac în contextul XDP, împiedicându-l să ajungă la nivelul aplicației. Katran de la Meta, un echilibrator de sarcină open-source XDP Layer 4, gestionează traficul pentru Facebook și Instagram la peste 10 milioane de pachete pe secundă per nucleu.

Pentru filtrarea dinamică, hărțile eBPF precum BPF_MAP_TYPE_LPM_TRIE vă permit să gestionați liste de blocare IP care acoperă IP-uri individuale și subrețele CIDR într-o singură căutare. Actualizările au loc din spațiul utilizatorului în timp real, fără a fi necesară reîncărcarea programului. În timpul unui atac activ, puteți introduce noi semnături în milisecunde folosind bpftool:

bpftool map update id <MAP_ID> key <KEY_VALUE> value <VALUE>

Pentru observabilitate, eBPF colectează metrici pe aplicație, pe IP și pe flux direct din calea de date a kernelului. Contextul xdp_md contextul oferă telemetrie precum ingress_ifindex și rx_queue_index, astfel încât să puteți identifica ce interfață sau coadă este sub presiune. Pentru monitorizarea pe termen lung, instrumente precum ebpf_exporter convertesc datele brute ale hărții eBPF în metrici compatibile cu Prometheus pentru vizualizare în Grafana.

Instrumente, implementare și cerințe hardware

Lanțul de instrumente începe cu Clang și LLVM pentru compilarea limbajului C restricționat în codul byte eBPF. De acolo, aveți nevoie de o bibliotecă de încărcare:

• libbpf: biblioteca C standard pentru utilizare în producție. Suportă CO-RE (Compile Once, Run Everywhere) pentru portabilitate între nuclee.
• libxdp: specifică XDP, suportă rularea mai multor programe XDP pe o singură interfață.
• cilium/ebpf: o bibliotecă Go pură pentru stive bazate pe Go.

Pentru gestionare, bpftool vă permite să inspectați programele live și conținutul hărților. xdp-loader (din xdp-tools suită) se ocupă de încărcare și descărcare. BCC este util pentru prototipare cu front-end-uri Python/Lua, dar libbpf cu CO-RE este cea mai bună alegere pentru producție.

Activați compilatorul BPF JIT înainte de implementare:

sysctl -w net.core.bpf_jit_enable=1

Pentru actualizări fără întreruperi, utilizați XDP_FLAGS_REPLACE flag-ul pentru a schimba atomic un program care rulează. Fixați hărțile la /sys/fs/bpf/ astfel încât acestea să persiste după ieșirea încărcătorului.

Compatibilitate hardware și kernel

XDP a fost introdus în kernelul 4.8, dar se recomandă 5.x sau o versiune ulterioară pentru setul complet de funcții. Verificați kernelul cu uname -r și verificați dacă sistemul de fișiere BPF există la /sys/fs/bpf/.

Driverul plăcii de rețea (NIC) determină ce funcții XDP sunt disponibile:

Verificați driverul cu ethtool -i <interface>. Dacă modul nativ nu este acceptat, sistemul revine la modul generic, care rulează după sk_buff alocare și nu oferă niciun avantaj de performanță.

Dezactivați GRO și LRO înainte de a atașa un program XDP, deoarece acestea intră în conflict:

ethtool -K <iface> gro off lro off

XDP standard necesită ca pachetele să încapă într-o singură pagină de memorie de 4.096 de octeți. Pe i40e și ice , limita MTU pentru x86 este de 3.046 de octeți.

Noțiuni introductive despre XDP

Începeți prin a vă evalua mediul. Rulați uname -r pentru a confirma că aveți kernel 4.8+ (de preferat 5.x) și ethtool -i <interface> pentru a verifica dacă există suport nativ pentru driverul XDP.

Începeți cu observabilitatea, nu cu aplicarea. Utilizați hărțile eBPF pentru a clasifica și a număra traficul, astfel încât să aveți o bază de referință a activității normale. Odată ce ați înțeles modelele de trafic, treceți la aplicare: testați mai întâi cu xdpgeneric modul, apoi treceți la xdpdrv (nativ) pentru producție.

Rețineți că XDP gestionează filtrarea la nivel de pachet, nu lățimea de bandă brută. Pentru atacuri la scară largă de 100 Gbps, combinați-l cu infrastructura bare-metal și BGP FlowSpec pentru a gestiona traficul din amonte înainte ca acesta să ajungă la server.

Dacă rulați sarcini de lucru cu trafic intens care necesită filtrare rapidă a pachetelor, serverele dedicate FDC oferă fundația bare-metal pentru a profita la maximum de XDP.