我们有两条不同的通往服务器的路线。
- 其中一个延迟超过 20000 毫秒，而另一个则没有。
- 延迟恰好发生在同一路由和同一节点上。
- 当用户通过此路径访问服务器时，他们会抱怨互联网性能。
我的问题是，这种延迟是否真的导致了这个问题，还是我们必须考虑其他因素。
注意：我们有良好的带宽监控系统，我们知道我们的任何工作站是否存在带宽滥用的情况。
第一天路线
Start: Sun Oct 8 13:52:18 2017
HOST: gw131 Loss% Snt Last Avg Best Wrst StDev
1.|-- gateway 3.3% 30 0.2 0.3 0.2 0.9 0.0
2.|-- 172.16.65.97 0.0% 30 0.5 0.5 0.4 1.2 0.0
3.|-- 202.53.163.113 0.0% 30 0.4 0.5 0.4 1.0 0.0
4.|-- 103.12.172.217 0.0% 30 1.1 0.8 0.5 5.9 1.0
5.|-- 103.12.172.237 0.0% 30 0.8 0.8 0.5 4.6 0.7
6.|-- ix-ge-2-0-1-0.tcore3.MLV- 3.3% 30 87.4 87.6 87.3 90.6 0.6
7.|-- if-ae-4-2.tcore1.MLV-Mumb 0.0% 30 185.0 185.7 184.9 190.6 1.2
8.|-- if-ae-9-5.tcore1.WYN-Mars 0.0% 30 204.3 203.9 203.6 205.8 0.5
9.|-- if-ae-8-1600.tcore1.PYE-P 0.0% 30 184.7 185.8 184.5 204.9 3.8
10.|-- if-ae-11-2.tcore1.PVU-Par 0.0% 30 203.2 203.1 202.8 206.4 0.6
11.|-- 80.231.153.66 0.0% 30 185.2 185.9 185.2 196.7 2.1
12.|-- ae-2-3601.ear2.Washington 70.0% 30 24311 23996 23078 24311 412.9
13.|-- SUNGARD-NET.ear2.Washingt 0.0% 30 263.0 262.4 260.8 293.2 5.8
14.|-- phl3cr1-te-0-0-1-2.sgns.n 0.0% 30 282.5 282.5 282.1 285.6 0.6
15.|-- smy1cr1-te-0-0-0-2.sgns.n 3.3% 30 277.8 278.3 277.6 286.4 1.5
16.|-- dal2cr1-te-0-1-0-2.sgns.n 6.7% 30 281.5 281.8 281.5 284.7 0.5
17.|-- 66.179.229.126 0.0% 30 284.7 284.7 284.2 291.5 1.3
18.|-- ??? 100.0 30 0.0 0.0 0.0 0.0 0.0
第二天路线：
Start: Mon Oct 9 21:32:07 2017
HOST: gw131 Loss% Javg Last Avg Best Wrst StDev
1.|-- gateway 0.0% 0.7 0.2 0.6 0.1 4.9 1.0
2.|-- 172.16.65.97 0.0% 1.3 0.5 1.1 0.3 9.4 1.8
3.|-- 202.53.163.113 0.0% 3.1 0.8 2.1 0.4 37.1 6.7
4.|-- 103.12.172.217 0.0% 1.7 0.5 1.5 0.5 6.1 1.7
5.|-- 103.12.172.249 0.0% 1.7 0.6 1.7 0.5 8.1 1.9
6.|-- 103-16-155-89-noc.bsccl.c 0.0% 1.4 1.1 1.8 1.0 9.1 1.8
7.|-- 103-16-152-30-noc.bsccl.c 0.0% 1.7 1.2 2.2 1.0 10.3 2.1
8.|-- 103-16-152-34-noc.bsccl.c 0.0% 1.5 5.9 6.5 5.5 14.5 1.8
9.|-- 116.51.31.233 0.0% 0.9 58.0 58.8 58.0 60.9 0.5
10.|-- ae-17.a00.sngpsi05.sg.bb. 0.0% 2.3 58.1 59.6 57.7 66.8 2.3
11.|-- ae-0.level3.sngpsi05.sg.b 16.7% 3391 7458. 3324. 73.2 7738. 3008.0
12.|-- ae-2-3601.ear2.Washington 63.3% 271. 23772 23481 22938 24086 373.8
13.|-- SUNGARD-NET.ear2.Washingt 0.0% 16.4 309.7 304.5 288.8 353.5 16.1
14.|-- phl3cr1-te-0-0-1-2.sgns.n 0.0% 9.2 310.4 324.5 310.4 340.9 10.7
15.|-- smy1cr1-te-0-0-0-2.sgns.n 0.0% 11.1 328.1 317.0 305.9 335.9 9.6
16.|-- dal2cr1-te-0-1-0-2.sgns.n 0.0% 9.4 310.3 321.1 310.2 334.2 9.2
17.|-- 66.179.229.126 0.0% 10.0 312.3 323.6 312.3 342.3 10.1
18.|-- 95-216.205.157.appsitehos 0.0% 15.2 335.8 342.6 325.9 391.6 17.3
第 3 天路线：
gw131 (0.0.0.0) Tue Oct 10 14:36:21 2017
Resolver: Received error response 2. (server failure)er of fields quit
Packets Pings
Host Loss% Javg Last Avg Best Wrst StDev
1. 202.53.167.129 0.0% 0.4 0.2 0.4 0.1 6.8 0.7
2. 172.16.65.97 0.0% 0.5 0.5 0.7 0.4 5.4 0.7
3. 202.53.163.113 0.0% 2.0 2.1 1.9 0.4 22.6 4.2
4. 103.12.172.217 0.0% 0.7 0.6 0.9 0.5 9.1 1.2
5. 103.12.172.249 0.0% 0.6 0.7 1.0 0.5 7.7 0.8
6. 103-16-155-89-noc.bsccl.com 0.0% 1.0 1.3 1.7 1.0 9.3 1.3
7. 103-16-152-30-noc.bsccl.com 0.0% 23.1 1.5 12.9 1.1 1002. 105.5
8. 103-16-152-34-noc.bsccl.com 0.0% 0.7 5.8 6.1 5.5 13.6 1.1
9. 116.51.31.233 0.0% 23.3 58.4 70.0 57.9 1063. 105.9
10. ae-17.a00.sngpsi05.sg.bb.gin.ntt.net 0.0% 2.4 58.0 59.4 57.6 77.7 3.2
11. ae-0.level3.sngpsi05.sg.bb.gin.ntt.net 15.6% 4179 7084. 3128. 69.5 7247. 2939.
12. ae-2-3601.ear2.Washington1.Level3.net 26.7% 748. 23577 23876 17859 27371 1073.
103-16-155-89-noc.bsccl.com
13. SUNGARD-NET.ear2.Washington1.Level3.net 0.0% 8.1 312.6 305.7 288.8 335.4 10.6
14. phl3cr1-te-0-0-1-2.sgns.net 0.0% 8.8 311.1 327.1 309.8 344.1 9.1
15. smy1cr1-te-0-0-0-2.sgns.net 0.0% 8.0 327.6 322.1 305.3 344.3 9.7
16. dal2cr1-te-0-1-0-2.sgns.net 0.0% 8.2 332.2 328.0 309.4 356.0 9.5
17. 66.179.229.126 0.0% 10.7 334.8 329.5 311.9 359.7 10.2
18. 95-216.205.157.appsitehosting.com 0.0% 38.0 331.8 352.5 311.3 1329. 106.2
答案1
20秒任何网络上的延迟都会成为一种性能灾难适用于任何类型的交互式工作，如果你有的话。但你没有。
在从一跳到远程主机的旅程中，您会遇到高延迟（和数据包丢失）。这种情况并不罕见，特别是如果您使用基于 ICMP 的跟踪路由，因为大多数网络设备优先考虑实际路由流量发送 ICMP ttl-exceededs 来获取因时间过长而失效的随机 PING。从该主机远端的跃点 (13-17) 可以看出，您的流量通过时没有此类延迟通过主机。您最大的单跳到跳延迟是在跳 6 和 7 之间，这似乎是您 ISP 内部的点对点链接，可能已经饱和。您可以考虑监控它，如果这种情况持续一段时间，请向您的 ISP 投诉（没有 ISP 会回应您运行一次跟踪路由并发现链接问题的投诉，这是正确的）。
至于导致问题的原因是什么“互联网性能“，这是一个无法量化的问题，无法推测。如果你能从用户那里得到更清晰的问题陈述，那么可能就可以设计实验来阐明它。
另外，请不要发布文本输出的图像；链接会失效，您的问题的证据也会丢失，而且它们无法搜索，因为文本无法搜索。我已将图像放入您的问题中（我怀疑您缺乏这样做的声誉，这不是您的错） - 但最佳做法是将文本剪切并粘贴到您的问题中。