Capture des performances avec pcap vs socket brut

La réponse est destinée à expliquer plus sur le libpcap.

libpcap utilise le PF_PACKET pour capturer des paquets sur une interface. Reportez-vous au lien suivant. https://www.kernel.org/doc/Documentation/networking/packet_mmap.txt

À partir du lien ci-dessus

Sous Linux 2.4 / 2.6 / 3.x si PACKET_MMAP n’est pas activé, le processus de capture est très inefficace. Il utilise des tampons très limités et nécessite un appel système pour capturer chaque paquet, il en faut deux pour obtenir l’horodatage du paquet (comme le fait toujours libpcap). D’autre part, PACKET_MMAP est très efficace. PACKET_MMAP fournit un tampon circulaire configurable en taille, mappé dans l’espace utilisateur, qui peut être utilisé pour envoyer ou recevoir des paquets. De cette façon, la lecture des paquets doit simplement les attendre, la plupart du temps, il n’est pas nécessaire de lancer un seul appel système. En ce qui concerne la transmission, plusieurs paquets peuvent être envoyés via un appel système pour obtenir la bande passante la plus élevée. L’utilisation d’un tampon partagé entre le kernel et l’utilisateur présente également l’avantage de minimiser les copies de paquets.

l’amélioration des performances peut varier en fonction de l’implémentation de PF_PACKET.

De https://www.kernel.org/doc/Documentation/networking/packet_mmap.txt –

On dit que TPACKET_V3 apporte les avantages suivants: *) Réduction de 15 à 20% de l’utilisation du processeur * Augmentation de 20% du taux de capture de paquets

L’inconvénient d’utiliser libpcap –

1. Si une application doit contenir le paquet, il peut être nécessaire de faire une copie du paquet entrant.

   Reportez-vous à la page de manuel de pcap_next_ex.

   pcap_next_ex () lit le paquet suivant et renvoie une indication succès / échec. Si le paquet a été lu sans problème, le pointeur désigné par l’argument pkt_header est défini pour pointer vers la structure pcap_pkthdr du paquet et le pointeur désigné par l’argument pkt_data est défini pour pointer vers les données du paquet. La structure pcap_pkthdr et les données de paquet ne doivent pas être libérées par l’appelant et leur validité n’est pas garantie après le prochain appel à pcap_next_ex (), pcap_next (), pcap_loop () ou pcap_dispatch (); si le code en a besoin pour restr valide, il doit en faire une copie.

2. Pénalité de performance si l’application ne s’intéresse qu’aux paquets entrants.

   PF_PACKET fonctionne comme des taps dans le kernel, c’est-à-dire que tous les paquets entrants et sortants sont livrés à PF_SOCKET. Ce qui entraîne un appel coûteux à packet_rcv pour tous les paquets sortants. Comme libpcap utilise PF_PACKET, libpcap peut donc capturer tous les paquets entrants et sortants. Si l’application ne s’intéresse qu’aux paquets entrants, les paquets sortants peuvent être ignorés en définissant pcap_setdirection sur le handle de libpcap. libpcap élimine en interne les paquets sortants en vérifiant les indicateurs sur les métadonnées du paquet. Donc, essentiellement, les paquets sortants sont toujours vus par libpcap, mais seulement pour être éliminés plus tard. C’est une pénalité de performance pour l’application qui s’intéresse uniquement aux paquets entrants.

Le paquet brut fonctionne au niveau IP (couche OSI 3), pcap sur la couche liaison de données (couche OSI 2). Donc, c’est moins un problème de performance et plus une question de ce que vous voulez capturer. Si les performances sont votre principale recherche de problème pour PF_RING, etc., c’est ce que les IDS actuels utilisent pour la capture.

Edit: les paquets bruts peuvent être de niveau IP (AF_INET) ou de couche de liaison de données (AF_PACKET), pcap peut en fait utiliser des sockets bruts, voir Est – ce que libpcap utilise des sockets bruts en dessous?