我们大部分工作都是通过 SSH 在数据中心的共置服务器上完成的。这意味着我们几乎每周 5 天、每天全天都连接到这些服务器。间歇性地，我们会发现在键盘上打字和在 shell 上回显内容之间存在延迟。我开始进行一些挖掘，但无法理解结果；我也在寻找下一步要研究的方法。之前，我对 运行了 wireshark 跟踪tcp.dstport == 22，这似乎是我们遇到大多数问题的地方。我确实注意到大量的（几千个数据包中的 10-20 个）是 TCP 重传。我认为这与我们看到的延迟问题有关。
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
第一个问题：为什么上面的 mtr 显示 192.168.100.254 处有数据包丢失，而下面的 mtr 没有？
第二个问题：我如何才能更好地确定导致这种情况的原因？
编辑：
mtr 到我们网络之外的第一个主机：
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
根据这些新数据，您有什么建议吗？我打算更换路由器/防火墙。
答案1
直接答案
第一个问题：为什么顶部的 mtr 提示 192.168.100.254 有数据包丢失，而底部的 mtr 没有提示？
mtr 发送 ping（ICMP 回显响应），并增加 IP TTL，直到收到响应。192.168.100.254 在响应 TTL 到期条件（低成功率）与 ICMP 回显响应（高成功率）时的响应不同
第二个问题：我如何才能更好地确定导致这种情况的原因？
当您说“导致这种情况”时，我假设您指的是滞后的 ssh 会话，而不是奇怪的 mtr 结果……对吗？一些想法……
直接运行mtr11 跳路径上的每台主机，看看能否从其中一跳开始找到一些有趣的症状；根据你的第一个mtr，这可能不会更有成效，但值得一试。另外，与 192.168.100.254 的管理员交谈，看看你们是否能找出 ICMP TTL 过期回复被拦截的原因。
杂项想法
网络问题通常有三个原因：数据包丢失、数据包延迟（排队）或数据包重新排序。不过，我们也要记住，有时主机级问题也会导致您的问题1。
暂时假设
192.168.100.x您的问题不存在于 vlan 中，并且您的拓扑如下所示：HOST_A----------------------HOST_B 192.168.100.x 216.26.162.162
如果您尚未从 Windows 计算机 ssh 到HOST_A，请执行2。现在录制您的 Windows 桌面3。当问题再次发生时，录制的视频可以很好地跟踪问题可能出在哪里（即在网络中、在主机上或两者兼而有之）。如果您能以某种方式在此视频中看到时间，那就更好了……这也ntp为您提供了一种回溯分析的方法。syslog
结束语
- 其中一个是否正在交换到磁盘、消耗大量 CPU（可能是由脚本/数据库查询导致的）或者间歇性繁忙？
- 至少有四个窗口，一个用于
HOST_A和之间的 sshHOST_B，另一个用于上的嗅探会话HOST_A，最后两个应该正在和上运行top或vmstat 5在。HOST_AHOST_B - 用你喜欢的就行，但我用的是卡姆工作室（目前我最喜欢的是测试版）；它是免费且开源的。
答案2
对于您的第二个问题：也许您可以让 ping 在您检测到的每个跳数上运行几个小时。将输出重定向到日志文件。然后使用 grep、awk 等提取 ping 时间并绘制图表（Excel、OO Calc 等）。您应该能够看到滞后从哪些跳数开始。
您使用的是哪种互联网连接？通常，当您处理高延迟时，上传饱和度是值得怀疑的。将您的路由器（或新路由器）配置为以最大连接速度的 85%-90% 进行传输，并在其上设置一个公平队列，以避免 ssh 数据包最终排在队列末尾。