Anonim

¿Qué es el flent?

enlaces rápidos

  • ¿Qué es el flent?
  • Instalar Flent
    • Ubuntu
    • Debian
    • Arco
    • Gentoo
    • Todos los demás
  • Configuración básica
  • Ejecutando una prueba
  • Los exámenes
    • RRUL
    • RTT
    • TCP
    • Inundación UDP
  • Pensamientos finales

Flent significa FLE xible N etwork T ester, y no es un gran programa por derecho propio. En cambio, Flent es un contenedor que agrupa múltiples aplicaciones de prueba de red, especialmente Netperf, en un paquete cohesivo que simplifica la ejecución de las pruebas e incluye Matplotlib para crear gráficos y visualizaciones de datos automáticamente a medida que ejecuta sus pruebas.

Flent es un completo kit de herramientas para probar su red y diagnosticar todo, desde la simple ineficiencia hasta problemas de conexión graves. Como otra ventaja adicional, es gratis y de código abierto.

Instalar Flent

Flent solo está disponible para Mac y Linux. Eso no significa que deba deshacerse de Windows y convertir toda su red a Linux. Solo necesita encontrar alguna forma de ejecutarlo temporalmente para sus pruebas.

Ubuntu

Comience agregando el Flent PPA.

$ sudo add-apt-repository ppa: tohojo / flent $ sudo apt update

Luego, instala Flent.

$ sudo apt install flent

Debian

Flent está disponible en los repositorios oficiales de Debian que comienzan con Stretch. Solo instálalo.

# apt install flent

Arco

Flent está disponible de la AUR. Ve a su página y toma lo que necesites.

Gentoo

Agregue Flent a su '/etc/portage/package.accept_keywords'.

analizador de red / flent ~ amd64

Entonces, emergelo.

# emerge - pregunte flent

Todos los demás

Flent es un paquete de Python. Debería poder instalarlo utilizando el administrador de paquetes pip Python, si lo tiene instalado. Está disponible para casi todas las distribuciones de Linux y Homebrew para Mac.

# pip install flent

Configuración básica

Ahora que tiene instalado Flent, puede comenzar a usarlo para realizar algunas pruebas básicas. Flent tiene una línea de comandos y una versión gráfica. Dado que probablemente no desee memorizar los comandos de Flent, esta guía funcionará con la GUI.

Para que Flent funcione correctamente, necesita un servidor para probarlo. Ese servidor necesita ejecutar Netperf en modo servidor. Es mejor configurarlo primero, para que puedan hacer todas sus pruebas juntos. Netperf está disponible en casi todos los repositorios de distribución de Linux, así que simplemente instálelo con su administrador de paquetes.

$ sudo apt install netperf

Después de tenerlo en el servidor, ejecute Netperf en modo servidor.

$ sudo netserver y

Puede dejar el servidor solo por ahora. Continuará ejecutando Netperf en modo servidor en segundo plano. Puede hacer todo lo demás desde su cliente ejecutando Flent.

Ejecutando una prueba

Puede ejecutar pruebas a su servidor desde Flent, ahora. Abra la GUI de Flent desde el iniciador de su aplicación o escribiendo flent-gui en una terminal. La ventana que obtendrás es bastante simple para empezar. Haga clic en "Archivo" en la esquina superior izquierda y seleccione "Ejecutar nueva prueba" en el menú resultante.

La nueva ventana le permitirá seleccionar una prueba para ejecutar. Primero, use el menú desplegable "Nombre de prueba" para seleccionar una prueba. Para este primero, seleccione "rrul". Ingrese la IP de la computadora que configuró como servidor, luego asigne un nombre a su prueba. El nombre solo lo ayudará a identificar los resultados que guarda Flent. Utiliza una forma comprimida de JSON con la extensión .gz. Cuando todo se ve bien, haga clic en el botón "Ejecutar prueba" en la parte inferior izquierda de la ventana.

Todas las pruebas tardan un poco en ejecutarse, así que tenga paciencia e intente no hacer nada en la red con esas dos computadoras que puedan interferir con la conexión. Arruinará sus datos.

Una vez completada la prueba, podrá ver los datos relevantes presentados en una serie de gráficos en la ventana principal de Flent. La prueba RRUL le dará información sobre su carga, descarga y ping totales. Todos los cuadros le mostrarán esa misma información, pero la organizan de manera diferente para ayudarlo a notar cualquier patrón. En el caso del ejemplo, un enrutador de basura creó cargas de latencia y produjo algunos resultados bastante rotos.

Los exámenes

Flent proporciona una amplia variedad de pruebas. Cada uno puede estresar su red de una manera diferente. Sin embargo, no es necesario memorizarlos a todos. La mayoría se dividen en una de las cuatro categorías básicas. Esas categorías prueban su red de diferentes maneras específicas.

RRUL

RRUL significa R ealtime R esponse U nder L oad. Eso es exactamente lo que pretende medir. La prueba RRUL intenta simular una carga de trabajo de red real y capturar la forma en que la máquina objetivo responde bajo esa carga. RRUL fue desarrollado por la gente de Bufferbloat.net para crear condiciones de red donde el bufferbloat entraría en juego para ayudar a diagnosticarlo y remediarlo.

Bufferbloat es un problema común en las redes. Ocurre cuando un enrutador almacena demasiados datos al transferir una gran cantidad de datos o transmitir. Ese búfer adicional es un peso en el enrutador y ralentiza la transferencia. El esfuerzo de la prueba RRUL está diseñado para poner una carga lo suficientemente significativa en el enrutador para activar el búfer. Si su red está experimentando un bloqueo de búfer, los números de carga y descarga comenzarán a disminuir y el ping aumentará a medida que se ejecute la prueba.

Intente ejecutar la prueba de torrents RRUL. Simula una descarga de torrent, que obviamente es un tipo de actividad de red muy extenuante y sigue siendo un escenario del mundo real.

Los resultados anteriores son lo que no desea ver, cargas de latencia y paquetes descartados. Esa prueba se realizó entre dos dispositivos inalámbricos en una red abarrotada. Observe el cambio cuando el servidor está conectado.

La diferencia es definitivamente notable. La conexión no es perfecta, pero se vuelve mucho más estable con un dispositivo conectado. ¿Qué hay de ambos?

Hay mucha menos variación en esta prueba. Esto se debe a que no hay oportunidad de interferencia o falta de intensidad de la señal. Tenga en cuenta que esta es la misma red que el desastre de una prueba anterior. Claramente, hay un problema con las conexiones inalámbricas. Finalmente, intente probar en el servidor remoto proporcionado por Bufferbloat.net.

No es tan limpio como la red local, pero aún así no es tan complicado como las pruebas inalámbricas. Este es el tipo de cosas que probablemente esperarías de una descarga normal de torrents a través de Internet.

RTT

Las pruebas RTT o R tund T rip T ransfer son en realidad muy parecidas a las pruebas RRUL. No confían en que el objetivo esté bajo una carga. En cambio, solo miden el tiempo que tarda una solicitud UDP en completar el circuito y regresar al cliente. Incluyen ping también.

Para una buena prueba de RTT, intente ejecutar RTT Fair. Ya has probado el RRUL para simular una condición más realista y desafiante; ¿Por qué no más circunstancias ideales? La prueba RTT Fair lo ayudará a ver cómo se ve un viaje de ida y vuelta en condiciones más controladas en su red. Es considerablemente menos caótico. Sin embargo, ¿podría ser aún menos caótico? Estos son los resultados con un servidor con cable.

Es casi una ola de pecado. Claro, no es ideal, pero es más ordenado y considerablemente más rápido. Con ambas máquinas conectadas, se pone aún mejor.

Esa es una gran diferencia con respecto a los 40Mb / s en la primera prueba. Una vez más, lleve la prueba a la red.

Todavía es mejor que ese desastre de WiFi de antes. Una vez más, estos resultados parecen adecuados para una prueba como esta, aunque una mayor estabilidad podría ser un objetivo.

TCP

Las pruebas TCP son TCP estándar. Miden las solicitudes TCP básicas como si estuviera visitando un sitio web o revisando su correo electrónico. Lo más probable es que estas pruebas no pongan tanto estrés en su red, pero pueden darle una mejor idea de cómo se ve el tráfico regular.

Pruebe una prueba TCP más extenuante. La descarga TCP con 12 transmisiones es buena para simular una descarga directa más intensa. Hay una buena posibilidad de que vea una latencia seria, si no tiene una gran red. Tal vez un servidor con cable puede mejorar las cosas aquí también.

Está algo más normalizado y hay más ancho de banda. Eso es bueno. Hay aún más mejoras cuando el cliente está conectado.

Esto realmente se acercó a un sólido 1Gb / s. Eso es bastante sorprendente, teniendo en cuenta los resultados de WiFi. Finalmente, observe cómo se desempeñó con el servidor remoto.

Hay más latencia, pero las velocidades siguen siendo muy respetables. Ah, y esto también fue por una VPN. Claramente, el problema proviene del interior de la red.

Inundación UDP

Las pruebas de inundación UDP son en realidad pruebas RTT, pero envían una avalancha de paquetes UDP a la máquina de destino a la vez. No responden ni se adaptan al flujo del tráfico, solo envían. Pueden ser útiles para probar cómo responderá la máquina objetivo ante un error o un ataque.

Pensamientos finales

Si va a probar su red, es mejor probar entre diferentes puntos de su red para ayudar a reducir las áreas problemáticas. La red de prueba de esta guía claramente tiene algunos problemas con WiFi. Lo más probable es que el ancho de banda limitado y la interferencia estén en juego. También es bueno tener una idea clara de los tipos de problemas que está buscando. Diseña tus pruebas alrededor de eso.

Es posible que haya notado que la red de la que provienen los resultados no es tan buena. No es. En realidad, algunos de los resultados basura que vio son exactamente lo que necesita buscar en su propia red.

Pon a prueba la fuerza de tu red con flent