Ping 和 Web 请求的“启动”很慢,但 DNS、延迟和速度测试却很快?

Ping 和 Web 请求的“启动”很慢,但 DNS、延迟和速度测试却很快?

因此,令我怀疑的关键症状是,当我在 Ubuntu 上运行 ping 时,它需要大约一秒钟左右的时间才能开始打印,而在 OSX 笔记本电脑上几乎立即启动(我的笔记本电脑上没有 ubuntu,所以操作系统可能是巧合)。

通常我会怀疑 DNS,但这是我的 Ubuntu DNS 测试:

dig +trace www.stackoverflow.com

; <<>> DiG 9.16.1-Ubuntu <<>> +trace www.stackoverflow.com
;; global options: +cmd
;; Received 40 bytes from 10.0.0.1#53(10.0.0.1) in 7 ms

mtr、ping 和速度测试的指标都很好。例如,这是 Ubuntu 桌面上的 ping:

ping www.stackoverflow.com
PING stackoverflow.com (151.101.1.69) 56(84) bytes of data.
64 bytes from 151.101.1.69 (151.101.1.69): icmp_seq=1 ttl=57 time=9.87 ms
64 bytes from 151.101.1.69 (151.101.1.69): icmp_seq=2 ttl=57 time=8.95 ms
64 bytes from 151.101.1.69 (151.101.1.69): icmp_seq=3 ttl=57 time=9.17 ms
64 bytes from 151.101.1.69 (151.101.1.69): icmp_seq=4 ttl=57 time=8.83 ms
64 bytes from 151.101.1.69 (151.101.1.69): icmp_seq=5 ttl=57 time=9.14 ms
64 bytes from 151.101.1.69 (151.101.1.69): icmp_seq=6 ttl=57 time=9.08 ms
64 bytes from 151.101.1.69 (151.101.1.69): icmp_seq=7 ttl=57 time=9.16 ms
64 bytes from 151.101.1.69 (151.101.1.69): icmp_seq=8 ttl=57 time=9.03 ms
64 bytes from 151.101.1.69 (151.101.1.69): icmp_seq=9 ttl=57 time=8.91 ms

但关键是它花了将近两秒钟才开始打印 ping 时间。

我意识到了这一点可能与 Ubuntu 完全无关,但我猜测这里可能有一些 Linux 内部知识或调试知识可能会有所帮助。

我可以查看 ping 的 strace 输出,但不太确定我在寻找什么。strace 打印了一些内容,然后在执行任何操作时挂起两秒钟。这是我在此时将其杀死时的输出

openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libnss_mdns4_minimal.so.2", O_RDONLY|O_CLOEXEC) = 5
read(5, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240\23\0\0\0\0\0\0"..., 832) = 832
fstat(5, {st_mode=S_IFREG|0644, st_size=18504, ...}) = 0
mmap(NULL, 20496, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 5, 0) = 0x7f565ae48000
mmap(0x7f565ae49000, 8192, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 5, 0x1000) = 0x7f565ae49000
mmap(0x7f565ae4b000, 4096, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 5, 0x3000) = 0x7f565ae4b000
mmap(0x7f565ae4c000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 5, 0x3000) = 0x7f565ae4c000
close(5)                                = 0
mprotect(0x7f565ae4c000, 4096, PROT_READ) = 0
munmap(0x7f565ae4e000, 155550)          = 0
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 5
fstat(5, {st_mode=S_IFREG|0644, st_size=155550, ...}) = 0
mmap(NULL, 155550, PROT_READ, MAP_PRIVATE, 5, 0) = 0x7f565ae4e000
close(5)                                = 0
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libnss_dns.so.2", O_RDONLY|O_CLOEXEC) = 5
read(5, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0 #\0\0\0\0\0\0"..., 832) = 832
fstat(5, {st_mode=S_IFREG|0644, st_size=31176, ...}) = 0
mmap(NULL, 32984, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 5, 0) = 0x7f565ae3f000
mmap(0x7f565ae41000, 16384, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 5, 0x2000) = 0x7f565ae41000
mmap(0x7f565ae45000, 4096, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 5, 0x6000) = 0x7f565ae45000
mmap(0x7f565ae46000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 5, 0x6000) = 0x7f565ae46000
close(5)                                = 0
mprotect(0x7f565ae46000, 4096, PROT_READ) = 0
munmap(0x7f565ae4e000, 155550)          = 0
socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 5
setsockopt(5, SOL_IP, IP_RECVERR, [1], 4) = 0
connect(5, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("192.168.1.1")}, 16) = 0
poll([{fd=5, events=POLLOUT}], 1, 0)    = 1 ([{fd=5, revents=POLLOUT}])
sendmmsg(5, [{msg_hdr={msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base=">\326\1\0\0\1\0\0\0\0\0\0\3www\rstackoverflow\3c"..., iov_len=39}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, msg_len=39}, {msg_hdr={msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="w\256\1\0\0\1\0\0\0\0\0\0\3www\rstackoverflow\3c"..., iov_len=39}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, msg_len=39}], 2, MSG_NOSIGNAL) = 2
poll([{fd=5, events=POLLIN}], 1, 5000^C)  = ? ERESTART_RESTARTBLOCK (Interrupted by signal)
strace: Process 1242328 detached

欢迎任何想法。

更新:

我现在怀疑是路由器/调制解调器的连接问题。但非常奇怪的是,接下来是慢的在我的 Ubuntu 桌面上,但在笔记本电脑(OSX)上正常。

ping dsldevice.lan
PING dsldevice.lan (192.168.1.254) 56(84) bytes of data.
64 bytes from dsldevice.lan (192.168.1.254): icmp_seq=1 ttl=63 time=2.08 ms
64 bytes from dsldevice.lan (192.168.1.254): icmp_seq=2 ttl=63 time=1.89 ms

更新:

经过一番折腾,运行了 apt update 并重启后,似乎已经恢复正常了。我查看了之前(问题发生时)和之后的 tcpdump,没有发现什么异常。

仍然不知道,但现在问题暂时消失了。如果再次出现,将更新。这似乎是一个很好的学习练习。

更新:(这篇文章越来越长了)

关于 MTU 问题的参考,我正在从 Ubuntu 无线连接到有线连接到 plusnet 光纤连接的 netgear 路由器(使用来自场所的 ADSL)。

更新:测试 mtu 大小,如下https://mike632t.wordpress.com/2019/03/03/determine-mtu-size-using-ping/

当我针对 8.8.8.8 测试 mtu 时,我觉得有些地方出了问题?对于较大的尺寸,我收到“消息太长”错误,但当我减小尺寸时,该消息不再出现,但直到尺寸为 68=96-28 时,我才会出现 100% 的数据包丢失。也许出于某种原因,这是意料之中的?

ping -c 4 -M do -s 1472 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 1472(1500) bytes of data.
From 192.168.1.254 icmp_seq=1 Frag needed and DF set (mtu = 1488)
ping: local error: message too long, mtu=1488
ping: local error: message too long, mtu=1488

ping -s $((97 - 28)) -D 8.8.8.8 -c 1
PING 8.8.8.8 (8.8.8.8) 69(97) bytes of data.

--- 8.8.8.8 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms

ping -s $((96 - 28)) -D 8.8.8.8 -c 1
PING 8.8.8.8 (8.8.8.8) 68(96) bytes of data.
[1620817285.571725] 76 bytes from 8.8.8.8: icmp_seq=1 ttl=116 time=10.7 ms

--- 8.8.8.8 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 10.680/10.680/10.680/0.000 ms

更新:另一个数据点。

我怀疑这更像是一个网络论坛,因为我会发现这与 Ubuntu 驱动程序方面的事情无关,正如我之前所怀疑的那样,但目前还不确定

ping -c 3 -s $((1489 - 28)) -M do bbc.co.uk
PING bbc.co.uk (151.101.0.81) 1461(1489) bytes of data.
ping: local error: message too long, mtu=1488
ping: local error: message too long, mtu=1488
ping: local error: message too long, mtu=1488

--- bbc.co.uk ping statistics ---
3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2037ms

ping -c 3 -s $((1488 - 28)) -M do bbc.co.uk
PING bbc.co.uk (151.101.0.81) 1460(1488) bytes of data.
1468 bytes from 151.101.0.81 (151.101.0.81): icmp_seq=1 ttl=58 time=11.8 ms
1468 bytes from 151.101.0.81 (151.101.0.81): icmp_seq=2 ttl=58 time=12.0 ms
1468 bytes from 151.101.0.81 (151.101.0.81): icmp_seq=3 ttl=58 time=10.7 ms

--- bbc.co.uk ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 10.702/11.519/12.029/0.583 ms

更新:

请求的 tracepath 查询结果。这是在 mtu 1500 设置下。请注意,常规 mtr 测试显示速度和延迟良好,并且数据包较少。

tracepath www.ebay.com
 1?: [LOCALHOST]                      pmtu 1488
 1:  www.routerlogin.com                                   1.048ms
 1:  www.routerlogin.com                                   1.003ms
 2:  dsldevice.lan                                         2.037ms
 3:  no reply
 4:  no reply
 5:  128.hiper04.sheff.dial.plus.net.uk                   10.954ms asymm  7
 6:  peer3-et3-1-1.slough.ukcore.bt.net                   85.034ms asymm  7
 7:  peer2-xe8-0-2.telehouse.ukcore.bt.net                25.399ms asymm  8
 8:  no reply
 9:  no reply
10:  no reply
11:  no reply

更新:

只是为了确认,mtu 设置为 1500。

ip link | grep wlxa09f10b9ff56
3: wlxa09f10b9ff56: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DORMANT group default qlen 1000

更新:针对 8.8.8.8 的 ping 测试完整日志

$ ping -c 4 -M do -s 1472 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 1472(1500) bytes of data.
From 192.168.1.254 icmp_seq=1 Frag needed and DF set (mtu = 1488)
ping: local error: message too long, mtu=1488
ping: local error: message too long, mtu=1488
ping: local error: message too long, mtu=1488

--- 8.8.8.8 ping statistics ---
4 packets transmitted, 0 received, +4 errors, 100% packet loss, time 3028ms


$ ping -c 4 -M do -s 1462 8.8.8.8 # may show fragmentation
PING 8.8.8.8 (8.8.8.8) 1462(1490) bytes of data.
ping: local error: message too long, mtu=1488
ping: local error: message too long, mtu=1488
ping: local error: message too long, mtu=1488
ping: local error: message too long, mtu=1488

--- 8.8.8.8 ping statistics ---
4 packets transmitted, 0 received, +4 errors, 100% packet loss, time 3049ms


$ ping -c 4 -M do -s 1452 8.8.8.8 # no fragmentation?
PING 8.8.8.8 (8.8.8.8) 1452(1480) bytes of data.

--- 8.8.8.8 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3003ms


$ ping -c 4 -M do -s 1453 8.8.8.8 # still no fragmentation?
PING 8.8.8.8 (8.8.8.8) 1453(1481) bytes of data.

--- 8.8.8.8 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3005ms


$ ping -c 4 -M do -s 69 8.8.8.8 
PING 8.8.8.8 (8.8.8.8) 69(97) bytes of data.

--- 8.8.8.8 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3004ms


$ ping -c 4 -M do -s 68 8.8.8.8 
PING 8.8.8.8 (8.8.8.8) 68(96) bytes of data.
76 bytes from 8.8.8.8: icmp_seq=1 ttl=116 time=60.2 ms
76 bytes from 8.8.8.8: icmp_seq=2 ttl=116 time=9.07 ms
76 bytes from 8.8.8.8: icmp_seq=3 ttl=116 time=8.89 ms
76 bytes from 8.8.8.8: icmp_seq=4 ttl=116 time=9.04 ms

--- 8.8.8.8 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 8.887/21.802/60.215/22.177 ms

更新

不管怎样,我在 Plusnet 上“使用光纤”,但 ADSL 连接较短(反正他们就是这么告诉我的)。根据此线程,这意味着 Plusnet 路由器默认为 1500,并且我已将所有上游设备(netgear 路由器、ubuntu 桌面)也设置为 1500。

https://community.plus.net/t5/Fibre-Broadband/Maximum-MTU-for-PPPOE/td-p/1214123#:~:text=For%20what%20it's%20worth%3A,to%20a%20MTU%20of%201500

答案1

您的问题在于 DSL 连接的 MTU 设置。

Ubuntu 的网络配置中有一个 MTU 设置,而路由器中有一个 WAN MTU 设置。

对于 DSL,常见的 MTU 设置是 1492。请先尝试此值,然后查看您的网站现在是否可以访问。

要确定正确的设置,请从所有 MTU 设置 = 1500 和 VPN = 关闭开始。(VPN 需要不同的测试)。

在里面terminal

    ping [-c 计数] [-M 执行] [-s 数据包大小] [主机]

使用的选项是:

  • c count:ping 次数
  • M hint:选择路径 MTU 发现策略。可以是do(禁止碎片,即使是本地碎片),want(进行 PMTU 发现,当数据包大小较大时在本地进行碎片),或dont(不设置 DF 标志)。
  • s packet_size:指定要发送的数据字节数。

您应该始终从 1472 开始,然后每次减少 10。一旦收到回复,就增加 1,直到收到碎片数据包。取该值(最后一个好值)并将 28 添加到该值以考虑各种 TCP/IP 标头。例如,假设 1452 是合适的数据包大小(您第一次收到对 ping 的 ICMP 回复)。实际的 MTU 大小将是 1480,这是我们正在使用的网络的最佳值。

    ping -c 4 -M do -s 1472 8.8.8.8# 这可能会显示碎片

    ping -c 4 -M do -s 1462 8.8.8.8# 可能会显示碎片

    ping -c 4 -M do -s 1452 8.8.8.8# 没有碎片?

    ping -c 4 -M do -s 1453 8.8.8.8# 仍然没有碎片?

参考:如何使用 ICMP ping 确定适当的 MTU 大小

相关内容