Metrología y medición del rendimiento

1. Definición de metrología

La metrología forma parte integrante de la supervisión. En términos generales, se refiere a la ciencia de la medición que se aplica en numerosos ámbitos, especialmente en las redes informáticas. Más allá de la simple medición, la metrología se aplica para garantizar la medición e interpretarla.

Los usuarios se quejan de una red lenta, de un mal rendimiento al descargar archivos de la nube, de una aplicación que tarda demasiado en responder: ¿Cómo resolver estos problemas sin elementos cuantificables y comparables? ¿Cómo medir el tiempo de respuesta de una aplicación? ¿Cómo medir un ancho de banda? ¿Con qué unidad o unidades? ¿Cómo asegurarse de que un proveedor presta un servicio conforme a los SLA contractuales?

Si no se implementan medios para medir el rendimiento de una red o una aplicación, resultará difícil evaluar su calidad. Por lo tanto, es imposible reflexionar sobre la mejora del rendimiento actual o futuro sin evaluarlo de forma concreta según métricas bien definidas. Es fácil admitir que la percepción de la velocidad de acceso a una aplicación por parte de un usuario es un dato a tener en cuenta, pero que no es matemáticamente comparable y sigue siendo bastante subjetivo.

Es necesario cuantificar esta sensación de lentitud mediante una medida precisa, que podría ser, por ejemplo, el tiempo de visualización de la página de inicio de un sitio intranet tras la identificación de un usuario, por lo que se puede evaluar en segundos. Este valor se podría cuantificar en varios momentos del día para evaluar el tiempo de respuesta medio en periodos de uso intenso o reducido. Este registro de medias permitiría también evaluar las consecuencias derivadas de la modificación del código de la aplicación por parte del equipo de desarrollo, de un cambio en el sistema operativo sobre el que se basa la aplicación o de la modificación de la configuración de un activo de red, por ejemplo. Al final, todo lo que se mide se vuelve comparable.

La trampa de la metrología (y, en general, de la supervisión) es querer medirlo todo, obtener...

1. Velocidad bruta y velocidad de aplicación

Los operadores suelen expresar las velocidades de una conexión de tipo xDSL en velocidad ATM. Así, una conexión ADSL2 anunciada a 28 Mbits/s en descarga no representa realmente la velocidad real medida, incluso sin tener en cuenta la inevitable atenuación de la señal, que depende de la distancia del abonado. De hecho, una prueba de velocidad nos dará un resultado en torno a los 22 Mbit/s, esto es lo que los operadores denominan velocidad IP, es decir, la velocidad disponible sin tener en cuenta la velocidad adicional utilizada por uno o varios protocolos de nivel inferior al protocolo IP, como precisamente ATM (véase el capítulo Evolución de las profesiones en torno a las redes - subsección La evolución hacia las redes ATM). De hecho, no hay que olvidar que, para la transmisión de datos, estos se encapsulan en diferentes protocolos que utilizan encabezados de distintos tamaños, potencialmente variables. Por lo tanto, estos encabezados consumen ancho de banda adicional (ya que aumenta el número de bits que hay que transmitir).

Cuando se habla de ancho de banda, es necesario precisar en qué nivel de la capa OSI nos situamos; por defecto, se suele hacer referencia al ancho de banda IP. Pero si la aplicación en cuestión utiliza TCP en lugar de UDP, así como IPv6 en lugar de IPv4, la transmisión de un archivo será más lenta, ya que las cabeceras TCP e IPv6, en nuestro ejemplo, tienen un tamaño mayor. Teniendo en cuenta que, además, existe un tamaño máximo para un paquete determinado denominado MTU (Maximum Transfer Unit), lo que implica que, por encima de este valor, los datos se deben fragmentar y, por lo tanto, se utilizan más bits para las cabeceras, ya que se emplean más paquetes.

Por tanto, el error sería realizar el siguiente cálculo: una aplicación transfiere un archivo de 25 MB, con una conexión de 100 Mbits (12,5 MB por segundo), la transmisión tardará exactamente 2 s. En realidad, es necesario tener en cuenta los protocolos utilizados y la posible fragmentación en función del tamaño de los datos enviados y del MTU.

Consideremos aquí el envío...

1. Medición de la latencia y la fluctuación

a. Ping

El protocolo ICMP, mediante la generación de mensajes Echo Request y las correspondientes respuestas Echo Reply, permite verificar, por un lado, la conectividad de red entre dos máquinas en una red WAN o LAN (mediante el comando ping) y, por otro lado, de forma indirecta, obtener valores de latencia en el conjunto de las redes atravesadas. La latencia corresponde a una de las métricas de red definidas en este capítulo, en la subsección Las métricas de red.

El resultado de un comando ping a un destinatario accesible va acompañado del tiempo transcurrido entre el envío de la solicitud ICMP y la respuesta correspondiente, es decir, el tiempo de ida y vuelta por la red o RTT. La latencia se obtiene dividiendo este valor por 2; por lo general, es simétrica, aunque la ruta de ida seguida por un paquete IP puede diferir de la ruta de vuelta.

La latencia depende del medio utilizado, así como de su longitud. Las latencias más bajas se alcanzan en medios de fibra óptica, mientras que las más altas suelen encontrarse en las conexiones inalámbricas.

A continuación, se muestra una tabla con los valores "habituales" de RTT en una conexión WAN durante una prueba de ping entre dos equipos en Francia, según el tipo de conexión utilizada:

Soporte físico	RTT medio esperado
ADSL/VDSL (cobre)	Entre 30 ms y 80 ms
Fibra óptica	Entre 2 ms y 25 ms
Conexión por cable (coaxial)	Entre 15 ms y 40 ms
5G	Entre 20 ms y 40 ms
4G LTE	Entre 40 ms y 80 ms
3G	Entre 90 ms y 200 ms
WiMAX	Entre 40 ms y 85 ms
Satélite (geoestacionario)	Entre 600 ms y 900 ms
Satélite (LEO) - p. ej., Starlink	Entre 25 ms y 60 ms

Obtención del RTT a través del resultado del comando ping. Por tanto, la latencia es de 7 ms en esta captura para un RTT de 14 ms

La latencia también se puede evaluar en relación con el uso de protocolos de nivel superior al ICMP, concretamente a nivel de transporte a través de TCP o UDP. Para ello, se puede utilizar la utilidad echoping mencionada en la subsección Metodología de pruebas de rendimiento de este capítulo.

1. Almacenar las mediciones