MTRレポート分析
サーバーへの2つの異なるルートがあります。
- 1つは、20000ミリ秒以上の遅延のこの遅延を持っています。他はそれを持っていません。
- 遅延は、まったく同じルートと同じノードで発生します。
- ユーザーは、このルートを介してサーバーに到達しているときに、インターネットのパフォーマンスについて不満を持っています。
私の質問は、この待ち時間が実際にこの問題を引き起こしているのか、それとも他の要因を調べる必要があるのかということです。
注：優れた帯域幅監視システムがあり、ワークステーションのいずれかから帯域幅の乱用がないかどうかを確認しています。
1日目ルート
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 seconds任意のネットワークでの遅延はパフォーマンスになりますdisasterあらゆる種類のインタラクティブな作業（ある場合）。しかし、あなたはしません。
リモートホストへの移動中に1ホップからtraceroute応答を取得すると、待ち時間が長くなります（パケット損失が発生します）。これは珍しいことではありません。特にICMPベースのtracerouteを使用している場合は、ほとんどのネットワークデバイスがICMPttlの送信よりも実際にトラフィックをルーティングするを優先するためです。そのホストの向こう側のホップ（13-17）からわかるように、ホストを通過するトラフィックにそのような遅延はありませんthrough。最大のシングルホップツーホップ遅延はホップ6と7の間です。これは、ISP内のポイントツーポイントリンクのようで、おそらく飽和状態になっています。それを監視し、しばらくの間ISPに苦情を申し立てることを検討してください（1つのtracerouteを実行し、リンクの問題が発生したという苦情にISPは対応しませんが、当然のことながら対応しません）。
「インターネットパフォーマンス」の問題の原因については、それは定量化されていない問題であり、推測することは不可能です。ユーザーからより明確な問題の説明を得ることができれば、それに光を当てるための実験を設計することが可能かもしれません。
余談ですが、テキスト出力の画像を投稿しないでください。リンク切れが発生し、質問に対する証拠が失われ、テキストが検索されないため、検索できなくなります。私はあなたの質問に画像を入れました（あなたがするべき担当者が不足していること、私はあなたのせいではないと思います）-しかし、ベストプラクティスは代わりにあなたの質問にテキストをカットアンドペーストすることです。