主页 / ubuntu / 问题 / 1337125
Accepted
mathtick
Asked: 2021-05-10 03:40:10 +0800 CST

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

  • 772

所以让我怀疑的关键症状是，当我在 Ubuntu 上运行 ping 并在 OSX 笔记本电脑上几乎立即启动时，ping 大约需要一秒钟左右的时间才能开始打印（我的笔记本电脑上没有 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 和 speed test 的指标都很好。例如，这是在 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 时，我认为有些地方很不对劲？对于较大的尺寸，我收到“消息太长”错误，但随着我减小尺寸，消息不再出现，但我得到 100% 的数据包丢失，直到尺寸 68=96-28。也许出于某种原因这是预期的？

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

更新：

请求的跟踪路径查询的结果。这是 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。

networking

2 个回答

  1. Best Answer

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

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

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

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

    在terminal：

        ping [-c count] [-M do] [-s packet_size] [host]

    使用的选项是：

    • 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 大小

    • 1

  2. 检查您的 WiFi MTU，使用

    ip link

    还要注意您的 WiFi 接口的名称。

    ( MTUMaximum Transmission Unit)是单次网络传输可以发送的最大数据包的大小。如果一个数据包超出 MTU了链路的范围，则数据必须拆分为多个数据包（分段）。这些多个数据包必须通过链路发送、接收、确认并在远端重新组合。如果您的链接配置错误，并且您必须对发送的每个数据包进行分段，那么您的实际数据传输率就会下降。

    以太网（有线）网络使用MTU1500 字节。

    由于 WiFi 的每个数据包额外开销（8 字节 PPPoE 标头），WiFi 使用MTU1492。

    您MTU应该由您的 DHCP 服务器设置，检查您的路由器的配置。

    您可以设置自己的MTU（设置不会在重新启动后持续存在）

    ip link set dev name mtu 1492

    其中“name”是上面的接口名称。

    这是一个例子：

    walt@squid:~(0)$ ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp63s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN mode DEFAULT group default qlen 1000
    link/ether 00:24:21:7f:e5:1c brd ff:ff:ff:ff:ff:ff
3: wlxf46d04b1790f: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN mode DORMANT group default qlen 1000
    link/ether f4:6d:04:b1:79:0f brd ff:ff:ff:ff:ff:ff
walt@squid:~(0)$   sudo ip link set dev wlxf46d04b1790f mtu 1492
[sudo] password for walt: 
walt@squid:~(0)$ ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp63s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN mode DEFAULT group default qlen 1000
    link/ether 00:24:21:7f:e5:1c brd ff:ff:ff:ff:ff:ff
3: wlxf46d04b1790f: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1492 qdisc mq state UP mode DORMANT group default qlen 1000
    link/ether f4:6d:04:b1:79:0f brd ff:ff:ff:ff:ff:ff

    我的 WiFi“接口名称”是“ wlxf46d04b1790f”。

    • 0

相关问题