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.
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.
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.
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.
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.
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.
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.
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ésCe qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
