Gdzie zapisany jest „czas podróży w obie strony” Pinga w nagłówku IP?

Jeśli używamy ICMP ping, znamy TTL i round-trip timesą przechowywane w nagłówku IP. Na poniższej mapie nagłówka IP znamy lokalizację TTL, ale gdzie jest czas podróży w obie strony ?

Czy to jest przechowywane Options?

Czas podróży w obie strony nie jest nigdzie przechowywany. Host wysyłający zapamiętuje czas, w którym wysyła każdy komunikat żądania echa ICMP, używając 16-bitowego identyfikatora i pól sekwencji ICMP. Gdy otrzyma odpowiedź ICMP Echo, odnotowuje bieżącą godzinę, znajduje czas wysłania pasującego pakietu żądania określonego przez odpowiedź, oblicza różnicę i zgłasza ją.

Zazwyczaj ping używa pola identyfikacyjnego ICMP do rozróżnienia wielu jednoczesnych pingów, a pole sekwencji do rozróżnienia poszczególnych pakietów.

Implementacja decyduje, gdzie przechowywać czas wychodzący dla danego pakietu: zamiast przechowywać go na hoście w tabeli, zwykle wysyła go w żądaniu wychodzącym i używa kopii w odpowiedzi do obliczenia czasu. (Dzięki komentatorom za zwrócenie na to uwagi.) Jest wysyłany w sposób dogodny dla wdrożenia i oczywiście musi ufać odległemu końcowi i innemu sprzętowi, aby poprawnie skopiować dane. Niektóre systemy reprezentują czas w 16 bajtach z rozdzielczością mikrosekund, niektóre jako 8 bajtów z rozdzielczością milisekund.

Format w dataczęści pakietu IP to komunikat żądania / odpowiedzi echa ICMP, skopiowany tutaj z RFC 792 „Internet Control Message Format” (p14).

Typewynosi 8 dla żądania, 0 dla odpowiedzi; Codewynosi 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. Żeby było jasne, pole identyfikacyjne nagłówka IP jest zwykle ustawione na dowolną wartość, inną dla każdego wychodzącego pakietu, używaną do ponownego złożenia jakiejkolwiek fragmentacji i nie ma takiej samej wartości jak cokolwiek w treści ICMP.

Ponadto, chociaż zdefiniowano mechanizm wstawiania znaczników czasu do nagłówka IP jako opcji, nie jest to normalny mechanizm pingowania, ponieważ bardzo wiele routerów jest skonfigurowanych tak, aby nie przekazywać niektórych opcji IP. Patrz RFC 781 Specyfikacja opcji znacznika czasu protokołu internetowego.

Wreszcie, chociaż wszystko tutaj zostało napisane z perspektywy IPv4, na pierwotne pytanie; ale ping w IPv6 jest bardzo podobny, patrz ICMPv6 RFC 4443 .

Przynajmniej w przypadku wspólnego pingnarzędzia w systemie Linux czas wysłania pakietu jest przechowywany w części danych pakietu żądania echa, tj. Po nagłówkach IP i ICMP. Część danych pozostaje nienaruszona, gdy odbiorca odpowiada odpowiedzią echa, aby nadawca mógł obliczyć czas podróży w obie strony.

Jest to opisane na stronie podręcznika dla pingnarzędzia (w części „SZCZEGÓŁY PAKIETU ICMP”):

Jeśli przestrzeń danych ma rozmiar co najmniej struct timevalping, wykorzystuje początkowe bajty tej przestrzeni, aby uwzględnić znacznik czasu, który wykorzystuje do obliczania czasów podróży w obie strony. Jeśli przestrzeń danych jest krótsza, nie podaje się czasów podróży w obie strony.

Na moim komputerze sizeof(struct timeval)jest 16, więc ustawienie rozmiaru danych pakietu na 15 zapobiega pingwyświetlaniu czasów podróży w obie strony:

$ 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

Oczywiście przechowywanie znacznika czasu wysyłania w narzędziu, jak opisuje odpowiedź @ jonathanjo, byłoby również możliwą implementacją. Nawet narzędzie Linux wymaga wewnętrznej księgowości, ponieważ wykrywa duplikaty pakietów.