Cet article répertorie quatre moteurs de collecte de paquets Linux classiques. Si vous pensez qu'il y en a d'autres, vous pouvez laisser un message. Ces quatre sont :
libpcap se trouve au niveau de la couche liaison de données. Ajouter un contournement processus qui n'interfère pas avec le traitement de la propre pile de protocoles réseau du système. Les paquets de données envoyés et reçus sont filtrés et mis en mémoire tampon via le noyau Linux, et finalement transmis directement à l'application de couche supérieure.
- 5.1 S'il existe un programme de capture de paquets, entrez le filtre BPF via la sous-interface réseau et copiez les paquets correspondant aux règles dans le cache du noyau système ( "3ème copie " ). BPF associe un filtre et deux tampons à chaque programme de capture de paquets nécessitant un service. BPF alloue des tampons et sa taille est généralement de 4 Ko. Le tampon de stockage est utilisé pour recevoir les données de l'adaptateur ; le tampon de conservation est utilisé pour copier les paquets vers l'application.
- 5.2 Traitez la fonction de pontage de la couche liaison de données ;
- 5.3 Déterminez le protocole de couche supérieure en fonction du champ skb->protocol et soumettez-le à la couche réseau pour traitement, entrez la pile de protocole réseau et effectuer un traitement de haut niveau.
- libpcap contourne le traitement de la pile de protocoles du processus de collecte de paquets du noyau Linux, permettant à l'API de l'espace utilisateur d'appeler directement le socket PF_PACKET pour obtenir une copie du paquet de données du pilote de couche de liaison et de le mettre en mémoire tampon à partir du La zone du noyau est copiée dans le tampon de l'espace utilisateur ("La 4ème copie")
libpcap-mmap
libpcap-mmap est une amélioration de l'ancienne implémentation de libpcap et est essentiellement utilisée dans la nouvelle versions du mécanisme libpcap packet_mmap. PACKET_MMAP réduit une copie de mémoire via mmap ("La quatrième copie a disparu"), réduit les appels système fréquents et améliore considérablement l'efficacité de la capture de paquets.
PF_RING
Nous avons vu que libpcap avait 4 copies de mémoire auparavant. libpcap_mmap dispose de 3 copies mémoire. La solution principale proposée par PF_RING est de réduire le nombre de copies des messages lors de la transmission.
Nous pouvons voir que par rapport à libpcap_mmap, pfring permet à la mémoire de l'espace utilisateur de mapper directement avec rx_buffer. Cela réduit une autre copie ( "La deuxième copie de libpcap_mmap" : rx_buffer->skb)
PF-RING ZC implémente la technologie DNA (Direct NIC Access direct network card access) pour mapper l'espace mémoire utilisateur à la mémoire du pilote. espace afin que l'application de l'utilisateur puisse accéder directement aux registres et aux données de la carte réseau.
De cette façon, la mise en mémoire tampon des paquets de données dans le noyau est évitée et une copie est réduite ("La première copie de libpcap", copie du tampon DMA vers le noyau). Il s’agit d’une copie totalement nulle.
L'inconvénient est qu'une seule application peut ouvrir l'anneau DMA à la fois (notez que les cartes réseau actuelles peuvent avoir plusieurs files d'attente RX/TX, permettant à une application d'être sur chaque file d'attente en même temps), autrement dit , plusieurs applications en mode utilisateur doivent communiquer entre elles pour distribuer des paquets de données.
DPDK
pf-ring zc et dpdk peuvent obtenir une copie nulle des paquets de données. Les deux contournent le noyau, mais les principes d'implémentation sont légèrement différents. PF-ring zc prend en charge les paquets de données via le pilote zc (également au niveau de la couche application), et dpdk est implémenté sur la base de UIO.
1 UIO+mmap implémente zéro copie
UIO (Userspace I/O) est une technologie d'E/S qui s'exécute dans l'espace utilisateur. Généralement, les périphériques pilotes des systèmes Linux s'exécutent dans l'espace noyau et peuvent être appelés par les applications dans l'espace utilisateur. Cependant, UIO exécute une petite partie du pilote dans l'espace noyau et implémente la grande majorité du pilote dans l'espace utilisateur. Fonction. Grâce au mécanisme UIO fourni par Linux, le noyau peut être contourné et tout le travail de traitement des paquets est effectué dans l'espace utilisateur.
2 UIO+PMD réduit les interruptions et le changement de contexte du processeur
Le pilote UIO de DPDK bloque les interruptions émises par le matériel, puis utilise l'interrogation active en mode utilisateur. Ce mode est appelé PMD (Poll Mode Driver).
Par rapport à DPDK, pf-ring (pas de zc) utilise l'interrogation NAPI et l'interrogation de la couche d'application, tandis que pf-ring zc est similaire à DPDK et utilise uniquement l'interrogation de la couche d'application.
3 HugePages réduisent les erreurs TLB
Après l'introduction de la MMU (Memory Management Unit) dans le système d'exploitation, le CPU doit accéder à la mémoire deux fois pour lire les données de la mémoire. La première fois consiste à interroger la table des pages pour convertir l'adresse logique en adresse physique, puis à accéder à l'adresse physique pour lire des données ou des instructions.
Afin de réduire le problème du temps de requête long causé par un trop grand nombre de pages et des tables de pages trop volumineuses, TLB (Translation Lookaside Buffer) a été introduit, qui peut être traduit comme un tampon de traduction d'adresses. Le TLB est une unité de gestion de mémoire, généralement stockée dans un registre, qui stocke une petite partie des entrées de table de pages les plus susceptibles d'être consultées actuellement.
Après l'introduction du TLB, le CPU ira d'abord au TLB pour s'adresser. Étant donné que le TLB est stocké dans un registre et ne contient qu'une petite partie des entrées de la table des pages, la vitesse de requête est très rapide. Si l'adressage dans TLB réussit (TLB hit), il n'est pas nécessaire d'interroger la table des pages dans la RAM ; si l'adressage dans TLB échoue (TLB miss), vous devez interroger la table des pages dans la RAM. Après avoir interrogé la page. sera mis à jour dans le TLB.
DPDK utilise HugePages, qui prend en charge des tailles de page de 2 Mo et 1 Go sous x86-64, ce qui réduit considérablement le nombre total de pages et la taille de la table des pages, réduisant ainsi considérablement la probabilité de manque de TLB et améliorant les performances d'adressage du processeur.
4 Autres optimisations
- SNA (Shared-nothing Architecture), l'architecture logicielle est décentralisée, essayant d'éviter le partage mondial, provoquant une concurrence mondiale et perdant la capacité de s'étendre horizontalement. Sous le système NUMA, la mémoire n'est pas utilisée à distance entre les nœuds.
- SIMD (Single Instruction Multiple Data), du premier mmx/sse au dernier avx2, les capacités du SIMD ont augmenté. DPDK utilise le traitement par lots de plusieurs paquets en même temps, puis utilise la programmation vectorielle pour traiter tous les paquets en un seul cycle. Par exemple, memcpy utilise SIMD pour augmenter la vitesse.
- affinité CPU : c'est-à-dire affinité CPU
XDP
Plan de traitement des données, xdp crée un plan rapide de données dans la couche pilote. Le paquet de données est traité avant que les données ne soient enregistrées par le matériel de la carte réseau dans la mémoire et que skb ne soit alloué.
Veuillez noter que XDP n'effectue pas de contournement du noyau sur les paquets de données, il effectue simplement une petite vérification préalable.
Par rapport à DPDK, XDP présente les avantages suivants :
Pas besoin de bibliothèques de codes et de licences tierces définir de nouveaux modèles de réseau sécurisés
-
Les scénarios d'utilisation de XDP incluent :
-
Défense DDoS
-
Pare-feu
-
Équilibrage de charge basé sur XDP_TX
-
Statistiques réseau
Échantillonnage de réseaux complexes
-
Plateforme de trading à grande vitesse
-
OK, ce qui précède est le partage d'aujourd'hui. Si vous pensez qu'il existe d'autres moteurs de collecte de paquets, vous pouvez laisser un message à partager.
-
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
