La capture de performance avec le ppce vs raw socket

La réponse est destinée à donner plus de détail sur la libpcap.

libpcap utilise le PF_PACKET pour la capture de paquets sur une interface. Consulter le lien suivant.
https://www.kernel.org/doc/Documentation/networking/packet_mmap.txt

À partir du lien ci-dessus

Dans Linux 2.4/2.6/3.x si PACKET_MMAP n'est pas activé, le processus de capture est très
inefficaces. Il utilise très limitée tampons et nécessite un système d'appel à l'
la capture de chaque paquet, il nécessite deux si vous souhaitez obtenir des paquets d'horodatage
(comme libpcap le fait toujours).
Dans l'autre main PACKET_MMAP est très efficace. PACKET_MMAP offre une taille 
configurable tampon circulaire mappé dans l'espace utilisateur qui peuvent être utilisées soit pour
envoyer ou recevoir des paquets. De cette façon, la lecture des paquets juste besoin d'attendre pour eux,
la plupart du temps il n'est pas nécessaire de faire un seul appel système. Concernant
la transmission, plusieurs paquets peuvent être envoyés via un appel système pour obtenir le
bande passante la plus élevée. En utilisant une mémoire tampon partagée entre le noyau et l'utilisateur
a aussi l'avantage de minimiser les paquets de copies.

l'amélioration de la performance peut varier en fonction de la PF_PACKET mise en œuvre est utilisée. 

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

Il est dit que TPACKET_V3 apporte les avantages suivants:
 *) ~15 - 20% de réduction de la CPU, l'utilisation de la
 *) ~20% d'augmentation de la capture de paquets taux

L'inconvénient de l'utilisation de libpcap -

1. Si une application a besoin pour tenir le paquet puis il a besoin pour rendre
   une copie du paquet entrant.

   Reportez-vous à la page de manuel de pcap_next_ex.

   pcap_next_ex() lit le prochain paquet et renvoie un succès/échec indication. Si le paquet a été lu sans problèmes, le pointeur
   pointé par le pkt_header argument est mis au point à l'
   pcap_pkthdr struct pour le paquet, et le pointeur pointé par le
   pkt_data argument a la valeur du point de données dans le paquet. L'
   struct pcap_pkthdr et le paquet de données ne sont pas à être libéré par le
   de l'appelant, et ne sont pas garantis pour être valide après l'appel suivant à
   pcap_next_ex(), pcap_next(), pcap_loop(), ou pcap_dispatch(); si le
   le code doit rester valide, il doit en faire une copie.

2. De la Performance, si la demande uniquement intéressé en entrant
   des paquets.

   PF_PACKET fonctionne comme les robinets dans le noyau, c'est à dire tous les paquets entrants et sortants sont livrés à PF_SOCKET.  ce Qui résulte en un cher appel à packet_rcv pour tous les paquets sortants.  Depuis libpcap utilise le PF_PACKET, donc libpcap peut capturer tous les entrants ainsi les paquets sortants.
   si l'application est seulement intéressé par les paquets entrants puis les paquets sortants peuvent être ignorées par la mise en pcap_setdirection sur la libpcap poignée. libpcap en interne ignore les paquets sortants en vérifiant les indicateurs sur le paquet de métadonnées.
   Donc, en substance, les paquets sortants sont toujours considérés par la libpcap, mais seulement à être jetés plus tard. C'est sur les performances de l'application qui est intéressé dans les paquets entrants uniquement.

OriginalL'auteur user3511903