Quiero capturar paquetes de la tarjeta de red de 10 Gbps con 0 pérdida de paquetes. Estoy usando lipcap para 100Mbps NIC y está funcionando bien. ¿Libpcap podrá gestionar el tráfico de NIC a 10 Gbps? Si no, ¿cuáles son las otras formas alternativas de lograr esto?libpcap para capturar 10 Gbps NIC
Si libpcap manejará o no 10Gbps con 0 pérdida de paquete es una cuestión de la máquina que está utilizando y la versión de libpcap. Si la máquina, la CPU y la E/S de HDD son lo suficientemente rápidas, es posible que pierda 0 paquetes. De lo contrario, es posible que deba realizar las siguientes acciones:
Actualice su libpcap a la versión más reciente. Libpcap 1.0.0 o posterior, supone un mecanismo de copia cero (memoria asignada). Significa que hay un búfer que está tanto en el espacio de direcciones del núcleo como en el espacio de direcciones de la aplicación, por lo que no es necesario copiar los datos desde un búfer en modo kernel a un búfer en modo usuario. Los paquetes aún se copian del skbuff (Linux) en el búfer compartido, por lo que se parece más a "una copia", pero esa es una copia menos, por lo que podría reducir el tiempo de CPU requerido para recibir paquetes capturados. Además, se pueden obtener más paquetes del búfer por llamada de activación de la aplicación.
Si observa una alta utilización de CPU, es probable que su CPU no pueda manejar la velocidad de llegada del paquete. Puede usar xosview (una herramienta de visualización de carga del sistema) para verificar los recursos de su sistema durante la captura.
Si la CPU descarta paquetes, puede usar PF_RING. PF_RING es una extensión de libpcap con un buffer circular: http://www.ntop.org/products/pf_ring/. Es mucho más rápido y puede capturar con 10 Gbps con las NIC básicas http://www.ntop.org/products/pf_ring/hardware-packet-filtering/.
Otro enfoque es obtener una tarjeta de interfaz de red que tenga una memoria incorporada y un diseño HW específico para la captura de paquetes, consulte http://en.wikipedia.org/wiki/DAG_Technology.
Si la CPU ya no es su problema, debe probar la velocidad de transferencia de datos del disco. hdparm es la herramienta más simple en Linux. Algunas distribuciones vienen con una interfaz gráfica de usuario, de lo contrario: $ sudo hdparm -tT /dev/hda
Si está desarrollando su propia aplicación basada en libpcap:
Use pcap_stats para identificar (a) el número de paquetes descartados porque hay no había espacio en el búfer del sistema operativo cuando llegaron, porque los paquetes no se leían lo suficientemente rápido; (b) cantidad de paquetes eliminados por la interfaz de red o su controlador.
Libpcap 1.0.0 tiene una API que permite a una aplicación establecer el tamaño del búfer, en plataformas donde se puede establecer el tamaño del búfer. b) Si le resulta difícil establecer el búfer, puede utilizar Libpcap 1.1.0 o posterior en el que el tamaño del búfer de captura predeterminado se ha aumentado de 32 K a 512 K. c) Si se acaba usando tcpdump, utilice 4.0.0 o posterior y usar la bandera -B para el tamaño de la memoria intermedia de
PF_RING es una buena solución alternativa puede ser netsniff-ng (http://netsniff-ng.org/) . Para ambos proyectos, la ganancia de rendimiento se alcanza mediante mecanismos de copia cero. Obviamente, el cuello de botella puede ser el HD, su tasa de transferencia de datos.
Usted no dice qué sistema operativo o la CPU. No importa si elige libpcap o no, el rendimiento de la red subyacente aún está cargado por la gestión de memoria del sistema operativo y su controlador de red. libpcap se ha mantenido al día y puede manejar 10Gbps, pero hay más.
Si desea la mejor CPU para hacer números, ejecutar máquinas virtuales y capturar paquetes, vaya con la CPU AMD Opteron que todavía supera a la de Intel Xeon Quadcore 5540 2.53GHz (a pesar de la introducción de XIO/DDIO de Intel y debido a Intel dual-core sharing de la misma caché L2). Para un mejor sistema operativo ya hecho, ir con la última FreeBSD como está (que todavía supera a Linux 3.10 en red utilizando hardware básico.) De lo contrario, Intel y Linux funciona muy bien para la captura de 10 Gbps sin soltar básica, siempre y cuando esté deseoso de enrollar tus mangas
Si usted está empujando a toda velocidad todo el tiempo mientras se hace financiera o de tipo estocástico o grande de cálculo de matrices de predicción computacional (o algo así), a continuación, leer sobre ...
Como RedHat tener discovered, 67,2 nanosegundo es lo que se necesita para procesar un paquete de tamaño mínimo a una velocidad de 10 Gbps. Afirmo que está más cerca de 81.6 nanosegundos para la carga útil Ethernet de 64 bytes, pero están hablando de un mínimo de 46 bytes como teórico.
En resumidas cuentas, usted no será capaz de hacer o utilizar cualquiera de los siguientes si desea caída de paquetes 0% a tasa completa por permanecer bajo 81,6 ns para cada paquete:
ethtool -C rx-frames 1024+).malloc() (hay que sustituirlo por uno más rápido, preferentemente enorme basada en uno)Así, Linux tiene una ventaja sobre FreeBSD para capturar la tasa de 10 Gbps en una tasa de caída del 0% Y ejecutar varias máquinas virtuales (y otras sobrecargas). Solo que requiere una nueva gestión de memoria (MM) de algún tipo para un dispositivo de red específico y no necesariamente para todo el sistema operativo. La mayoría de los nuevos controladores de red de súper alto desempeño ahora están haciendo que los dispositivos usen ENORME memoria que se asignaron en el usuario y luego usan llamadas de controladores para pasar un paquete de paquetes a la vez.
Muchos MM nueva red-driver haber reutilizados están fuera (en ningún orden particular):
El nivel de madurez de cada código depende en gran medida de la versión de Linux (o distro) que elija. He intentado algunos de ellos y una vez que entendí el diseño básico, se hizo evidente lo que necesitaba. YMMV.
Buena suerte.
Si tiene tiempo, pase a Intel DPDK. Permite el acceso de copia cero al registro de hardware de NIC. Pude lograr caídas de 0% a 10 Gbps, 1.5Mpps en un solo núcleo. Estarás mejor a la larga
Sí, he tenido muchas dificultades con los controladores Intel IXFGB. Es tan sensible al estar vinculado a versiones específicas del kernel de Linux. –
Depende de la cantidad de procesador que arrojes ... eso debería haber sido obvio. –