Por que o traceroute demora muito mais que o ping?

16

Como explicar isso?

C:\Documents and Settings\Administrator>tracert google.com

Tracing route to google.com [64.233.189.104]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  192.168.0.1
  2     7 ms    <1 ms    <1 ms  reserve.cableplus.com.cn [218.242.223.209]
  3   108 ms   135 ms   163 ms  211.154.70.10
  4     *        *        *     Request timed out.
  5     2 ms     *        1 ms  211.154.64.114
  6     1 ms     1 ms     1 ms  211.154.72.185
  7     1 ms     1 ms     1 ms  202.96.222.77
  8     2 ms     1 ms     2 ms  61.152.81.145
  9     1 ms     2 ms     1 ms  61.152.86.54
 10     1 ms     1 ms     1 ms  202.97.33.238
 11     2 ms     2 ms     2 ms  202.97.33.54
 12     2 ms     1 ms     2 ms  202.97.33.5
 13    33 ms    33 ms    33 ms  202.97.61.50
 14    34 ms    34 ms    34 ms  202.97.62.214
 15    34 ms   186 ms    37 ms  209.85.241.56
 16    35 ms    35 ms    44 ms  66.249.94.34
 17    34 ms    34 ms    34 ms  hkg01s01-in-f104.1e100.net [64.233.189.104]

Trace complete.

Portanto, o tempo médio deve ser: 1 + 7 + 108 + 2 + 1 + 1 + 2 + 1 + 1 + 2 + 2 + 33 + 34 + 34 + 35 + 34 + 34 + 35 + 34, que é muito maior que ping

C:\Documents and Settings\Administrator>ping google.com

Pinging google.com [64.233.189.104] with 32 bytes of data:

Reply from 64.233.189.104: bytes=32 time=34ms TTL=241
Reply from 64.233.189.104: bytes=32 time=34ms TTL=241
Reply from 64.233.189.104: bytes=32 time=34ms TTL=241
Reply from 64.233.189.104: bytes=32 time=34ms TTL=241

Ping statistics for 64.233.189.104:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 34ms, Maximum = 34ms, Average = 34ms
ping networking splattne
fonte
3
Tantas respostas ruins sobre esta questão. Vocês todos me lembrar, de certa forma, de youtube.com/watch?v=SXmv8quf_xM
Tom O'Connor

Respostas:

16

Você não pode simplesmente adicionar todos esses números. Esse é o tempo de ping para cada um dos saltos no caminho para o google. Então, naturalmente, cada trecho do caminho se afasta cada vez mais e você vê diferentes tempos de ping. Se você observar o último horário de ping no tracert (34 ms) e o tempo que você recebeu quando emitiu o ping (34ms), são os mesmos. O programa tracert não é mais lento que o ping.

Sugiro ler sobre como funciona um traceroute:
http://en.wikipedia.org/wiki/Traceroute

einstiien
fonte
Não é farther and farther away.
Eu não entendo o que você quer dizer. Cada endereço IP listado no traceroute é o endereço do próximo roteador alinhado entre você e o Google. Na topologia de rede "lógica", elas se afastam à medida que você avança na lista. Além disso, na maioria das vezes, eles se afastam fisicamente da sua localização geográfica. Embora isso nem sempre seja verdade, às vezes as rotas parecem pular o mapa "desnecessariamente". Mas o que quero dizer é que a distância física e vários saltos aumentam o tempo de ping.
einstiien
Tente fazer ping em cada nó na rota. Você deve criar o mesmo total (aproximadamente).
Chris Nava
1
Talvez o PHP esteja no site errado do stackoverflow, e isso significa que mais se refere à distância física, enquanto mais é mais apropriado para a distância da rede? english.stackexchange.com
dunxd
12

Você pode ver o ping como uma viagem de carro de Nova York a São Francisco. Demora, digamos 200 horas (eu sou da Suíça e não estou familiarizado com as distâncias nos EUA)

Mas o motorista precisa voltar a Nova York para dizer que ele estava em São Francisco. Você dá uma olhada no relógio e agora calcula que ele levou 400 horas para a distância. Agora é isso que Ping faz. O que Traceroute faz é: Diga ao seu motorista que ele deve dirigir de Nova York a San Franciso e toda vez que ele entrar em uma encruzilhada, ele deve voltar e dizer o nome dele. Então ele está a caminho e as primeiras encruzilhadas estão em Nova York. Então ele é bem rápido em dirigir de volta para você e dizer o nome da encruzilhada. Mas quando ele se afastar, ele levará mais tempo para retornar a você. e assim por diante...

Então, se você contar todas as horas de condução que ele estava a caminho, ele levaria muito mais tempo relatando todas as encruzilhadas do que se tivesse que dirigir para San Francisco. Espero que isso esclareça algumas coisas para você ...

Bona
fonte
2
Uma analogia melhor seria que você mandasse 30 motoristas, dizendo a cada um para seguir em direção a Nova York, mas cada um deles deveria se virar e voltar na primeira encruzilhada, na segunda encruzilhada, na terceira encruzilhada e assim por diante. o caminho até trinta encruzilhadas (esperando que haja menos de 30 entre SF e NY).
precisa
0

De fato, é basicamente devido ao fato de o PING ter enviado uma solicitação de ICMP pela rede ao DNS e a outros dispositivos da rede.

No entanto, o Traceroute envia muitos paquets com um TTL muito curto.

Por exemplo, quando você tenta ingressar no www.google.com do seu assento, o traceroute enviou um paquet para www.google.com com um TTL definido como 1 e aguarde uma resposta do dispositivo da rede do primeiro encontro.

Em seguida, o Traceroute exibe o IP do primeiro dispositivo de rede na tela e depois ele fará a mesma coisa, mas desta vez com um TTL definido como 2 etc.

No final, o Traceroute aguardou cerca de metade do tempo, pois, a cada envio, aguarda a resposta do dispositivo de uma rede.

Dr I
fonte
0

O Traceroute sempre indica a média do destino, não um acúmulo de vezes, ou seja, no seu caso, são 34ms com pinge traceroute.

Se o traceroute fizesse o que você sugere, sua saída seria bastante ilegível.

Se você está interessado apenas no tempo de resposta do destino, pingé o suficiente, tracerouteé para quando você precisar depurar algo na rota para o destino. Além disso, todos os saltos entre você e o destino são roteadores e, na maioria das vezes, os roteadores têm prioridade sobre o que fazer, ou seja, os primeiros pacotes de rota e, em seguida, respondem a ping ou traceroute (ou seja, o primeiro caso, respondendo a icmp echo reply, e no segundo caso, an icmp time exceeded) e geralmente respondem mais lentamente (quando respondem)

esteira
fonte
0

Para a posteridade, uma vez que nenhuma das respostas corretas é muito clara ...

-

Cada vez que é mostrado no traceroute é o TEMPO TOTAL DA SUA MÁQUINA (ou da máquina que faz o traceroute ...) até O NÚMERO PARTICULAR.

Em outras palavras, o tempo mostrado no segundo nó não é o tempo gasto entre os nós 1 e 2, mas o tempo total gasto entre a origem, o primeiro nó e o segundo nó, todos juntos.

Portanto, em média, os tempos mostrados em cada nó devem corresponder aproximadamente aos tempos que você obteria se pingasse esse nó em particular "diretamente" (não é mais direto do que um traceroute na realidade ... ele geralmente seguirá o mesmo caminho na internet).

Basta ter em mente que existe um "pico de atraso". A maneira mais precisa de encontrar a origem de qualquer atraso é executar um traceroute na repetição usando um arquivo em lotes (se você estiver no Windows) e encontrar o nó mais próximo (número mais baixo) que possui números altos a qualquer momento.

-

Para o arquivo em lotes, abra o bloco de notas e digite estas 3 linhas:

:start
tracert -d www.google.com
goto start

Salve como "Trace.bat", mas certifique-se de alterar o tipo de arquivo na caixa de diálogo Salvar para "todos os arquivos" antes de salvar ou ele ainda será salvo como um arquivo de texto.

Quando aberto, isso executa constantemente traceroutes (para o google). Você pode pará-lo pressionando ctrl + c enquanto a janela está selecionada.

-

Obviamente, você pode alterar para onde ele está executando o traceroute, alterando "www.google.com" para o endereço desejado.

Você também pode remover a opção "-d" se desejar ver os nomes de host resolvidos, mas isso fará com que o traceroute demore mais devido à obtenção dos nomes de host de um servidor DNS para cada nó (isso NÃO altera os resultados reais, no entanto, )

Por fim, se você encontrar um nó com tempos altos e apenas desejar executar traceroutes para esse nó específico, no caso de outro nó apresentar problemas, você poderá alterar "www.google.com" para o endereço IP ou o nome do host desse nó, OU você pode usar a opção -h para especificar quantos nós procurar, ou seja, ...

:start
tracert -d -h 5 www.google.com
goto start
Laike Endaril
fonte
Uma observação importante é que um nó responde com o ICMP, mas o objetivo principal de um roteador é rotear pacotes, e a criação de respostas ICMP está muito abaixo na lista do que ele faz. Um roteador fará o roteamento e enviará mensagens ICMP quando chegar a hora. É por isso que o tempo intermediário pode ser maior que o caminho completo; o roteador intermediário pode ser muito mais ocupado que o nó final.
Ron Maupin
Sim, a prioridade de QOS do ICMP geralmente é mais baixa, mas geralmente quando você está executando um traceroute, é porque já existe um problema (você está com picos de atraso ou ping ruim em um jogo) e com o nó específico que você mencionou ( o ocupado) é o gargalo que você está procurando.
Laike Endaril
Não quero dizer a prioridade de QoS, quero dizer o próprio dispositivo criando uma resposta ICMP. Na verdade, o nó pode estar muito ocupado com o roteamento de pacotes para enviar uma mensagem ICMP antes que o nó original atinja o tempo limite. Um roteador roteará pacotes antes de decidir enviar uma mensagem ICMP. Isso não tem nada a ver com QoS.
quer
QoS é um termo muito pouco definido, e considero que inclui todas as atividades que usam o mesmo conjunto de recursos, em vez de excluir atividades que requerem atenção extra (construção de um pacote de resposta). De qualquer forma, isso não muda o fato de o referido roteador estar com uma carga muito pesada e provavelmente causar problemas; portanto, os altos tempos de um traceroute ainda são um bom indicador de onde estão seus problemas ... com o possível exceção de uma grande quantidade de tráfego com prioridade mais alta que o ICMP, mas com prioridade mais baixa que o tráfego normal.
Laike Endaril
-1

Como o tracert usa pacotes UDP, como o ping, usam pacotes ICMP. No Linux, temos a traceroute -Iopção de fazer traceroute de ICMP.

No seu teste, o tempo para conectar-se ao google é o mesmo em traceroute e ping: 34ms. Todos os roteadores no meio têm seu próprio tempo para responder, mas não afetam o tempo final de transferência.

http://en.wikipedia.org/wiki/Traceroute explique tudo no Traceroute

Dom
fonte
3
Na verdade, no Windows, tracertusa o ICMP por padrão, diferente do Linux traceroute.
Phoebus
O tracert usa o período ICMP. ICMP é um protocolo IP, UDP é 17.
dbasnett
@dbasnett Originalmente, o traceroute enviou pacotes de saída como UDP, e os pacotes de retorno são obviamente mensagens excedidas de ICMP TTL. O Windows e agora outros programas traceroute usam pacotes de solicitação de eco ICMP para a saída. Normalmente, quando as pessoas se referem ao traceroute UDP ou traceroute ICMP, é a esses pacotes de saída que eles estão se referindo, uma vez que AMBOS os mecanismos dependem de ICMP TTL excedeu as mensagens que retornam ao remetente a partir dos saltos ao longo da rota.
Jed Daniels #
-1

Você pode aumentar seu traceroute desativando a pesquisa reversa de DNS, que geralmente falha: tracert -d www.google.com

Mathieu Chateau
fonte
Isso não torna os tempos de ida e volta mais rápidos. No entanto, torna mais rápido o retorno de resultados na tela, pois não faz as pesquisas de DNS.
precisa