Delay
El delay (o "retardo" en castellano) es el tiempo que demora un bit en viajar desde un dispositivo origen hasta un dispositivo destino a través de la red.
Se expresa en milisegundos y tiene varios componentes.
El delay tiene componentes fijos (que no pueden ser modificados) y componentes variables (que pueden ser optimizados en mayor o menor medida).
El componente fijo inevitable es el delay de transmisión que es provocado por el tiempo de propagación de la señal a través del medio físico (cobre, fibra óptica, señal de radiofrecuencia).
Entre los componentes variables debemos considerar el delay de serialización (tiempo que demanda la copia de los bits de la memoria del dispositivo al medio físico), el delay de procesamiento (tiempo requerido por cada dispositivo para definir el reenvío o no del bit), el delay de buffer (que es el tiempo que el bit permanece en espera antes de ser enviado en caso de congestión).
El delay considera el tiempo necesario para establecer la comunicación solamente en sentido origen-destino.
¿Puede ser "medido" utilizando el ping?
No, el ping no mide delay.
RTT
El Round Trip Time (RTT) es el parámetro que muestra como resultado un ping.
Es el tiempo requerido para que una comunicación circule desde el origen hasta el destino y regrese al origen.
Es decir que considera el delay de ida, el delay de procesamiento de la respuesta, y el delay de regreso.
Por eso es una medición solamente aproximativamente del delay, porque en realidad el delay no es la mitad del RTT.
Porque RTT incluye el delay de procesamiento de la respuesta; y porque el delay de ida no es necesariamente igual al delay de regreso.
Con esas consideraciones, el RTT es una aproximación simple y accesible al estado de una ruta que permite realizar comparaciones sobre todo de una misma ruta en diferentes momentos.
Jitter
El Jitter es la variación del delay de una ruta durante una comunicación.
Como dije antes, el delay tiene una componente variable que es importante. Esto hace que durante el desarrollo de una comunicación el delay de cada paquete pueda ser diferente, lo que afecta la calidad de las comunicaciones en tiempo real (voz y video).
El jitter es más difícil de medir y requiere de herramientas específicas como pueden ser iperf o jperf. No puede ser evaluado con herramientas simples como ping o pathping.
Herramientas de los sistemas operativos
Ping
Herramienta basada en paquetes ICMP que permite verificar accesibilidad, RTT y pérdida de paquetes.
Se trata de un programa que utiliza las solicitudes ICMP echo (echo request) para enviar un datagrama a una dirección IP de destino y luego queda en espera de una respuesta (echo reply) a ese datagrama.
El resultado de esa solicitud de echo puede ser utilizado para evaluar la confiabilidad de la ruta al destino, el delay de esa ruta y si el nodo de destino es “alcanzable” o no.
C:\>ping 8.8.8.8
Haciendo ping a 8.8.8.8 con 32 bytes de datos:
Respuesta desde 8.8.8.8: bytes=32 tiempo=10ms TTL=56
Respuesta desde 8.8.8.8: bytes=32 tiempo=10ms TTL=56
Respuesta desde 8.8.8.8: bytes=32 tiempo=9ms TTL=56
Respuesta desde 8.8.8.8: bytes=32 tiempo=11ms TTL=56
Estadísticas de ping para 8.8.8.8:
Paquetes: enviados = 4, recibidos = 4, perdidos = 0
(0% perdidos),
Tiempos aproximados de ida y vuelta en milisegundos:
Mínimo = 9ms, Máximo = 11ms, Media = 10ms
Es importante tener presente que el resultado de la ejecución del comando no muestra precisamente el delay de la conexión entre origen y destino sino el RTT.
Tracert
El descubrimiento o “traceo” de rutas se puede realizar utilizando el programa traceroute presente en múltiples sistemas operativos. Este programa permite descubrir y revisar salto por salto la ruta que toman los paquetes hacia un destino específico.
Se envían 3 paquetes UDP al destino, utilizando los puertos 33434 (el primer paquete), 33435 (el segundo paquete) y 33436 (el tercer paquete). El proceso se inicia enviando primero una secuencia de paquetes UDP con TTL = 1 y a partir de allí se va incrementando el valor del campo TTL de uno en uno hasta llegar al destino o al límite de saltos definido (por defecto 30).
Microsoft Windows en su aplicación Tracert no utiliza paquetes UDP sino ICMP echo request.
En todos los casos utiliza respuestas de ICMP, en este caso paquetes time exceeded.
El valor máximo por defecto del campo TTL es 30, por lo que inicialmente al ejecutar el programa se rastrean los primeros 30 saltos. Si es preciso este valor puede ser ajustado.
Entre la información que proporciona el resultado de la ejecución de traceroute se encuentra:
- El listado ordenado de direcciones IP de cada salto que recorre el paquete en su ruta hacia el destino.
- La demora en milisegundos que ha registrado cada uno de los 3 paquetes que se han enviado en cada porción del trayecto. Se trata nuevamente de RTT, no delay.
- La identidad de cada salto.
C:\>tracert 8.8.8.8
Traza a la dirección google-public-dns-a.google.com [8.8.8.8]
sobre un máximo de 30 saltos:
1 2 ms 1 ms 1 ms 192.168.0.1
2 17 ms 8 ms 8 ms 10.96.0.1
3 11 ms 11 ms 10 ms 10.171.0.109
4 42 ms 11 ms 8 ms 10.200.0.66
5 19 ms 17 ms 18 ms 72.14.202.235
6 28 ms 24 ms 19 ms 108.170.248.225
7 59 ms 9 ms 9 ms 108.170.227.23
8 13 ms 8 ms 10 ms google-public-dns-a.google.com [8.8.8.8]
Traza completa.
Pathping
Herramienta disponible en sistemas operativos Microsoft.
Combina ping y tracert, a la vez que provee información estadística adicional tomada sobre la base de 100 paquetes enviados a cada uno de los saltos de la ruta.
Es una buena herramienta para la evaluación del estado de rutas activas, dada la estadística de tráfico que proporciona.
Como ocurre con ping, esta herramienta también presente un valor de RTT promedio de los 100 paquetes ICMP que envió a cada salto.
C:\>pathping 8.8.8.8
Seguimiento de ruta a google-public-dns-a.google.com [8.8.8.8]
sobre un máximo de 30 saltos:
0 192.168.0.17
1 192.168.0.1
2 10.96.0.1
3 10.171.0.109
4 10.200.0.66
5 72.14.202.235
6 108.170.248.225
7 108.170.227.23
8 google-public-dns-a.google.com [8.8.8.8]
Procesamiento de estadísticas durante 200 segundos...
Origen hasta aquí Este Nodo/Vínculo
Salto RTT Perdido/Enviado = Pct Perdido/Enviado = Pct Dirección
0 192.168.0.17
0/ 100 = 0% |
1 5ms 8/ 100 = 8% 8/ 100 = 8% 192.168.0.1
0/ 100 = 0% |
2 11ms 0/ 100 = 0% 0/ 100 = 0% 10.96.0.1
0/ 100 = 0% |
3 12ms 1/ 100 = 1% 1/ 100 = 1% 10.171.0.109
0/ 100 = 0% |
4 10ms 3/ 100 = 3% 3/ 100 = 3% 10.200.0.66
0/ 100 = 0% |
5 12ms 0/ 100 = 0% 0/ 100 = 0% 72.14.202.235
1/ 100 = 1% |
6 11ms 1/ 100 = 1% 0/ 100 = 0% 108.170.248.225
2/ 100 = 2% |
7 --- 100/ 100 =100% 97/ 100 = 97% 108.170.227.23
0/ 100 = 0% |
8 10ms 3/ 100 = 3% 0/ 100 = 0% google-public-dns-a.google.com [8.8.8.8]
Traza completa.
Lo interesante de esta herramienta es que permite tener información no ya de un paquete individual sino de una ráfaga de 100 paquetes, lo que da una visión más ajustada del estado de una ruta específica.
Aplicaciones
Las abreviaturas y siglas utilizadas en este post puede encontrarlas desarrolladas en
que está disponible en la Librería en Línea de EduBooks.
Entonces ¿normalmente un traceroute en un equipo Cisco por ejemplo se puede considerar una aplicación udp mientras que en windows es icmp?
ResponderBorrarHay una sutileza a considerar.
BorrarEn IOS, los paquetes que genera la aplicación para censar la ruta son paquetes UDP, pero las respuestas con el mensaje de timeout son paquetes ICMP.
En el caso de Microsoft, los paquetes que se envían son ICMP echo request, y las respuestas son igualmente mensajes ICMP timeout.
Respecto al traceroute creo que habría que explicar que se prueba la ida y la vuelta y que cada y también acerta del ping y del tracert que cada sistema operativo tiene un ttl asignado y le resta uno por cada nivel 3 porque el que tiene que pasar, si estoy en lo correcto.
ResponderBorrarEstás en lo correcto.
BorrarLo que ocurre es que no dediqué este post al traceo de rutas sino a los conceptos de delay, rtt y jitter. Por eso me limito a tracert como herramienta de verificación. Veré de hacer un post más específico sobre el tema.
Hola Oscar. ¿Y cuánto es el rango de ms "estable" en un enlace? Se que depende de muchas variables, pero en el caso de las redes LAN y hacia Internet en que tiempo (ms) se considera que existe retardo en la comunicación?
ResponderBorrarBuenos días Aldo.
BorrarQue el enlace sea estable, significa que el enlace mantiene un delay uniforme sin variaciones significativas. Simplemente eso.
Ahora, de cuánto es ese delay... una respuesta sencilla sería "mentirosa".
En realidad el delay depende de la tecnología y el medio de transmisión que se esté utilizando. Hoy contamos con enlaces de Internet sobre fibra óptica que te permiten el acceso a servidores distribuidos en diferentes partes del planeta en un rango inferior a los 10 mseg., mientras que hay redes LAN que presentan delays internos del orden de varias decenas de mseg.
El delay no depende solamente del medio y la tecnología de transmisión, sino que tiene múltiples componentes, algunos fijos (delay de serialización, delay de transmisión) y otros variables (delay de procesamiento). Esto hace que el delay entre 2 puntos particulares depende de la cantidad de saltos, de la configuración de cada salto, del grado de saturación de esos saltos, etc.
Una misma terminal, puede tener diferente delay cuando se comunica con 2 servicios diferentes, dentro de la misma red.
Retardo en la comunicación hay siempre. Lo que procuramos es mantenerlo en el mínimo posible; considerando para aplicaciones de tiempo real los 150 mseg. como un límite de referencia que se aconseja no sobrepasar.