Al capturar el tráfico de red para la depuración, parece haber dos enfoques comunes:
Use un enchufe sin procesar.
Utilice libcap.
En cuanto al rendimiento, ¿hay mucha diferencia entre estos dos enfoques? libpcap parece una buena forma compatible de escuchar una conexión de red real o reproducir algunos datos enlatados, pero ¿ese conjunto de características viene con un impacto en el rendimiento?
La respuesta pretende explicar más sobre libpcap.
libpcap usa PF_PACKET para capturar paquetes en una interfaz. Consulte el siguiente enlace. https://www.kernel.org/doc/Documentation/networking/packet_mmap.txt
Desde el enlace de arriba
En Linux 2.4/2.6/3.x si PACKET_MMAP no está habilitado, el proceso de captura es muy ineficiente. Utiliza búferes muy limitados y requiere una llamada al sistema para capturar cada paquete, requiere dos si desea obtener la marca de tiempo del paquete (como siempre lo hace libpcap). Por otro lado, PACKET_MMAP es muy eficiente. PACKET_MMAP proporciona un búfer circular de tamaño configurable mapeado en el espacio del usuario que se puede usar para enviar o recibir paquetes. De esta manera, la lectura de paquetes solo necesita esperarlos, la mayoría de las veces no es necesario realizar una sola llamada al sistema. En cuanto a la transmisión, se pueden enviar múltiples paquetes a través de una llamada al sistema para obtener el mayor ancho de banda. El uso de un búfer compartido entre el núcleo y el usuario también tiene la ventaja de minimizar las copias de paquetes.
la mejora del rendimiento puede variar según la implementación de PF_PACKET que se utilice.
De https://www.kernel.org/doc/Documentation/networking/packet_mmap.txt -
Se dice que TPACKET_V3 trae los siguientes beneficios: *) ~15 - 20% de reducción en el uso de CPU *) ~20% de aumento en la tasa de captura de paquetes
La desventaja de usar libpcap -
Si una aplicación necesita retener el paquete, es posible que deba hacer una copia del paquete entrante.
Consulte la página de manual de pcap_next_ex.
pcap_next_ex() lee el siguiente paquete y devuelve una indicación de éxito/fracaso. Si el paquete se leyó sin problemas, el puntero al que apunta el argumento pkt_header se establece para que apunte a la estructura pcap_pkthdr del paquete, y el puntero al que apunta el argumento pkt_data se establece para que apunte a los datos del paquete. La estructura pcap_pkthdr y los datos del paquete no deben ser liberados por la persona que llama, y no se garantiza que sean válidos después de la siguiente llamada a pcap_next_ex(), pcap_next(), pcap_loop() o pcap_dispatch(); si el código necesita que sigan siendo válidos, debe hacer una copia de ellos.
Penalización de rendimiento si la aplicación solo está interesada en los paquetes entrantes.
PF_PACKET funciona como derivaciones en el núcleo, es decir, todos los paquetes entrantes y salientes se envían a PF_SOCKET. Lo que resulta en una costosa llamada a package_rcv para todos los paquetes salientes. Dado que libpcap usa PF_PACKET, libpcap puede capturar todos los paquetes entrantes y salientes. si la aplicación solo está interesada en los paquetes entrantes, los paquetes salientes se pueden descartar configurando pcap_setdirection en el identificador libpcap. libpcap descarta internamente los paquetes salientes al verificar las banderas en los metadatos del paquete. Entonces, en esencia, los paquetes salientes todavía son vistos por libpcap pero solo para ser descartados más tarde. Esta es una penalización de rendimiento para la aplicación que solo está interesada en los paquetes entrantes.
El paquete sin procesar funciona en el nivel de IP (capa 3 de OSI), pcap en la capa de enlace de datos (capa 2 de OSI). Por lo tanto, es menos un problema de rendimiento y más una cuestión de lo que desea capturar. Si el rendimiento es su principal problema, busque PF_RING, etc., eso es lo que usan los IDS actuales para capturar.
Editar: los paquetes sin procesar pueden ser de nivel IP (AF_INET) o capa de enlace de datos (AF_PACKET), pcap podría usar sockets sin procesar, consulte ¿Utiliza libpcap sockets sin procesar debajo de ellos?