主页 / computer / 问题 / 1582504
Accepted
Elliott B
Asked: 2020-09-03 09:24:07 +0800 CST

ping -n 有什么不同？

  • 772

在对我的家庭互联网上偶尔出现的网络“失速”进行故障排除时，我发现了戴尔提供的这个技术提示。他们建议使用ping -n以避免由 DNS 解析引起的停顿。这让我想到，-n开关实际上做了什么？在我看来，如果您 p​​ing DNS 名称，则需要 DNS 解析，但如果您 p​​ing IP，则不需要。

从手册页：
-n 仅数字输出。不会尝试查找主机地址的符号名称。

如果我 ping 一个 IP 地址，比如ping 8.8.8.8这里有什么 DNS 查找？做ping -n 8.8.8.8一些不同的事情吗？

linux networking

2 个回答

  1. Best Answer

    如果我 ping 一个 IP 地址，比如ping 8.8.8.8这里有什么 DNS 查找？做ping -n 8.8.8.8一些不同的事情吗？

    它可能取决于实现。如果在其输出中ping没有-n包含，则可能不包含，这就是区别。但有可能两个输出都不包含字符串。dns.googleping -n

    在我的 Ubuntu 18.04.4 LTSman 8 ping中写道：

    ping是iputils软件包的一部分，最新版本以源代码形式在http://www.skbuff.net/iputils/iputils-current.tar.bz2.

    这个确切的地址似乎不起作用，仍然http://www.skbuff.net/iputils提供了其他链接，包括SourceForge 的链接。我已经下载了 iputils-s20151218并阅读了代码。

    -n处理ping_common.c：

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

    那么选项 ( options & F_NUMERIC) 在以下方面很重要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 {
                …

    要到达gethostbyaddr，两者exiting和都options & F_NUMERIC必须为假（因为a || b不会评估b是否a为真）。后者取决于是否-n使用过。

    gethostbyaddr是“尝试查找主机地址的符号名称”。见man 3 gethostbyaddr。getent hosts这与您提供 IP 地址时使用的库调用相同（请参阅 参考资料man 1 getent）。

    看到不同：

    $ 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
…
$

    似乎ping不-n只是使用用户提供的字符串；但不是：

    $ 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
…
$

    这里poczta.wp.pl被解析为193.17.41.99，然后193.17.41.99被解析为poczta.o2.pl（注意o2而不是wp）。的使用-n会抑制后一步。

    对于某些地址，会发生这种情况：

    $ 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
…
$

    但是，如果我提供一个数字地址，那么就没有区别：

    $ 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
…
$

    这是因为这个片段来自ping.c：

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

    inet_aton从 IPv4 数字和点符号转换为二进制形式。它返回1成功。如果给定的最后一个参数ping可以转换，则该片段的评估options |= F_NUMERIC 就像-nwas used一样。

    我实际上是ping从源代码编译的两个版本：原始版本和if … options |= F_NUMERIC;注释掉的版本。修改后的版本行为如下：

    $ ./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
…
$

    现在我可以明确回答这个问题了：

    做ping -n 8.8.8.8一些不同的事情[比ping 8.8.8.8]？

    不，IPv4 数字和点符号中的地址ping（iputils在 Linux 上）就像-n使用过的一样工作。

    如果我 ping 一个 IP 地址，比如ping 8.8.8.8这里有什么 DNS 查找？

    我用一对 veth 创建了一个单独的网络命名空间（以确保尽可能少的流量干扰），然后在wireshark那里使用。（如果您想复制我的结果并需要该过程的帮助，请参阅此答案，示例 2）。

    与原件ping：

    • ping -n -c 1 8.8.8.8生成ICMP echo request和接收ICMP echo reply. 不涉及 DNS。
    • ping -c 1 8.8.8.8做同样的事情（这并不奇怪，上面解释过）。

    这意味着没有 DNS 查找。以下是一些比较测试。

    随着我的修改ping：

    • ping -n -c 1 8.8.8.8表现得像原来的。
    • ping -c 1 8.8.8.8在 ICMP 之后查询 DNS 服务器并收到响应。这是要搞定的dns.google。

    再次与原始ping：

    • ping -n -c 1 dns.google查询 DNS 服务器并在 ICMP 之前收到响应。这是翻译dns.google成8.8.8.8or 8.8.4.4。
    • ping -c 1 dns.google查询 DNS 服务器并在 ICMP（转换为8.8.8.8或转换为）之前8.8.4.4和 ICMP（转换回）之后分别接收响应。
    • 2

  2. 从手册页：

    -n 仅数字输出。不会尝试查找主机地址的符号名称

    所以区别在于输出：

    >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

相关问题