¿Dónde se almacena el "tiempo de ida y vuelta" de Ping en el encabezado de IP?

Si usamos ICMP ping, conocemos el TTL y round-trip timeestamos almacenados en el encabezado IP. En el siguiente mapa de encabezado de IP sabemos la ubicación de TTL, pero ¿dónde está el tiempo de ida y vuelta ?

¿Está almacenado en Options?

protocol-theory ping icmp

— aeronave
fuente

Respuestas:

El tiempo de ida y vuelta en realidad no se almacena en ningún lado. El host remitente recuerda la hora en que envía cada mensaje de solicitud de eco ICMP, utilizando el identificador de 16 bits de ICMP y los campos de secuencia. Cuando recibe la respuesta de eco ICMP, anota la hora actual, encuentra la hora en que envió el paquete de solicitud coincidente identificado por la respuesta, calcula la diferencia y lo informa.

Típicamente, ping utiliza el campo de identificación de ICMP para diferenciar múltiples pings simultáneos y el campo de secuencia para diferenciar paquetes individuales.

Depende de la implementación decidir dónde almacenar el tiempo de salida para un paquete dado: en lugar de almacenarlo en el host en una tabla, generalmente lo envía en la solicitud de salida y usa la copia en la respuesta para calcular el tiempo. (Agradece a los comentaristas por señalar esto). Se envía de la manera que sea conveniente para la implementación y, por supuesto, tiene que confiar en el otro extremo y en cualquier equipo que intervenga para copiar adecuadamente los datos. Se sabe que algunos sistemas representan el tiempo en 16 bytes con resolución de microsegundos, algunos como 8 bytes con resolución de milisegundos.

El formato dentro de la dataporción del paquete IP es el mensaje de solicitud / respuesta de eco ICMP, copiado aquí del RFC 792 "Formato de mensaje de control de Internet" (p14).

Typees 8 para Solicitud, 0 para Respuesta; Codees 0.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |     Code      |          Checksum             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Identifier          |        Sequence Number        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Data ...
   +-+-+-+-+-

PD. Para ser claros, el campo de identificación del encabezado IP normalmente se establece en un valor arbitrario, diferente para cada paquete saliente, utilizado para el reensamblaje de cualquier fragmentación, y no tiene el mismo valor que cualquier cosa en el cuerpo ICMP.

Además, aunque hay un mecanismo definido para colocar marcas de tiempo en el encabezado IP como una opción, este no es el mecanismo normal para hacer ping porque muchos enrutadores están configurados para no pasar ciertas opciones de IP. Consulte la especificación RFC 781 de la opción de marca de tiempo del protocolo de Internet.

Finalmente, aunque todo aquí fue escrito desde una perspectiva IPv4, según la pregunta original; pero el ping en IPv6 es extremadamente similar, vea ICMPv6 RFC 4443 .

— jonathanjo
fuente

AIUI el campo "identificación" se utiliza para identificar paquetes para el reensamblaje de fragmentos. Las solicitudes de eco coinciden con las respuestas de eco de los campos id y seq en el encabezado ICMP.

— Peter Green

Gracias por señalarlo: aclaré que es el ICMP, no la identificación de IP (y seq, como usted dice).

— jonathanjo

Estoy bastante seguro de que hay al menos una implementación de pingen Linux que almacena la marca de tiempo en la Datasección de la carga útil de ICMP. Eso condujo a un mensaje de error bastante interesante cuando las respuestas de eco atravesaron un intercambio de Internet que estaba corrompiendo un poco en esa ubicación en cada paquete.

— kasperd

Tienes razón, por supuesto, y actualicé la respuesta para decir esto; aunque, naturalmente, se almacena el tiempo absoluto de envío de acuerdo con el reloj del remitente, no el RTT en sí.

— jonathanjo

Al menos con la pingutilidad común en Linux, el momento en que se envió el paquete se almacena en la parte de datos del paquete de solicitud de eco, es decir, después de los encabezados IP e ICMP. La parte de datos se mantiene intacta cuando el receptor responde con una respuesta de eco, para que el remitente pueda calcular el tiempo de ida y vuelta.

Esto se describe en la páginaping del manual de la utilidad (en "DETALLES DEL PAQUETE ICMP"):

Si el espacio de datos es al menos del tamaño de struct timevalping, utiliza los bytes iniciales de este espacio para incluir una marca de tiempo que utiliza en el cálculo de los tiempos de ida y vuelta. Si el espacio de datos es más corto, no se dan tiempos de ida y vuelta.

En mi máquina sizeof(struct timeval)es 16, por lo que establecer el tamaño de paquete de datos en 15 evita que se pingmuestren los tiempos de ida y vuelta:

$ ping -s 15 8.8.8.8 
PING 8.8.8.8 (8.8.8.8) 15(43) bytes of data.
23 bytes from 8.8.8.8: icmp_seq=1 ttl=121

Por supuesto, almacenar la marca de tiempo de envío dentro de la utilidad, como describe la respuesta de @ jonathanjo, también sería una posible implementación. Incluso la utilidad Linux necesita algo de contabilidad interna, ya que detecta paquetes duplicados.

— ilkkachu
fuente

Parece que es un error del programa que no pueden mostrar el RTT cuando configura el tamaño de los datos en menos de 16. Pero buenos puntos.

— canadadry

@canadadry, Bueno, poner la marca de tiempo en el paquete en sí es obvio: la única situación que se necesita es cuando llega el paquete de respuesta, por lo que no tiene sentido almacenarlo localmente. Por supuesto, el programa parece derivarse del original BSD de los 80, por lo que también puede tener algo que ver con los tiempos. De todos modos, no estoy exactamente seguro de por qué alguien querría usar paquetes tan pequeños. Tenga en cuenta que incluso el tamaño mínimo de trama de Ethernet es lo suficientemente grande como para adaptarse a los encabezados de Ethernet, IP e ICMP, y una marca de tiempo de 16 bytes. (Aunque con 2 bytes sobrantes, no queda mucho espacio para ninguna otra extensión).

— ilkkachu

@ilkkachu gracias por recordarme dónde se almacenaba el tiempo a menudo; Actualicé mi respuesta. Re paquetes pequeños: muchos problemas de red se diferencian en el tamaño del paquete.

— jonathanjo

@ikkachu Eché un vistazo a los paquetes de ping de Cisco: también tienen el tiempo, como un recuento de 64 bits de milisegundos.

— jonathanjo