我们通过SSH在数据中心的大部分同事服务器上执行这些工作。 这意味着我们几乎整天都在连接到这些盒子，每周5天。 间歇地，我们会看到在键盘上打字之间有一段时间的滞后，并且让内容在shell上回显给我们。 我开始做一些挖掘工作，对理解结果有困难。 我也在寻找下一步的步骤。 早些时候，我运行了tcp.dstport == 22的wireshark trace，这似乎是我们遇到的大多数问题。 我注意到TCP重传是一个很大的问题（数千个包中有10-20个）。 我认为这与我们所看到的滞后问题有关。
1）mtr到远程主机
Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. 192.168.100.254 76.6% 454 0.5 0.5 0.3 4.7 0.4 2. 10.113.128.1 80.6% 454 17.3 130.8 5.7 6030. 726.7 3. 74.128.19.209 79.5% 454 9.7 25.8 6.7 1270. 133.2 4. 74.128.8.233 80.6% 454 8.5 31.9 6.6 1369. 150.6 5. 4.71.250.1 79.2% 454 1547. 50.5 14.7 1547. 194.1 6. 4.69.138.158 80.4% 454 20.1 29.7 15.4 1003. 104.5 7. 4.69.140.189 74.2% 454 16.2 28.6 15.0 920.0 85.5 8. 4.69.138.4 72.6% 454 17.0 41.2 15.5 821.6 81.7 9. ??? 10. 216.26.190.9 79.4% 453 45.2 105.8 24.4 3008. 406.7 11. 216.26.162.162 90.7% 453 28.3 40.2 24.1 556.3 81.7
2）mtr到192.168.100.254（同时发生到mtr以上）
Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. 192.168.100.254 0.0% 591 0.8 0.4 0.3 6.9 0.5
第一个问题：为什么顶层mtrbuild议在192.168.100.254丢失数据包，而最底层的那个没有？
第二个问题：我怎样才能更好地确定可能造成这种情况？
编辑 ：
mtr首先在我们的networking之外主持：
Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. edge.networldalliance.local 18.1% 393 0.5 0.5 0.4 1.8 0.2 2. 10.113.128.1 0.0% 393 10.0 10.1 5.5 744.3 37.4
单独的mtr到跳转中的第二个主机：
Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. edge.networldalliance.local 87.9% 424 0.8 0.7 0.5 1.2 0.1 2. 10.113.128.1 0.0% 424 9.5 9.5 5.2 577.8 27.8 3. 74-128-19-209.dhcp.insightbb.com 0.0% 423 6.5 10.4 6.2 243.9 12.8
将（再次）mtr分隔到跳转中的第三个主机：
Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. edge.networldalliance.local 87.2% 440 0.6 0.7 0.4 2.2 0.3 2. 10.113.128.1 0.0% 439 6.4 10.9 5.6 991.8 47.2 3. 74-128-19-209.dhcp.insightbb.com 0.0% 439 8.5 13.3 6.5 744.3 35.6 4. 74.128.8.233 0.0% 439 7.9 23.6 6.3 493.8 47.2
基于这个新数据的任何build议？ 我将看到关于更换路由器/防火墙。
直接答案
第一个问题 ：为什么顶层mtrbuild议在192.168.100.254丢失数据包，而最底层的那个没有？
mtr发送ping（ICMP回应响应）并递增IP TTL，直到获得响应。 当响应TTL过期条件（低成功）与ICMP回应响应（高成功）时，192.168.100.254的响应不同，
第二个问题 ：我怎样才能更好地确定可能造成这种情况？
当你说“造成这个”时，我认为你的意思是你的迟缓ssh会话，而不是奇怪的mtr结果…对不对？ 几个想法…
直接运行mtr到11跳path中的每个主机，看看你是否能从其中一个跳跃中find一些有趣的症状; 根据您的第一个mtr ，这可能不会更有成效，但值得一试。 也请咨询192.168.100.254的pipe理员，看看你们是否可以弄清楚为什么ICMP TTL过期的回复会被破坏。
其他的想法
networking问题有三个一般原因：数据包丢失，数据包延迟（排队）或数据包重新sorting。 但是，我们还要记住，有时候主机级别的问题会导致您的问题1 。
让我们暂时假设192.168.100.x vlan不是你问题的地方，你的拓扑看起来像这样：
HOST_A----------------------HOST_B 192.168.100.x 216.26.162.162
如果您尚未从Windows机器到HOST_A ，请执行以下操作2 。 现在logging你的Windows桌面3 。 当问题再次发生时，录制的video对于您的问题可能出现的位置（即networking，主机或两者的组合）来说是非常好的审计线索。 如果你能以某种方式在这个video中看到ntp时间，那么更好…这给你一个通过syslog回溯分析的方法。
END-NOTES
HOST_A和HOST_B之间的ssh，另一个用于HOST_B的嗅探会话，最后两个应该在HOST_A和HOST_B上运行top或vmstat 5 。 对于第二个问题：也许你可以让ping运行几个小时到你检测到的每一跳。 将输出redirect到日志文件。 然后用grep，awk等提取ping时间并绘制（Excel，OO Calc等）。 你应该可以看到延迟开始的时间。
你有什么样的互联网连接？ 当你处理高延迟时，上传饱和度经常是可疑的。 configuration您的路由器（或新路由器）以最大连接速度的85％-90％进行传输，并在其上设置一个公平的队列以避免ssh数据包在队列末尾结束。