faccio uno sforzo immane e provo a scrivere una cosa seria, cosi da far vedere che mi guadagno lo stipendio :elio) (devo ancora cominciare ad essere serio)
dunque:
I pacchetti IP possiedono un'informazione denominata TTL, ovvero Time to live, il valore di questo campo va da 0 a 255 e viene deciso da chi genera il pacchetto.
Ogni volta che un pacchetto attraversa un nodo (un router o qualcosa che svolge un compito simile), il nodo deve provvedere a ridurre di un'unità questo valore. Quando un nodo riceve un pacchetto con un valore TTL pari a zero, lo elimina, mandando al mittente un pacchetto ICMP di tipo 11, "tempo scaduto", che indica l'impossibilità di raggiungere la destinazione con quel valore TTL di partenza. Il valore TTL di un pacchetto IP rappresenta il numero massimo di router IP che il pacchetto può attraversare prima di essere respinto. Nella pratica corrente ci si può aspettare che ciascun router in Internet decrementi il campo TTL esattamente di uno. Le specifiche TCP/IP stabiliscono che il campo TTL per i pacchetti TCP deve essere impostato a 60, ma molti sistemi usano valori minori (30, 15). Il massimo valore possibile di questo campo è 255, e molti sistemi impostano il campo TTL dei pacchetti ICMP ECHO_REQUEST a 255. Questa è la ragione per cui si può fare ping su certi host, ma non li si può raggiungere con telnet o ftp. Nelle operazioni normali ping stampa il valore ttl dal pacchetto che riceve. Quando un sistema remoto riceve un pacchetto ping, esso può fare una tra tre cose con il campo TTL in risposta:
Non lo cambia; in questo caso il valore TTL nel pacchetto ricevuto sarà 255 meno il numero
di router nel percorso di ritorno.
Impostarlo a 255; in questo caso il valore TTL nel pacchetto ricevuto sarà 255 meno il numero
di router nel percorso dal sistema remoto al ping ing host.
Impostarlo su qualche altro valore:
alcuni apparati se configurati per farlo, possono modificare il TTL in maniera arbitraria, falsando quindi il valore, inoltre, nel caso del trace, quello che vedi è l'elenco degli "hops" per raggiungere un dato host, ma nulla ti dice che tra un hop e l'altro non esistano degli apparati "invisibili" che decrementano il TTL dei pacchetti in transito.
prendiamo ad esempio windows ed il suo trace
impostiamo il TTL ad 1
invio un pacchetto ICMP echo (ping) verso l'IP di destinazione
rilevo la risposta, se si tratta di un codice 11, visualizzo l'IP che ha risposto (hop), incrementa di 1 il TTL e ripete l'invio fino a che l'host destinazione non sia stato raggiunto o fino a che il massimo numero di hops non sia stato raggiunto.
questo significa che, se il primo nodo potrà rispondere alla richiesta con TTL = 1, il secondo potrebbe rispondere con un TTL = 4, il terzo con 5, il quarto con 9 ecc...
se vuoi fare una prova:
c:\>pathping
http://www.google.it
Traccia route verso
http://www.l.google.com [74.125.43.99]
su un massimo di 30 punti di passaggio:
0 SC_045 [10.1.1.18]
1 10.1.1.1
2 89-96-179-1.ip13.fastwebnet.it [89.96.179.1]
3 213-156-57-1.ip.fastwebnet.it [213.156.57.1]
4 89.96.200.233
5 72.14.198.149
6 209.85.249.54
7 209.85.251.113
8 216.239.48.11
9 64.233.174.53
10 209.85.255.249
11 bw-in-f99.google.com [74.125.43.99]
questo trace non sta a significare che tutti punti da me raggiunti siano nel giusto ordine, per avere un alto livello di chiarezza:
ping -n 1 -i 1 x.x.x.x |find /i "risposta da"
alla risposta (richiesta scaduta) annotati l'host che ha risposto ed il TTL che hai usato, incrementa di una unità il valore TTL usato per "-i" e riesegui il comando, ossia
lancia il comando
ping -n 1 -i 2 x.x.x.x |find /i "risposta da"
ripeti quanto sopra incrementando il TTL (valore usato per -i) fino a quando riceverai risposta dall'host destinazione a questo punto avrai un elenco con i TTL relativi ai vari "hops"
ld) 