Qué es la pérdida de paquetes, de qué puede depender y cómo verificar cuándo se presenta. Prueba de packet loss con comandos del sistema operativo, utilidades dedicadas y herramientas online.
La red Internet es el ejemplo por excelencia de red de conmutación de paquetes en la que la información a transferir se «trocea» en porciones transmitidas individualmente y en secuencia. Estas porciones de datos se llaman paquetes y cada uno de ellos, además del payload o los datos reales a transferir, consta de una cabecera o header.
El header contiene la dirección del transmisor, la del receptor, la vida útil del paquete, los datos relativos al ensamblaje con los otros paquetes, y así sucesivamente.
Para llegar al dispositivo (host) de destino, los paquetes toman uno o más caminos según las indicaciones contenidas en las tablas de enrutamiento o tablas de routing.
El conjunto de protocolos utilizados para una red de conmutación de paquetes como Internet se llama TCP/IP y nació en 1981.
Cuando no todos los paquetes de datos llegan a destino, TCP se encarga de reenviar los paquetes perdidos o dañados. La recepción de un paquete ACK (acknowledgment) enviado por el destinatario confirma que la transmisión del dato individual ha sido exitosa.
Pérdida de paquetes o packet loss: qué significa
Cuando uno o más paquetes de datos enviados por el transmisor no son recibidos por el host de destino, se habla de pérdida de paquetes o packet loss en inglés.
Con la navegación web típica basada en TCP, cuando se pierden paquetes, el remitente se da cuenta de que su mensaje no ha sido entregado correctamente y lo reenvía hasta que es recibido correctamente o hasta que desiste debido al timeout establecido, para luego, eventualmente, reiniciar todo el proceso de envío.
A diferencia de TCP, UDP es un protocolo de tipo connectionless, no gestiona el reordenamiento de los paquetes ni la retransmisión de los perdidos. Es, por lo tanto, menos fiable para transferir datos de un host a otro, pero a pesar de esto, es ampliamente utilizado: seguramente habrás encontrado referencias a UDP en aplicaciones de streaming de audio y video, en aplicaciones VoIP, en juegos online y en todos aquellos contextos donde las prestaciones son esenciales.
UDP es un protocolo de comunicación «ligero»: al no realizar todas las verificaciones sobre los paquetes de datos entrantes y al no requerir una nueva transmisión de los paquetes eventualmente perdidos, UDP puede ser muy eficiente. Aplicaciones como las que hemos mencionado antes toleran bien alguna pérdida de datos, prefiriendo un stream de datos que fluya sin interrupciones.
Las causas de la pérdida de paquetes son a menudo las mismas que la mayoría de los problemas de red: con frecuencia, el packet loss es consecuencia de una situación de congestión cuando demasiados usuarios están utilizando un conjunto de routers y estos no logran gestionar el encaminamiento de todos los paquetes.
Los paquetes pueden perderse ya dentro de la LAN, a nivel de la red del operador de telecomunicaciones que proporciona el servicio de acceso a Internet, o externamente a ella. La pérdida de paquetes también puede ocurrir en la red a la que está conectado el servidor de destino o en la red local utilizada por este último.
A nivel local puede depender del uso de una tarjeta de red defectuosa, de problemas de hardware en el PC en uso, de problemas en el router local (incluida la congestión de la red local), del uso de una conexión WiFi inestable.
En otro artículo hemos visto cómo verificar qué falla cuando resulta imposible acceder a un sitio web.
A veces, los paquetes no están realmente perdidos porque finalmente llegan a destino; sin embargo, llegan tan tarde que se consideran ya perdidos.
Las herramientas para verificar la velocidad de la conexión de red se llaman speed test: los mejores miden también la latencia, es decir, el tiempo requerido por los paquetes de datos para llegar correctamente al sistema de destino y regresar (ping), y el jitter, que es la variación que afecta al dato relativo a la latencia (cuánto es más o menos estable el valor del ping). La latencia y el jitter deberían mantenerse en valores tendencialmente «bajos».
El concepto de «bajo» es obviamente relativo: antes que nada, hay que considerar el tipo de conexión a Internet que se está utilizando (fibra FTTH, FTTC, FWA, ADSL, satelital, datos móviles,…) y luego el servidor sobre el cual se está realizando la prueba (¿qué tan cerca está físicamente? ¿Con qué tipo de conexión está conectado a la red Internet?…).
Prueba de packet loss: cómo realizarla
Una de las mejores herramientas para verificar si se produce una pérdida de paquetes es el comando ping: está presente en todos los sistemas operativos y acepta tanto direcciones IP privadas como públicas.
Por defecto, el comando ping en Windows envía cuatro paquetes de datos de prueba (ICMP) de 32 bytes cada uno y calcula la latencia en milisegundos (ms).
Cuando el host especificado como destinatario de la prueba no envía ninguna respuesta, ping muestra el mensaje «Request timed out».
Para ejecutar la prueba, basta con escribir cmd en el cuadro de búsqueda de Windows, luego presionar Intro y escribir ping -t seguido de la dirección del host objeto de verificación (también puedes presionar Windows+R y escribir el comando en el campo Ejecutar).
Al escribir ping -t seguido de la dirección IP del router local (ejemplo: ping -t 192.168.1.1 o ping -t 192.168.0.1), se verifica en cuántos milisegundos dicho dispositivo responde al envío de paquetes de prueba ICMP. Respuestas tardías o solicitudes agotadas son imputables a la presencia de fenómenos de congestión en la red local (ancho de banda agotado por los dispositivos locales que están realizando transferencias de datos) o, por ejemplo, entre otras razones, a una conexión WiFi poco fiable, a la demasiada distancia del router inalámbrico o del access point,…
ping -t [dirección IP o nombre del host]En el caso de que se haya indicado la dirección IP pública de un host remoto (por ejemplo, un servidor web), hay que decir que no todos responden a las solicitudes ping, aunque estén perfectamente funcionando y accesibles. En este caso, tendrás una pérdida de paquetes del 100%, cuando en realidad el host de destino resulta perfectamente accesible.
El comando ping -t envía paquetes ICMP sin límite alguno: para interrumpir la prueba, basta con presionar CTRL+C. Manteniendo abierta la ventana del símbolo del sistema en la que se lanzó el comando ping -t, puedes sin embargo verificar el momento exacto en que se presenta la pérdida de paquetes o el aumento de la latencia en milisegundos.
MTR (Matt’s traceroute) es una utilidad de línea de comandos que combina el comando ping con un mecanismo de verificación de la ruta seguida por los paquetes de datos (traceroute). Nació como un programa Linux que en Windows puede ejecutarse, por ejemplo, utilizando WSL 2 (WinMTR, desafortunadamente, no ofrece el mismo abanico de funciones).
Al escribir, por ejemplo, mtr google.es, aparecerá una pantalla similar a la de la figura, en continua actualización.
- Como se ve, a la izquierda MTR devuelve las direcciones IP de los host (se resuelven automáticamente cuando es posible) que son atravesados sucesivamente por los paquetes a lo largo de su recorrido hasta el destino (hop), mientras que bajo la columna
Lost%se indica el porcentaje de paquetes perdidos en correspondencia con los hops individuales. - Examinando las indicaciones de
Lost%, es posible entender rápidamente qué host encontrados a lo largo del recorrido son probablemente responsables del packet loss. - Más a la derecha se muestra el número de pruebas realizadas (paquetes enviados,
Snt) y los valores de latencia (último detectado, promedio, mejor, peor, desviación estándar).
Como se mencionó anteriormente, el valor de latencia puede aumentar, a veces incluso de manera considerable, entre los primeros hops (red de tu propio operador de telecomunicaciones) y los pasos finales (red del host remoto).
MTR tiene la ventaja de que permite simular la conexión también en puertos específicos utilizando los protocolos indicados. El siguiente comando, por ejemplo, establece una conexión TCP en el puerto 443 (HTTPS) hacia el servidor de Google (motor de búsqueda):
mtr -T -P 443 www.google.esPara que el comando se ejecute correctamente, es necesario respetar las mayúsculas.
Con un WHOIS, además, es posible establecer con certeza a qué entidades pertenecen los diversos sistemas, partiendo de la correspondiente dirección IP pública. También hablamos de ello en el artículo en el que vemos cómo encontrar a quién está registrado un dominio.
En el traceroute de MTR es posible encontrar también direcciones IP privadas: además de las de tu red local, los operadores también usan IP privadas para encaminar los paquetes de datos antes de reenviarlos a host externos.
En las distribuciones Debian, Ubuntu y derivadas, MTR se puede instalar simplemente escribiendo sudo apt install mtr -y en la ventana del terminal.
sudo apt install mtr -yPor último, mencionamos también Packet Loss Test online, una herramienta que permite verificar la presencia de eventuales paquetes perdidos. Sugerimos elegir Alemania (Germany) como servidor de prueba.
Junto a Select a Preset Approximation, puedes elegir un perfil de prueba que permita simular la transferencia de video en streaming 720p o 1080p, el uso de una solución para videoconferencia como Zoom, una conexión VoIP o algunos de los principales títulos de gaming.
Optando por uno de los perfiles presentados, la prueba ajusta el tamaño de los paquetes, la frecuencia, la duración y el retraso a considerar como «aceptable».
