问题
很长一段时间以来,我的网络连接一直出现问题,尽管速度与 ISP 提供的一样快(经测试https://speed.cloudflare.com/)。具体来说,当我访问一个网站(或者甚至在 ping 一个 IP 时),会出现一个延迟这似乎与实际速度。
这是 ping 维基百科的结果:
$ time ping -c 5 wikipedia.org
PING wikipedia.org (91.198.174.192) 56(84) bytes of data.
64 bytes from 91.198.174.192: icmp_seq=1 ttl=57 time=46.1 ms
64 bytes from 91.198.174.192: icmp_seq=2 ttl=57 time=48.6 ms
64 bytes from text-lb.esams.wikimedia.org (91.198.174.192): icmp_seq=3 ttl=57 time=48.2 ms
64 bytes from text-lb.esams.wikimedia.org (91.198.174.192): icmp_seq=4 ttl=57 time=48.5 ms
64 bytes from 91.198.174.192: icmp_seq=5 ttl=57 time=46.3 ms
--- wikipedia.org ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 26204ms
rtt min/avg/max/mdev = 46.085/47.527/48.634/1.100 ms
ping -c 5 wikipedia.org 0.01s user 0.00s system 0% cpu 27.280 total
^--- this is way too high
请注意,尽管 ping 响应时间在 ms 数量级(~48ms),但所花费的总时间(以 测量time
)要高得多(~27s)。
我尝试使用 Wireshark 来调试这个问题,并观察到一个一致的模式:DHCP Discover
数据包之间有很大的延迟,如下所示:
No. Time
13 1.741054670 0.0.0.0 255.255.255.255 DHCP 590 DHCP Discover - Transaction ID 0xdefe259a
14 4.813077659 0.0.0.0 255.255.255.255 DHCP 590 DHCP Discover - Transaction ID 0xdefe259a
# ~3s delay
以下是两个连续 ping 请求/答复之间的更大上下文:
10 1.115798068 192.168.0.107 91.198.174.192 ICMP 98 Echo (ping) request id=0x0009, seq=2/512, ttl=64 (reply in 11)
/---> 11 1.163998347 91.198.174.192 192.168.0.107 ICMP 98 Echo (ping) reply id=0x0009, seq=2/512, ttl=57 (request in 10)
| 12 1.164386243 192.168.0.107 192.168.0.1 DNS 87 Standard query 0x4e78 PTR 192.174.198.91.in-addr.arpa
| 13 1.741054670 0.0.0.0 255.255.255.255 DHCP 590 DHCP Discover - Transaction ID 0xdefe259a
5s 14 4.813077659 0.0.0.0 255.255.255.255 DHCP 590 DHCP Discover - Transaction ID 0xdefe259a
| 15 6.169712508 192.168.0.107 192.168.0.1 DNS 87 Standard query 0x4e78 PTR 192.174.198.91.in-addr.arpa
| 16 6.200238569 192.168.0.1 192.168.0.107 DNS 128 Standard query response 0x4e78 PTR 192.174.198.91.in-addr.arpa PTR text-lb.esams.wikimedia.org
\---> 17 6.200452771 192.168.0.107 91.198.174.192 ICMP 98 Echo (ping) request id=0x0009, seq=3/768, ttl=64 (reply in 18)
18 6.246764831 91.198.174.192 192.168.0.107 ICMP 98 Echo (ping) reply id=0x0009, seq=3/768, ttl=57 (request in 17)
我注意到由于DHCP Discover
多次捕获而导致的这种延迟。
我尝试过
- 静态 IP(路由器上的 DHCP 旁路)
- 路由器和电脑重置
- 不同的浏览器
- 不同的内核
- 有线连接:PPPoE 也会出现同样的延迟
- 不同的设备:此问题不存在于此网络上连接的任何其他设备上,因此很可能是 Linux / 笔记本电脑的问题
系统信息
System:
Kernel: 6.0.15-1-MANJARO arch: x86_64 bits: 64 compiler: gcc v: 12.2.0
Desktop: GNOME v: 43.2 Distro: Manjaro Linux base: Arch Linux
Machine:
Type: Laptop System: LENOVO product: 82K8 v: Legion S7 15ACH6
serial: <filter>
Mobo: LENOVO model: LNVNB161216 v: NO DPK serial: <filter> UEFI: LENOVO
v: HACN31WW date: 11/19/2021
Network:
Device-1: Intel Wi-Fi 6 AX200 vendor: Rivet Networks Killer™
driver: iwlwifi v: kernel bus-ID: 02:00.0
IF: wlp2s0 state: up mac: <filter>
我可以尝试什么来进一步调试这个问题?
答案1
DHCP 发现消息可能是个障眼法,可能是您网络中的其他设备在您执行 ping 操作的同时尝试获取 dhcp 地址(这些是向您的网络发送的广播消息,因此网络中的所有内容都可以看到它们)。
所有 ping 之间的 5 秒延迟是否一致?我猜 ping 是使用“-i 5”选项或类似选项运行的,您能否检查一下 ping 是否有别名或类似名称?
您可以在 ping 运行时尝试“ps axuw | grep ping”,看看 ping 命令是否与您运行的完全一样,或者它是否有其他参数,比如我上面提到的“-i 5”。
更新
在更详细地查看了您的 tcpdump 之后,它似乎与 DNS 查询更相关。请注意,在 1.164386243 处没有对第一个查询的答复,并且在 5 秒超时后,您的解析器会重试在 6.169712508 处的查询,并收到答复,并且 ping 可以正常继续。您可能可以使用 /etc/resolv.conf 中的选项来减少延迟,但如果您能调试为什么您的 dns 服务器不响应第一个查询,那就更好了。
要验证是 DNS 导致了延迟,您可以尝试使用 -n 进行 ping 以避免 ping 中的名称解析(但相同的 DNS 5 秒延迟在其他情况下也会导致类似的问题)。