¿Cómo se pueden describir las características de retraso de los comandos ping y traceroute?

¿Pregunta qué puede contribuir a la latencia que informan estas herramientas? Pueden estar formados por varias cosas …

  1. Distancia desde el sistema que ejecuta la aplicación hasta la respuesta del dispositivo
  2. El hecho de que la ruta que va al dispositivo remoto puede no ser lo mismo que volver.
  3. Con qué rapidez el dispositivo remoto puede responder a su aplicación.
  4. Congestión entre la fuente y el dispositivo remoto.
  5. Modulación / latencia de conversión de medios
  6. Límites de ancho de banda del circuito (es decir, módems lentos frente a enlaces 10GigE)
  7. Bufferbloat.
  8. Otros factores como QoS …

El número 1 estaría compuesto por la rapidez con que los paquetes pueden viajar sobre un medio en particular. La fibra es típicamente el 67% de la velocidad de la luz en el vacío. El cobre es de aproximadamente el 78%. Los recorridos de larga distancia se realizan sobre fibra, ya que puede obtener 100 km o más sobre fibra, mientras que no puede hacer lo mismo con el cobre.

En el número 2, debe tener en cuenta que gran parte de Internet es asimétrico en la forma en que enruta los paquetes. Esto normalmente es el resultado de que un ISP o operador prefiera enrutar paquetes en función del costo u otros factores. Esto significa que los paquetes pueden venir de una manera y luego retirarse de otra manera. Una dirección puede ser más corta que la otra. Su número tendrá en cuenta el tiempo de ida y vuelta.

El número 3 se refiere a la rapidez y la prioridad con la que el dispositivo remoto le enviará un paquete. Normalmente los paquetes ping (solicitud de eco ICMP) o traceroute (tiempo excedido) o se consideran tráfico de menor prioridad. Si tiene un enrutador sobrecargado, puede notar que ve un “tiempo de ping” más alto desde un dispositivo en medio de una ruta de seguimiento que los dispositivos aún más alejados.

El número 4 estaría compuesto por, digamos, un enrutador que está tratando de manejar más tráfico del que puede, ya sea por la rapidez con que puede determinar a dónde debe ir el paquete y si el enlace que necesita para reenviar el paquete está comenzando a alcanzar su límite .

El número 5 cubre qué tan rápido se tarda en convertir un bit al medio que está enviando. En los enlaces de microondas, este sería el proceso y el tiempo para modular lo que sea necesario para representar el bit y luego el tiempo para decodificar esa modulación en el otro extremo. Esto también puede incluir detección de errores, por lo que puede haber bits adicionales en este flujo de datos utilizados para eso.

El número 6 es algo que vemos con menos frecuencia en estos días, pero debe considerarse. Se relaciona con el número 5, pero realmente comienza a aparecer cuando tienes un enlace muy lento. En los primeros días del uso de líneas telefónicas de voz para transportar datos por módems, los primeros enlaces eran de 110 y 300 bits por segundo. Si estuviera enviando un paquete de ping estándar de 64 bytes e ignorando todos los demás gastos generales, esto tomaría 9 segundos de ida y vuelta solo en base a 110 bits por segundo. Como la mayoría de los enlaces de datos están en el rango Mega o Gigabit, esto no es tan importante.

El número 7 cubre algo que varias personas están tratando de abordar, conocido como bufferbloat [1]. Esta es la latencia como resultado de que los datos se viertan innecesariamente en un búfer de datos y se tomen un tiempo para procesarse. Cuando digo innecesariamente, tenga en cuenta que puede haber muchos buffers entre su aplicación, el sistema operativo del sistema, los controladores de red y el dispositivo de red en sí. Todos se suman a los retrasos. Muchas veces, estos tampones no son necesarios o pueden diseñarse para que sean mucho más pequeños de lo necesario.

El número 8 está destinado a ser una trampa para todos los demás factores que pueden afectar los resultados de ping y traceroute. Muchas veces pueden ser más políticas que técnicas. Mencioné el enrutamiento asimétrico antes como uno. La calidad de servicio (QoS) puede y cambiará estos números. Sus paquetes pueden dejarse de lado para un tráfico más “importante” para que experimente un retraso.

Espero que otros puedan pensar más factores aquí de lo que he cubierto.

Notas al pie

[1] Introducción – Bufferbloat.net

Si hace ping a una dirección IP, se espera que vea la siguiente respuesta:

Hacer ping 8.8.8.8 con 32 bytes de datos:

Respuesta de 8.8.8.8: bytes = 32 tiempo = 19 ms TTL = 42

Respuesta de 8.8.8.8: bytes = 32 tiempo = 22 ms TTL = 42

Respuesta de 8.8.8.8: bytes = 32 tiempo = 19 ms TTL = 42

Respuesta de 8.8.8.8: bytes = 32 tiempo = 135 ms TTL = 42

Respuesta de 8.8.8.8: bytes = 32 tiempo = 158 ms TTL = 42

Respuesta de 8.8.8.8: bytes = 32 tiempo = 60 ms TTL = 42

Respuesta de 8.8.8.8: bytes = 32 tiempo = 33 ms TTL = 42

Ahora observe el campo de tiempo en ms. La latencia varía de 19 milisegundos a 158 milisegundos.

Del mismo modo, para traceroute obtienes la latencia para cada salto

Cero, para todos los efectos. Los comandos en sí son irrelevantes.

Ahora, los paquetes que usan e informan tienen un retraso real. Pero no preguntaste eso. Así que no voy a decirte que tu profesor quiere que digas que estos comandos miden el retraso asimétrico de ida y vuelta, si obtienen una respuesta.