Gráficos en Wireshark
Posiblemente, esta sea una de las características que más se ajusten en esta serie de pruebas realizadas, y de las que más provecho podemos sacar. Gracias a los gráficos, se podrán analizar las diferencias que existen entre cada driver con más contundencia.
A priori, Wireshark nos provee varios gráficos con parámetros preestablecidos:
- Time Sequence (Stevens)
- Time Sequence (tcptrace)
- Throughput
- Round Trip Time (RTT)
- Window Scaling
Cada uno de estos gráficos aportan información vital para determinar el funcionamiento de una conexión de red. Además, Wireshark provee un gráfico (IO Graphs) totalmente configurable por el usuario mediante la utilización de filtros. En él, se pueden graficar: tráfico total, saliente, entrante, retransmisiones, reconocimientos, y cualquier información detallada que pueda ser filtrada por Wireshark.
En IO Graphs, también se pueden modificar otros aspectos como: unidades de medidas, intervalos de tiempo, colores y tipo de gráfico:
- Linea
- Barra
- Histograma
- Punto
- Rectángulo
- Rombo
En la imagen se muestra como obtengo un parámetro del puerto del servidor. Dicha información se introduce en los campos de filtros en IO Graphs:
seleccionando un filtro personalizado correspondiente al tráfico del puerto local:
El gráfico (arriba) pertenece al driver b43, y aunque ahora estoy tratando con tráfico más real, el patrón sigue siendo el mismo, la transmisión de datos varia constantemente. Aquí lo que se está expresando es la cantidad de bits/s transmitidos, por tanto, los picos descendientes son una baja en el rendimiento de red.
Lo que uno espera es una linea lo más llana posible y bien arriba, como es el caso del driver wl. Este refleja una conexión mucho más estable, por consiguiente, un mejor rendimiento.
Estos gráficos son muy fáciles de interpretar, no obstante, se pueden obtener gráficos erróneos si utilizamos mal el campo de filtros. Prefiero recurrir a los gráficos proporcionados por Wireshark para casos específicos, —los mencioné más arriba—.
Los que más me interesaron fueron: Throughput y Round Trip Time (RTT). El primero nos detalla claramente el rendimiento de red y muestra el tráfico de TCP en una sola dirección. El segundo, muestra la latencia de red (tiempo que tarda un segmento, desde que se envía, hasta su confirmación).
Ambas métricas son todo lo que necesito para dicha comparación. Veamos el Throughput del driver b43:
Más específico que los anteriores, aquí se puede observar longitud de segmentos y ancho de banda utilizado. Un pico máximo aproximado de 4.5 Mbits (562.5 Kbits), y otros pocos alrededor de 3 Mbits. La mayor parte de la transmisión transcurre en una franja de 0.6 a 1.5 Mbits. Lo que significa un muy bajo rendimiento de red.
Como se vio anteriormente, en wl se puede ver como TCP obtiene un rendimiento casi absoluto de los 6 Mbits disponibles, realmente se aprecia la estabilidad de este driver. Salvo al final, no existen altibajos en wl:
La siguiente métrica, el Round Trip Time (RTT), no es más que el tiempo de ida y vuelta de un paquete de datos enviado desde el emisor y volviendo al mismo, luego de pasar por el receptor. Además se toma en cuenta los procesos que realizan tanto el emisor como el receptor (buffers, cola, retransmisiones, etc).
Una diferencia con la herramienta ping, es que esta última viaja en una dirección, y no toma en cuenta los procesamientos. Además, utiliza paquetes ICMP. Aunque en su momento ping aportó información vital, ahora estoy probando un escenario real, y el RTT es más específico.
En estas imágenes se puede observar claramente como en b43 (arriba) la mayor parte de los reconocimientos (ACKs) están concentrados en un rango de 120 ms a 200 ms. En wl se ve realmente bien, los RTTs son muy inferiores a los expuestos arriba.
El RTT forma parte de varios algoritmos utilizados por TCP: RTO, troughput, ventana de congestión. Un valor alto del RTT tiene efectos contraproducentes, y TCP puede tomar medidas ejemplares para estabilizar la conexión, aunque perdamos rendimiento.
Una de esas medidas es reducir la ventana de recepción. Al comienzo TCP fija un tamaño mínimo de ventana, y el emisor no puede mandar más segmentos (datos) de los que el receptor pueda aceptar de acuerdo a su tamaño de ventana. El tamaño irá variando a medida que se estabiliza la transmisión de datos. Es decir que TCP irá aumentando progresivamente el tamaño de ventana, sin embargo, si se produce congestión, hará lo inverso.
Esto me lleva a los gráficos de ventana escalable:
La linea color pastel representa el tamaño de ventana, y se puede ver como fluctúa en un rango de 500000/600000 bytes, al parecer le cuesta mantener un valor fijo de tamaño de ventana y mucho menos escalarla, —problemas—.
Tamaño de ventana escalable en driver wl:
El valor máximo de tamaño de ventana es de 16 Bits (65535 valores posibles), sin embargo luego de alcanzar el máximo tamaño TCP puede ir escalando ese valor, mientras no se produzca congestión. Eso es lo que ocurre con el driver wl, rompe la barrera de 16 bits para luego escalar la ventana y mantenerse por encima de 1500000. No hay ninguna restricción por parte de TCP.
Como última observación, cabe destacar el tiempo en la descarga del paquete. Puede verse en los gráficos un tiempo aproximado de 1 min. por parte del driver wl vs 6 min. del b43 —algo más de 5 min. de diferencia entre ambas descargas—, realmente significativo este dato, pero no es de extrañar si comparamos los gráficos.
b43 vs b43
Luego de hacer las pruebas comparativas, con el driver wl, decidí realizar un último test. Esta vez será con un driver b43 de otra distribución, y otra versión del kernel. No recuerdo que este driver haya funcionado mal en los últimos años, sin embargo, nunca lo había testeado de esta forma.
Decidí utilizar una distribución de Kali Linux que tenía a mano. Con esta distro tengo la ventaja de que inicia con el driver b43 pre-instalado, más el firmware.
Especificaciones de Kali Linux:
- Kernel: 4.6.0-kali1-amd64
- Driver: b43
- Firmware versión: 666.2
Capturé la descarga del paquete emacs del mismo sitio y estos fueron los resultados:
Cualquiera de los tres gráficos que analicemos: Throughput, Window Scaling y RTT, demuestran estabilidad y un óptimo rendimiento. Además de una gran similitud con los gráficos del driver wl, lo que implica una diferencia apreciable con su homólogo (b43, Debian 10).
Conclusiones
Los resultados en Kali Linux demuestran que el driver b43 es estable, incluso por sus características, es una mejor opción a wl. Sin embargo, en Debian 10 (Buster) existe algún inconveniente con este driver (b43) que impide un máximo rendimiento de red.
Lamentablemente me es difícil determinar que causa el problema en este driver en particular. Algunos factores pudieran estar involucrados en el problema: Kernel, Network-manager, modificación en el firmware, compilación, etc. Hasta que no encuentre una solución en Debian 10, utilizaré el driver wl. Si bien, es más limitado en características, me ofrece el mayor rendimiento que puedo obtener.
Fuente:
https://es.wikipedia.org/wiki/Rendimiento_de_red
https://www.wireshark.org/docs/wsug_html_chunked/
¿Te resultó interesante? Compártelo ...
Receurda que Kali es una distribucion hecha para eso, sabe dios que modificaciones le habran hecho al kernel o al driver para que funcione bien, prueba con otra distribucion mas de uso general a ver que pasa. Saludos, muy buenos tus artículos
Gracias kpo-259.
Ciertamente, es probable que sea el kernel. Hice un volcado hexadecimal y ambos drivers son idénticos.
Me queda por comprobar el firmware (Kali-Debian), si son idénticos el problema yace en alguna comunicación del driver con alguna librería externa, o algún módulo que Debian incluye por defecto en el kernel. Probaré otra distribución para quitarme la duda.
Saludos.