山西电信，延迟只有 40+ms，令人难以置信
正在 Ping 8.8.8.8 具有 32 字节的数据:
来自 8.8.8.8 的回复: 字节=32 时间=48ms TTL=52
来自 8.8.8.8 的回复: 字节=32 时间=47ms TTL=52
来自 8.8.8.8 的回复: 字节=32 时间=48ms TTL=52
来自 8.8.8.8 的回复: 字节=32 时间=47ms TTL=52
8.8.8.8 的 Ping 统计信息:
数据包: 已发送 = 4，已接收 = 4，丢失 = 0 (0% 丢失)，
往返行程的估计时间(以毫秒为单位):
最短 = 47ms，最长 = 48ms，平均 = 47ms
A：浙江电信：
正在 Ping 8.8.8.8 具有 32 字节的数据:
来自 8.8.8.8 的回复: 字节=32 时间=35ms TTL=51
来自 8.8.8.8 的回复: 字节=32 时间=35ms TTL=51
来自 8.8.8.8 的回复: 字节=32 时间=35ms TTL=51
来自 8.8.8.8 的回复: 字节=32 时间=35ms TTL=51
8.8.8.8 的 Ping 统计信息:
数据包: 已发送 = 4，已接收 = 4，丢失 = 0 (0% 丢失)，
往返行程的估计时间(以毫秒为单位):
最短 = 35ms，最长 = 35ms，平均 = 35ms
还真的是啊，别紧张可能是错觉
B：因为给你回应的 8.8.8.8 不是真正的 8.8.8.8，运营商做手脚了
C：试了下 DoT 可以用 DoH 不能用
root@debian:~# ./tcpping dns.google 853
seq 0: tcp response from dns.google (8.8.4.4) [open] 32.166 ms
seq 1: tcp response from dns.google (8.8.4.4) [open] 32.216 ms
seq 2: tcp response from dns.google (8.8.4.4) [open] 31.426 ms
seq 3: tcp response from dns.google (8.8.4.4) [open] 31.875 ms
seq 4: tcp response from dns.google (8.8.4.4) [open] 31.209 ms
^C
root@debian:~# ./tcpping dns.google 443
seq 0: no response (timeout)
seq 1: no response (timeout)
seq 2: no response (timeout)
seq 3: no response (timeout)
seq 4: no response (timeout)
seq 5: no response (timeout)
D：我这更低...怀疑是假的
正在 Ping 8.8.8.8 具有 32 字节的数据:
来自 8.8.8.8 的回复: 字节=32 时间=14ms TTL=242
来自 8.8.8.8 的回复: 字节=32 时间=17ms TTL=242
来自 8.8.8.8 的回复: 字节=32 时间=12ms TTL=242
来自 8.8.8.8 的回复: 字节=32 时间=13ms TTL=242
8.8.8.8 的 Ping 统计信息:
数据包: 已发送 = 4，已接收 = 4，丢失 = 0 (0% 丢失)，
往返行程的估计时间(以毫秒为单位):
最短 = 12ms，最长 = 17ms，平均 = 14ms
E：从几年前开始 8888 的 icmp 延迟就很好看了.
但 tcp 和 udp 有时会被概率性人为丢包,重点时期概率会变高.
所以不建议单配 8888 为 dns.
F：@Archeb 怎么做到的请问?深圳电信 8888 和 8844 分别是 20ms 和 18ms,就算绕路广州出去也不能无缘无故多出 10ms 来啊,奇怪了.