Où le «temps d'aller-retour» de Ping est-il stocké dans l'en-tête IP?

Si nous utilisons des ICMP ping, nous connaissons le TTL et round-trip timesommes stockés dans l'en-tête IP. Dans la carte d'en-tête IP ci-dessous, nous connaissons l'emplacement de TTL, mais où est le temps d' aller-retour ?

Est-il stocké dans Options?

protocol-theory ping icmp

— avion
source

Réponses:

Le temps d'aller-retour n'est en fait stocké nulle part. L'hôte émetteur se souvient de l'heure à laquelle il envoie chaque message de demande d'écho ICMP, à l'aide de l'identificateur 16 bits et des champs de séquence ICMP. Lorsqu'il obtient la réponse d'écho ICMP, il note l'heure actuelle, trouve l'heure à laquelle il a envoyé le paquet de demande correspondant identifié par la réponse, calcule la différence et la signale.

En général, ping utilise le champ d'identification ICMP pour différencier plusieurs pings simultanés et le champ de séquence pour différencier les paquets individuels.

C'est à l'implémentation de décider où stocker le temps sortant pour un paquet donné: au lieu de le stocker sur l'hôte dans une table, il l'envoie généralement dans la demande sortante et utilise la copie dans la réponse pour calculer le temps. (Merci aux commentateurs de l'avoir signalé.) Il est envoyé de la manière qui convient à la mise en œuvre, et doit bien sûr faire confiance à l'extrémité distante et à tout équipement intermédiaire pour copier correctement les données. Certains systèmes sont connus pour représenter le temps en 16 octets avec une résolution de microsecondes, certains comme 8 octets avec une résolution de millisecondes.

Le format à l'intérieur de la datapartie du paquet IP est le message de demande / réponse d'écho ICMP, copié ici à partir de la RFC 792 "Format de message de contrôle Internet" (p14).

Typeest 8 pour la demande, 0 pour la réponse; Codeest 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 ...
   +-+-+-+-+-

PS. Juste pour être clair, le champ d'identification de l'en-tête IP est normalement défini sur une valeur arbitraire, différente pour chaque paquet sortant, utilisée pour le réassemblage de toute fragmentation, et n'a pas la même valeur que quoi que ce soit dans le corps ICMP.

De plus, bien qu'il existe un mécanisme défini pour placer des horodatages dans l'en-tête IP en option, ce n'est pas le mécanisme normal pour le ping car de très nombreux routeurs sont configurés pour ne pas transmettre certaines options IP. Voir la spécification RFC 781 de l'option d'horodatage du protocole Internet.

Enfin, bien que tout ici ait été écrit dans une perspective IPv4, selon la question d'origine; mais le ping dans IPv6 est extrêmement similaire, voir ICMPv6 RFC 4443 .

— jonathanjo
source

AIUI le champ "identification" est utilisé pour identifier les paquets pour le réassemblage des fragments. Les demandes d'écho sont mises en correspondance avec les réponses d'écho par les champs id et seq dans l'en-tête ICMP.

— Peter Green le

Merci de l'avoir signalé: j'ai précisé qu'il s'agit de l'ICMP et non de l'ID IP (et seq, comme vous le dites).

— jonathanjo

Je suis pratiquement sûr qu'il existe au moins une implémentation de pingLinux qui stocke l'horodatage dans la Datasection de la charge utile ICMP. Cela a conduit à un message d'erreur assez intéressant lorsque les réponses d'écho ont traversé un échange Internet qui corrompait un peu cet emplacement dans chaque paquet.

— kasperd

Vous avez bien sûr raison, et j'ai mis à jour la réponse pour le dire; bien que ce soit naturellement l'heure absolue d'envoi en fonction de l'horloge de l'expéditeur qui est stockée, pas RTT lui-même.

— jonathanjo

Au moins avec l' pingutilitaire commun sous Linux, l'heure à laquelle le paquet a été envoyé est stockée dans la partie données du paquet de demande d'écho, c'est-à-dire après les en-têtes IP et ICMP. La partie de données est conservée intacte lorsque le récepteur répond avec une réponse d'écho, afin que l'expéditeur puisse calculer le temps d'aller-retour.

Ceci est décrit dans la page de manuel de l' pingutilitaire (sous "DÉTAILS DU PAQUET ICMP"):

Si l'espace de données est au moins de la taille du struct timevalping, utilise les octets de début de cet espace pour inclure un horodatage qu'il utilise dans le calcul des temps d'aller-retour. Si l'espace de données est plus court, aucun temps d'aller-retour n'est indiqué.

Sur ma machine sizeof(struct timeval)est 16, donc la définition de la taille des données par paquets à 15 empêche pingd'afficher les temps d'aller-retour:

$ 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

Bien sûr, le stockage de l'horodatage d'envoi dans l'utilitaire, comme le décrit la réponse de @ jonathanjo, serait également une implémentation possible. Même l'utilitaire Linux a besoin d'une comptabilité interne, car il détecte les paquets en double.

— ilkkachu
source

On dirait que c'est un bug de programme qu'ils ne peuvent pas afficher le RTT lorsque vous définissez la taille des données à moins de 16. Mais de bons points.

— canadadry

@canadadry, Eh bien, mettre l'horodatage dans le paquet lui-même est juste évident: la seule situation dont il a besoin est quand le paquet de réponse arrive, donc il ne sert à rien de le stocker localement. Bien sûr, le programme semble dériver de l'original BSD des années 80, il peut donc aussi avoir quelque chose à voir avec le temps. Quoi qu'il en soit, je ne sais pas exactement pourquoi quelqu'un voudrait utiliser de si petits paquets. Notez que même la taille de trame Ethernet minimale est suffisamment grande pour s'adapter aux en-têtes Ethernet, IP et ICMP, et un horodatage de 16 octets. (Bien qu'il reste 2 octets, il n'y a donc pas beaucoup de place pour une extension supplémentaire.)

— ilkkachu

@ilkkachu merci de me rappeler où le temps est souvent stocké; J'ai mis à jour ma réponse. Concernant les petits paquets: de nombreux problèmes de réseau sont différenciés selon la taille des paquets.

— jonathanjo

@ikkachu J'ai jeté un coup d'œil aux paquets ping de Cisco: ils ont aussi le temps, comme un décompte de 64 bits de millisecondes.

— jonathanjo