Dew*_*lam 4 performance internet mtr
我们有两个不同的路由到服务器。
我的问题是，这种延迟实际上是导致此问题的原因，还是我们必须考虑其他因素。
注意：我们有一个很好的带宽监控系统，我们知道我们的任何工作站是否存在任何带宽滥用。
第一天路线
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
第 2 天路线：
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
任何网络上的20秒延迟对于任何类型的交互式工作来说都是一场性能灾难，如果你有的话。但你没有。
在从您到远程主机的旅程中的一跳获取跟踪路由响应时，您会遇到高延迟（和数据包丢失）。这种情况并不少见，尤其是当您使用基于 ICMP 的跟踪路由时，因为大多数网络设备优先考虑实际路由流量，而不是发送 ICMP ttl-exceededs 关于因年老而死亡的随机 PING。正如你可以从啤酒花看到该主机（13-17）的另一边，也有你的流量不经过这样的延迟通过主人。您最大的单跳到跳延迟在第 6 跳和第 7 跳之间，这似乎是您的 ISP 内部的点对点链路，可能已饱和。您可能会考虑对其进行监控并在一段时间内仍然如此时向您的 ISP 投诉（没有 ISP 会回应您运行一个跟踪路由并看到链接问题的投诉，这是正确的）。
至于是什么导致“互联网性能”出现问题，这是一个无法量化的问题，无法推测。如果你能从用户那里得到更清晰的问题陈述，就有可能设计实验来阐明它。
顺便说一句，请不要发布文本输出的图像；链接腐烂，您的问题丢失了证据，并且它们无法搜索，因为文本不会。我已将图像放入您的问题中（我怀疑您缺少代表做的事情，这不是您的错）-但最佳做法是将文本剪切并粘贴到您的问题中。
| 归档时间： |
|
| 查看次数： |
942 次 |
| 最近记录： |