Folding@Home域名解析失败问题解决方案

wpf999

WaltherNernst 发表于 2016-1-17 17:14
自己去抓包

在我验证之前，我只问你抓过包吗，看过时间吗？

wpf999

WaltherNernst 发表于 2016-1-17 17:14
自己去抓包

同学，你需要多几分严谨。实证显示消耗0.24s，而不是几个毫秒。

其实最简单的办法是

1. C:\Users\root>ping 171.64.7.61
   
2. 
   
3. 正在 Ping 171.64.7.61 具有 32 字节的数据:
   
4. 来自 171.64.7.61 的回复: 字节=32 时间=239ms TTL=46
   
5. 来自 171.64.7.61 的回复: 字节=32 时间=237ms TTL=46
   
6. 来自 171.64.7.61 的回复: 字节=32 时间=234ms TTL=46
   
7. 来自 171.64.7.61 的回复: 字节=32 时间=240ms TTL=46
   
8. 
   
9. 171.64.7.61 的 Ping 统计信息:
   
10.     数据包: 已发送 = 4，已接收 = 4，丢失 = 0 (0% 丢失)，
    
11. 往返行程的估计时间(以毫秒为单位):
    
12.     最短 = 234ms，最长 = 240ms，平均 = 237ms
    
13. 
    
14. C:\Users\root>ping 171.64.7.88
    
15. 
    
16. 正在 Ping 171.64.7.88 具有 32 字节的数据:
    
17. 来自 171.64.7.88 的回复: 字节=32 时间=274ms TTL=46
    
18. 来自 171.64.7.88 的回复: 字节=32 时间=285ms TTL=46
    
19. 来自 171.64.7.88 的回复: 字节=32 时间=238ms TTL=46
    
20. 来自 171.64.7.88 的回复: 字节=32 时间=238ms TTL=46
    
21. 
    
22. 171.64.7.88 的 Ping 统计信息:
    
23.     数据包: 已发送 = 4，已接收 = 4，丢失 = 0 (0% 丢失)，
    
24. 往返行程的估计时间(以毫秒为单位):
    
25.     最短 = 238ms，最长 = 285ms，平均 = 258ms
    
26. 
    
27. C:\Users\root>ping 171.64.7.115
    
28. 
    
29. 正在 Ping 171.64.7.115 具有 32 字节的数据:
    
30. 来自 171.64.7.115 的回复: 字节=32 时间=194ms TTL=46
    
31. 来自 171.64.7.115 的回复: 字节=32 时间=198ms TTL=46
    
32. 来自 171.64.7.115 的回复: 字节=32 时间=196ms TTL=46
    
33. 来自 171.64.7.115 的回复: 字节=32 时间=193ms TTL=46
    
34. 
    
35. 171.64.7.115 的 Ping 统计信息:
    
36.     数据包: 已发送 = 4，已接收 = 4，丢失 = 0 (0% 丢失)，
    
37. 往返行程的估计时间(以毫秒为单位):
    
38.     最短 = 193ms，最长 = 198ms，平均 = 195ms
    
39. 
    

复制代码

金鹏

WaltherNernst 发表于 2016-1-16 22:36
@wpf999  @Lynt     @金鹏
看一楼更新

宁波电信光纤100M,设置的114主DNS, 8.8.4.4的备用DNS

1. Microsoft Windows [版本 6.1.7601]
   
2. 版权所有 (c) 2009 Microsoft Corporation。保留所有权利。
   
3. 
   
4. C:\Users\HuHu>ping 171.64.7.61
   
5. 
   
6. 正在 Ping 171.64.7.61 具有 32 字节的数据:
   
7. 来自 171.64.7.61 的回复: 字节=32 时间=164ms TTL=51
   
8. 来自 171.64.7.61 的回复: 字节=32 时间=164ms TTL=51
   
9. 来自 171.64.7.61 的回复: 字节=32 时间=164ms TTL=51
   
10. 来自 171.64.7.61 的回复: 字节=32 时间=163ms TTL=51
    
11. 
    
12. 171.64.7.61 的 Ping 统计信息:
    
13.     数据包: 已发送 = 4，已接收 = 4，丢失 = 0 (0% 丢失)，
    
14. 往返行程的估计时间(以毫秒为单位):
    
15.     最短 = 163ms，最长 = 164ms，平均 = 163ms
    
16. 
    
17. C:\Users\HuHu>ping 171.64.7.88
    
18. 
    
19. 正在 Ping 171.64.7.88 具有 32 字节的数据:
    
20. 来自 171.64.7.88 的回复: 字节=32 时间=187ms TTL=51
    
21. 来自 171.64.7.88 的回复: 字节=32 时间=187ms TTL=51
    
22. 来自 171.64.7.88 的回复: 字节=32 时间=187ms TTL=51
    
23. 来自 171.64.7.88 的回复: 字节=32 时间=178ms TTL=51
    
24. 
    
25. 171.64.7.88 的 Ping 统计信息:
    
26.     数据包: 已发送 = 4，已接收 = 4，丢失 = 0 (0% 丢失)，
    
27. 往返行程的估计时间(以毫秒为单位):
    
28.     最短 = 178ms，最长 = 187ms，平均 = 184ms
    
29. 
    
30. C:\Users\HuHu>ping 171.64.7.115
    
31. 
    
32. 正在 Ping 171.64.7.115 具有 32 字节的数据:
    
33. 来自 171.64.7.115 的回复: 字节=32 时间=179ms TTL=51
    
34. 来自 171.64.7.115 的回复: 字节=32 时间=173ms TTL=51
    
35. 来自 171.64.7.115 的回复: 字节=32 时间=170ms TTL=51
    
36. 来自 171.64.7.115 的回复: 字节=32 时间=176ms TTL=51
    
37. 
    
38. 171.64.7.115 的 Ping 统计信息:
    
39.     数据包: 已发送 = 4，已接收 = 4，丢失 = 0 (0% 丢失)，
    
40. 往返行程的估计时间(以毫秒为单位):
    
41.     最短 = 170ms，最长 = 179ms，平均 = 174ms
    
42. 
    
43. C:\Users\HuHu>

复制代码

WaltherNernst

wpf999 发表于 2016-1-17 19:10
同学，你需要多几分严谨。实证显示消耗0.24s，而不是几个毫秒。

其实最简单的办法是 ...

在我这确实在10ms左右。各地网络不相同，这个我无法做出任何保证，只能使用者自己判断。

wpf999

WaltherNernst 发表于 2016-1-17 21:00
在我这确实在10ms左右。各地网络不相同，这个我无法做出任何保证，只能使用者自己判断。 ...

除非你在美国，你在中国是不可能这么低的延迟的。      问问 @ManHo

ManHo

wpf999 发表于 2016-1-17 21:08
除非你在美国，你在中国是不可能这么低的延迟的。      问问 @ManHo

这个还真不一定，有个技术叫Anycast。说不定Stanford有亚洲的DNS服务器的。
选路的规则就算ISP相同也可能不一样，家用电信宽带我ping 8.8.4.4每次都是美国西岸，学校宿舍的电信Ping 8.8.4.4每次都是Google香港，也就能看出一个是170ms的延迟一个是4ms的延迟，具体情况只能用traceroute看



还有一个可能就是 某些ISP又偷偷用公网IP放在内网用了（移动就干过这种事）

Lynt

深圳电信171ms

yimu35

不在美国的北美某小城， 42ms.   @wpf999
物理距离(我家->某大学campus)

wpf999

ManHo 发表于 2016-1-17 21:18
这个还真不一定，有个技术叫Anycast。说不定Stanford有亚洲的DNS服务器的。
选路的规则就算ISP相同也可能 ...

跨洋通信延迟就不可能太低

wpf999

WaltherNernst 发表于 2016-1-17 21:00
在我这确实在10ms左右。各地网络不相同，这个我无法做出任何保证，只能使用者自己判断。 ...

你就不要挑战物理规律了，从中国到美国，

8000/300000=0.026

光速都要0.026秒，莫非你家到斯坦福是超光速的信息网络，10ms一个来回。

wpf999

ManHo 发表于 2016-1-17 21:18
这个还真不一定，有个技术叫Anycast。说不定Stanford有亚洲的DNS服务器的。
选路的规则就算ISP相同也可能 ...

Stanford有亚洲的DNS服务器，请给出证据

WaltherNernst

wpf999 发表于 2016-1-17 21:51
Stanford有亚洲的DNS服务器，请给出证据

还有一种可能性是运营商的通信缓存，确实没考虑到这种可能性。
刚刚发现TTL很高，确实很可能是被运营商抓了缓存。

wpf999

WaltherNernst 发表于 2016-1-17 22:13
还有一种可能性是运营商的通信缓存，确实没考虑到这种可能性。
刚刚发现TTL很高，确实很可能是被运营商抓 ...

缓存说倒是有可能，但需要验证。