Início / computer / Perguntas / 1582504
Accepted
Elliott B
Asked: 2020-09-03 09:24:07 +0800 CST

O que o ping -n faz de diferente?

  • 772

Ao solucionar um problema ocasional de "paralisação" da rede na minha internet doméstica, encontrei esta dica técnica da Dell . Eles sugerem usar ping -npara evitar uma parada causada pela resolução do DNS. Isso me fez pensar, o que o -nswitch realmente faz? Parece-me que a resolução DNS é necessária se você fizer ping em um nome DNS, mas não é necessária se você fizer ping em um IP.

Na página do manual:
-n Somente saída numérica. Nenhuma tentativa será feita para procurar nomes simbólicos para endereços de host.

Se eu fizer ping em um endereço IP, ping 8.8.8.8como há alguma pesquisa de DNS aqui? Faz ping -n 8.8.8.8algo diferente?

linux networking

2 respostas

  1. Best Answer

    Se eu fizer ping em um endereço IP, ping 8.8.8.8como há alguma pesquisa de DNS aqui? Faz ping -n 8.8.8.8algo diferente?

    Pode depender da implementação. Se pingsem -ninclui dns.googleem sua saída, ping -nprovavelmente não, esta é a diferença. Mas é possível que nenhuma das saídas inclua a string.

    No meu Ubuntu 18.04.4 LTS man 8 pinglê:

    pingfaz parte do iputilspacote e as versões mais recentes estão disponíveis no formato de origem em http://www.skbuff.net/iputils/iputils-current.tar.bz2.

    Este endereço exato parece não funcionar, ainda http://www.skbuff.net/iputils fornece outros links, incluindo o do SourceForge . Eu baixei iputils-s20151218 e li o código.

    -né tratado em ping_common.c:

    case 'n':
        options |= F_NUMERIC;
        break;

    Então a opção ( options & F_NUMERIC) é importante em ping.c:

    pr_addr(__u32 addr)
{
        …

        if (exiting || (options & F_NUMERIC) ||
            !(hp = gethostbyaddr((char *)&addr, 4, AF_INET)))
                sprintf(buf, "%s", inet_ntoa(*(struct in_addr *)&addr));
        else {
                …

    Para chegar a gethostbyaddr, ambos exitinge options & F_NUMERICdevem ser falsos (porque a || bdoes não avaliará bse afor verdadeiro). Este último depende se -nfoi ou não usado.

    gethostbyaddré a "tentativa de procurar nomes simbólicos para endereços de host". Veja man 3 gethostbyaddr. Essa é a mesma chamada de biblioteca getent hostsusada quando você fornece um endereço IP (consulte Recursos man 1 getent).

    Veja a diferença:

    $ getent hosts 8.8.8.8
8.8.8.8         dns.google
$ ping -c 1 dns.google
…
64 bytes from dns.google (8.8.8.8): icmp_seq=1 ttl=120 time=10.6 ms
…
$ ping -n -c 1 dns.google
…
64 bytes from 8.8.8.8: icmp_seq=1 ttl=120 time=11.3 ms
…
$

    Pode parecer pingsem -nusar apenas a string fornecida pelo usuário; mas não:

    $ getent hosts poczta.wp.pl
193.17.41.99    poczta.wp.pl
$ getent hosts 193.17.41.99
193.17.41.99    poczta.o2.pl
$ ping -c 1 poczta.wp.pl
…
64 bytes from poczta.o2.pl (193.17.41.99): icmp_seq=1 ttl=60 time=9.71 ms
…
$

    Aqui poczta.wp.plfoi resolvido 193.17.41.99e depois 193.17.41.99resolvido poczta.o2.pl(nota o2em vez de wp). O uso de -nsuprimiria a última etapa.

    Para alguns endereços isso acontece:

    $ getent hosts superuser.com
151.101.1.69    superuser.com
151.101.193.69  superuser.com
151.101.65.69   superuser.com
151.101.129.69  superuser.com
$ getent hosts 151.101.1.69 151.101.193.69 151.101.65.69 151.101.129.69        
$        # the output was empty
$ ping -c 1 superuser.com
…
64 bytes from 151.101.1.69 (151.101.1.69): icmp_seq=1 ttl=58 time=37.1 ms
…
$ ping -n -c 1 superuser.com
…
64 bytes from 151.101.1.69: icmp_seq=1 ttl=58 time=36.8 ms
…
$

    Mas se eu fornecer um endereço numérico, não haverá diferença:

    $ getent hosts 8.8.8.8
8.8.8.8         dns.google
$ ping -c 1 8.8.8.8
…
64 bytes from 8.8.8.8: icmp_seq=1 ttl=120 time=10.8 ms
…
$ ping -n -c 1 8.8.8.8
…
64 bytes from 8.8.8.8: icmp_seq=1 ttl=120 time=8.91 ms
…
$

    É por causa deste fragmento de ping.c:

    if (inet_aton(target, &whereto.sin_addr) == 1) {
        hostname = target;
         if (argc == 1)
                 options |= F_NUMERIC;
} else

    inet_atonconverte da notação de números e pontos IPv4 para a forma binária. Ele retorna 1em caso de sucesso. Se o último argumento fornecido a pingpuder ser convertido, o fragmento será avaliado options |= F_NUMERIC como se -nfosse usado .

    Na verdade, compilei pinga partir da fonte em duas versões: a original e com if … options |= F_NUMERIC;comentários. A versão modificada se comporta assim:

    $ ./ping -c 1 8.8.8.8
…
64 bytes from dns.google (8.8.8.8): icmp_seq=1 ttl=120 time=9.67 ms
…
$ ./ping -n -c 1 8.8.8.8
…
64 bytes from 8.8.8.8: icmp_seq=1 ttl=120 time=8.69 ms
…
$

    Agora posso responder explicitamente à pergunta:

    Faz ping -n 8.8.8.8algo diferente [de ping 8.8.8.8]?

    Não. O endereço na notação de números e pontos IPv4 faz ping( iputilsno Linux) funcionar como se -nfosse usado.

    Se eu fizer ping em um endereço IP, ping 8.8.8.8como há alguma pesquisa de DNS aqui?

    Criei um namespace de rede separado (para garantir que o mínimo de tráfego possível interfira) com um par veth e usei-o wiresharklá. (Se você quiser replicar meus resultados e precisar de ajuda com o procedimento, veja esta resposta , exemplo 2).

    Com o original ping:

    • ping -n -c 1 8.8.8.8gera ICMP echo requeste recebe ICMP echo reply. Nenhum DNS envolvido.
    • ping -c 1 8.8.8.8faz o mesmo (sem surpresa aqui, explicado acima).

    Isso significa que não há pesquisa de DNS . Abaixo estão alguns testes para comparação.

    Com o meu modificado ping:

    • ping -n -c 1 8.8.8.8se comporta como o original.
    • ping -c 1 8.8.8.8consulta o servidor DNS após o ICMP e recebe uma resposta. Isso é para conseguir dns.google.

    Novamente com o original ping:

    • ping -n -c 1 dns.googleconsulta o servidor DNS e recebe uma resposta antes do ICMP. Isto é para traduzir dns.googlepara 8.8.8.8ou 8.8.4.4.
    • ping -c 1 dns.googleconsulta o servidor DNS e recebe uma resposta antes do ICMP (para traduzir para 8.8.8.8ou para 8.8.4.4) e separadamente após o ICMP (para traduzir de volta).
    • 2

  2. Na página de manual:

    -n Somente saída numérica. Nenhuma tentativa será feita para procurar nomes simbólicos para endereços de host

    então a diferença está na saída:

    >ping  whitehouse.gov
PING whitehouse.gov(g2a02-26f0-0082-02b2-0000-0000-0000-2add.deploy.static.akamaitechnologies.com (2a02:26f0:82:2b2::2add)) 56 data bytes
64 bytes from g2a02-26f0-0082-02b2-0000-0000-0000-2add.deploy.static.akamaitechnologies.com (2a02:26f0:82:2b2::2add): icmp_seq=1 ttl=52 time=7.38 ms
64 bytes from g2a02-26f0-0082-02b2-0000-0000-0000-2add.deploy.static.akamaitechnologies.com (2a02:26f0:82:2b2::2add): icmp_seq=2 ttl=52 time=6.91 ms
64 bytes from g2a02-26f0-0082-02b2-0000-0000-0000-2add.deploy.static.akamaitechnologies.com (2a02:26f0:82:2b2::2add): icmp_seq=3 ttl=52 time=21.6 ms
64 bytes from g2a02-26f0-0082-02b2-0000-0000-0000-2add.deploy.static.akamaitechnologies.com (2a02:26f0:82:2b2::2add): icmp_seq=4 ttl=52 time=7.60 ms

    >ping  -n whitehouse.gov
PING whitehouse.gov(2a02:26f0:82:280::2add) 56 data bytes
64 bytes from 2a02:26f0:82:280::2add: icmp_seq=1 ttl=52 time=10.0 ms
64 bytes from 2a02:26f0:82:280::2add: icmp_seq=2 ttl=52 time=5.63 ms
64 bytes from 2a02:26f0:82:280::2add: icmp_seq=3 ttl=52 time=10.4 ms
64 bytes from 2a02:26f0:82:280::2add: icmp_seq=4 ttl=52 time=12.5 ms
    • 1

relate perguntas