rperf
v0.1.8
rperf es una alternativa de iperf basada en Rust desarrollada por 3D-P, con el objetivo de evitar algunos problemas de confiabilidad y consistencia que se encuentran en iperf3 , al mismo tiempo que proporciona datos de métricas más ricos, con un enfoque en la operación en un entorno más tolerante a las pérdidas y más similar a IoT. Si bien se puede utilizar como un reemplazo casi directo de iperf , y puede haber beneficios al hacerlo, se centra en la recopilación periódica de datos en una capacidad de monitoreo en una red cerrada, lo que significa que no es adecuado para todos los dominios. que iperf puede servir.
rperf es una implementación independiente, que hace referencia a los algoritmos de iperf3 y zapwireless para evaluar la corrección y derivar correcciones adecuadas, pero no copia ningún código de ninguno de los dos.
En particular, las cuestiones más importantes abordadas desde iperf3 son las siguientes:
Cualquier servidor determinado admite varios clientes simultáneos.
La implementación de rperf de RFC 1889 para el cálculo de la fluctuación de transmisión comienza asumiendo un delta entre el primer y el segundo paquete en una secuencia y los espacios en una secuencia desencadenan un reinicio del conteo. Comparativamente, iperf3 comienza con 0, lo que crea valores artificialmente bajos, y en caso de una brecha, simplemente continúa ingenuamente, lo que crea valores artificialmente altos.
Los paquetes duplicados se contabilizan en los intercambios UDP y los paquetes desordenados se cuentan como eventos independientes.
Todo el tráfico se puede emitir proporcionalmente a intervalos regulares de menos de un segundo, lo que permite configuraciones que reflejan con mayor precisión la transmisión de datos reales y los algoritmos de envío.
La configuración de la transmisión y los resultados se intercambian a través de una conexión dedicada y cada ruta de datos tiene una semántica de tiempo de espera, finalización y falla claramente definida, por lo que la ejecución no se suspende indefinidamente en ninguno de los lados de una prueba cuando se pierden paquetes clave.
La salida JSON de rperf es estructuralmente legal. Sin cadenas sin comillas, claves repetidas ni comas colgantes, todo lo cual requiere un procesamiento previo antes de su consumo o causa errores inesperados.
A diferencia de zapwireless , se realizan las siguientes mejoras:
rperf utiliza una arquitectura cliente-servidor clásica, por lo que no es necesario mantener un proceso en ejecución en dispositivos que esperan una solicitud de ejecución de prueba.
Se calcula la inquietud.
Se admite IPv6.
Se pueden ejecutar varios flujos en paralelo como parte de una prueba.
Hay una opción omit disponible para descartar el tiempo de aceleración de TCP de los resultados.
La salida está disponible en JSON para facilitar la recolección de telemetría.
rperf debería compilarse y funcionar en todas las plataformas principales, aunque su desarrollo y uso se centra en sistemas basados en Linux, por lo que es allí donde tendrá más funciones.
Se aceptan solicitudes de extracción para implementaciones de funciones equivalentes para otros sistemas.
Todo se describe en el resultado de --help y la mayoría de los usuarios familiarizados con herramientas similares deberían sentirse cómodos de inmediato.
rperf funciona de manera muy similar a iperf3 , compartiendo muchos conceptos e incluso indicadores de línea de comandos. Un área clave en la que se diferencia es que el cliente controla todo el proceso de configuración, mientras que el servidor simplemente cumple lo mejor que puede y proporciona un flujo de resultados. Esto significa que el servidor no presentará los resultados de las pruebas directamente a través de su interfaz y también que las pruebas TCP y UDP se pueden ejecutar en la misma instancia, potencialmente por muchos clientes simultáneamente.
En su modo normal de operación, el cliente cargará datos al servidor; cuando se establece la bandera reverse , el cliente recibirá datos.
A diferencia de iperf3 , rperf no utiliza un rango de puertos reservado de forma predeterminada. Esto es para que pueda admitir una cantidad arbitraria de clientes en paralelo sin contención de recursos en lo que prácticamente solo puede ser una pequeña cantidad de puertos contiguos. En su capacidad prevista, esto no debería ser un problema, pero cuando se trata de firewalls no permisivos y configuraciones NAT, las opciones --tcp[6]-port-pool y --udp[6]-port-pool pueden ser útiles. Se utiliza para asignar puertos no contiguos al conjunto que se utilizará para recibir tráfico.
Tampoco existe el concepto de probar el rendimiento en relación con una cantidad fija de datos. Más bien, el único objetivo es medir el rendimiento durante un período de tiempo aproximadamente conocido.
También es relevante que, si el servidor se ejecuta en modo IPv6 y su host admite el mapeo de IPv4 en una configuración de doble pila, tanto los clientes IPv4 como IPv6 pueden conectarse a la misma instancia.
rperf utiliza carga . El proceso típico será simplemente cargo build --release .
cargo-deb también es compatible y producirá un paquete Debian utilizable que instala un servicio rperf systemd deshabilitado por defecto. Cuando se inicia, se ejecuta como nobody:nogroup , suponiendo que sea compatible con IPv6 de forma predeterminada.
Al igual que sus contemporáneos, el concepto central de rperf es disparar un flujo de datos TCP o UDP a un objetivo IP a una velocidad objetivo preestablecida. La cantidad de datos realmente recibidos se observa y se utiliza para medir la capacidad de un enlace de red.
Dentro de esos dominios, se recopilan datos adicionales sobre la calidad del intercambio y se ponen a disposición para su revisión.
Arquitectónicamente, rperf hace que los clientes establezcan una conexión TCP con el servidor, después de lo cual el cliente envía detalles sobre la prueba a realizar y el servidor lo obliga, informando los resultados de la observación al cliente durante todo el proceso de prueba.
El cliente puede solicitar que se utilicen múltiples flujos paralelos para las pruebas, lo que se facilita estableciendo múltiples conexiones TCP o sockets UDP con su propio subproceso dedicado en cada lado, que se puede anclar a un único núcleo lógico de CPU para reducir el impacto de la página. -fallos en el intercambio de datos.
La relación cliente-servidor se trata como un aspecto muy central de este diseño, en contraste con iperf3 , donde son más como pares, y zapwireless , donde cada participante ejecuta su propio demonio y un tercer proceso orquesta la comunicación.
En particular, toda la recopilación, el cálculo y la visualización de datos se realizan en el lado del cliente, y el servidor simplemente devuelve lo que observó. Esto puede provocar cierta variación en las grabaciones, especialmente en lo que respecta al tiempo (no es nada raro que los intervalos del servidor sean unos pocos milisegundos más largos que los valores correspondientes del cliente). Sin embargo, suponiendo que la conexión no se haya perdido, los totales de los datos observados coincidirán en todos los modos de operación.
El servidor utiliza tres capas de subprocesos: una para el subproceso principal, una para cada cliente al que se presta servicio y una más para cada secuencia que se comunica con el cliente. En el lado del cliente, el hilo principal se utiliza para comunicarse con el servidor y genera un hilo adicional para cada flujo que se comunica con el servidor.
Cuando el servidor recibe una solicitud de un cliente, genera un hilo que maneja la solicitud específica de ese cliente; Internamente, cada flujo de la prueba produce un controlador similar a un iterador en cada lado. Tanto el cliente como el servidor ejecutan estos iteradores análogos entre sí de forma asincrónica hasta que finaliza el período de prueba, momento en el que el remitente indica la finalización dentro de su flujo.
Para manejar de manera confiable la posibilidad de desconexiones a nivel de flujo, un mecanismo de mantenimiento de actividad en el flujo cliente-servidor, a través del cual se envían los resultados de las pruebas desde el servidor a intervalos regulares, finalizará las conexiones pendientes después de unos segundos de inactividad.
Los mecanismos TCP y UDP del sistema operativo host se utilizan para todo el tráfico real intercambiado, con algunos parámetros de ajuste expuestos. Se eligió este enfoque en lugar de una implementación de espacio de usuario sobre la capa 2 o la capa 3 porque representa con mayor precisión la forma en que se comportarán las aplicaciones del mundo real.
Los valores de "marca de tiempo" visibles en los datos de intervalo serializados JSON son relativos al host, por lo que, a menos que su entorno tenga una precisión muy alta del reloj del sistema, las marcas de tiempo de envío solo deben compararse con otras marcas de tiempo de envío y también con las marcas de tiempo de recepción. Sin embargo, en general, estos datos no son útiles fuera de la validación de la corrección.
Durante cada intervalo de intercambio, se intenta enviar bytes length a la vez, hasta que la cantidad escrita en el flujo cumpla o supere el objetivo de ancho de banda, momento en el que el remitente permanece en silencio hasta el inicio del siguiente intervalo; los datos enviados dentro de un intervalo deben distribuirse uniformemente a lo largo del período.
Los índices de flujo comienzan en 0 , no en 1 . Probablemente esto no sorprenda a nadie, pero ver "flujo 0" en un informe no es motivo de preocupación.
rperf es distribuido por Evtech Solutions, Ltd., dba 3D-P, bajo la versión 3 de GNU GPL, cuyo texto se puede encontrar en COPYING .
Los detalles de autoría, los derechos de autor y las notas de transferibilidad están presentes en el propio código fuente.
