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?

protocol-theory ping icmp

— samolot
źródło

Odpowiedzi:

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 .

— jonathanjo
źródło

AIUI pole „identyfikacja” służy do identyfikacji pakietów do ponownego złożenia fragmentu. Żądania echa są dopasowywane do echa odpowiedzi według pól id i seq w nagłówku ICMP.

— Peter Green,

Dzięki za wskazanie: wyjaśniłem, że to ICMP, a nie identyfikator IP (i kolejne, jak mówisz).

— jonathanjo

Jestem prawie pewien, że w pingLinuksie jest co najmniej jedna implementacja, która przechowuje znacznik czasu w Datasekcji ładunku ICMP. Doprowadziło to do całkiem interesującego komunikatu o błędzie, gdy odpowiedzi echa przeszły przez giełdę internetową, która w każdym miejscu nieco uszkadzała w każdym pakiecie.

— kasperd

Oczywiście masz rację, a ja zaktualizowałem odpowiedź, aby to powiedzieć; chociaż oczywiście jest to zapisany czas bezwzględny wysyłania zgodnie z zegarem nadawcy, a nie sam RTT.

— jonathanjo

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.

— ilkkachu
źródło

Wydaje się, że jest to błąd programu, który nie może wyświetlić RTT, gdy ustawisz rozmiar danych na mniej niż 16. Ale dobre strony.

— canadadry

@canadadry, Cóż, umieszczenie znacznika czasu w samym pakiecie jest po prostu oczywiste: jedyną potrzebną sytuacją jest nadejście pakietu odpowiedzi, więc nie ma sensu przechowywać go lokalnie. Oczywiście program wydaje się pochodzić z oryginału BSD z lat 80., więc może mieć również coś wspólnego z czasami. W każdym razie nie jestem do końca pewien, dlaczego ktokolwiek chciałby używać tak bardzo małych pakietów. Należy pamiętać, że nawet minimalny rozmiar ramki Ethernet jest wystarczająco duży, aby zmieścił się w nagłówkach Ethernet, IP i ICMP oraz 16-bajtowy znacznik czasu. (Chociaż pozostały 2 bajty, więc nie ma zbyt wiele miejsca na dalsze rozszerzenia.)

— ilkkachu

@ilkkachu dziękuję za przypomnienie mi, gdzie często przechowywany jest czas; Zaktualizowałem swoją odpowiedź. Re małe pakiety: wiele problemów sieciowych różni się w zależności od wielkości pakietu.

— jonathanjo

@ikkachu Rzuciłem okiem na pakiety ping Cisco: one także mają czas, bo 64-bitowa liczba milisekund.

— jonathanjo