☰

通过 ComCast 查找 TigerVNC 多分钟暂停的根本原因；为什么 ”* * *”

tag-icon • tag-icon ssh networking internet troubleshooting tigervnc
通过 ComCast 查找 TigerVNC 多分钟暂停的根本原因；为什么 ”* * *”

有哪些技术可用于追踪 TigerVNC 会话中间歇性、有时甚至很长的延迟的根本原因？

使用 TigerVNC 通过 SSH 远程工作。大多数时候屏幕都是有响应的。然而，每天很多时候，都会出现响应延迟的情况；这些范围可以从半秒到长达几秒分钟，输入的字符和鼠标移动和操作保持缓冲。当它发生在编写一行代码的过程中时，这是非常具有破坏性的。

在这些延迟期间，ping（到目前为止）没有任何问题，并且其他互联网访问工作正常。

我们在 ComCast 上有一个相对较高的性能计划。 WiFi 不是问题，因为我的笔记本电脑通过交换机硬连线到我们的路由器/电缆调制解调器。我工作的公司位于不同的 ISP 上。 IT 部门表示，其他使用 ComCast 的用户也遇到了类似的问题，但我居住的地方目前没有其他 ISP 选项。

跟踪路由（稍作编辑）...停顿在第 9 跳，并显示* * *该跳。

scott@scott-HP-Pavilion-15-dk0xxx:~$ traceroute <redacted>.com
traceroute to <redacted> (<redacted>), 64 hops max
  1   192.168.0.1  0.660ms  1.224ms  0.691ms 
  2   <redacted>  12.768ms  13.083ms  9.222ms 
  3   24.153.80.113  12.028ms  9.766ms  10.039ms 
  4   69.139.164.217  11.650ms  17.848ms  10.298ms 
  5   24.124.128.249  14.816ms  10.285ms  10.711ms 
  6   68.86.93.165  11.076ms  15.245ms  11.115ms 
  7   96.110.40.89  11.764ms  12.553ms  10.458ms 
  8   96.110.32.234  10.686ms  9.901ms  10.849ms 
  9   *  *  *    <---  this part runs slowly.
 10   64.125.23.46  11.342ms  9.551ms  8.964ms 
 11   64.125.29.3  10.094ms  11.916ms  11.782ms 
 12   64.125.36.106  11.953ms  9.912ms  9.900ms 
 13   <redacted>  14.820ms  9.314ms  10.101ms 
 14   <redacted>  12.224ms  9.792ms  10.748ms 
 15   <redacted>  10.585ms  11.545ms  12.545ms 
 16   *  *  * 
...
 64   *  *  *

到目前为止，给康卡斯特技术支持的电话已经产生了支持票号，这可能是本能地试图让我更换我们的（相当新的）电缆调制解调器，并且（迄今为止）没有回电。然而，问题不在于正常操作期间速度慢，而且我们的连接（据我所知）不会断开；在暂停期间，ping 和其他 Internet 访问会继续正常工作，不会出现任何延迟，并且按键和鼠标操作仍会被缓冲。

我将不胜感激任何想法：

  • 如何将问题隔离为软件问题、网络问题还是其他问题？
  • 帮助隔离的工具
  • 如果是后者，如何告诉我们的 ISP 出了什么问题，希望这能渗透到有权修复它的人身上
  • 如何克服这个问题（可能只是租用另一个 ISP 提供的办公室）

编辑： 根据建议使用sudo journalctl -b 0 -u NetworkManager：

日志显示许多三元组：

  • connectivity: (en01) timed out，紧接着是：
  • manager: NetworkManager state is now CONNECTED_SITE,
  • 然后每次延迟 4 分 31 秒（？）后：
  • manager: NetworkManager state is now CONNECTED_GLOBAL序列。

示例，修剪系统名称：

Oct 24 17:14:06 <name> NetworkManager[1065]: <info>  [1635120846.1948] connectivity: (eno1) timed out
Oct 24 17:14:06 <name> NetworkManager[1065]: <info>  [1635120846.1949] manager: NetworkManager state is now CONNECTED_SITE
Oct 24 17:18:37 <name> NetworkManager[1065]: <info>  [1635121117.3196] manager: NetworkManager state is now CONNECTED_GLOBAL

答案1

IP 数据包有一个生存时间字段，旨在防止数据包永远循环。

每次转发数据包时，每个路由器都需要减少 TTL 字段。

当 TTL 低于 1 时，路由器应发回 ICMP 数据包，表明 TTL 字段已过期。此外，它还必须丢弃数据包。

traceroute其工作原理是发送 3 个 TTL 为 1 的数据包，并侦听 ICMP 数据包。它报告所需的时间以及报告的来源。然后它发送 3 个带有 TTK 2 的数据包，并报告主机和时间。 TTL 为 3，然后 TTL 为 4，依此类推。然而，该程序不会无限期地等待。如果你没有收到 ICMP 响应，它会打印一个*.

因此，对于 TTL 为 9 的情况，不会收到 ICMP 响应。这可能是因为路由器配置为不发送响应，或者可能有防火墙规则阻止数据包。缓慢只是等待响应。

对于 TTL 值 16 到 64，我会将其归咎于防火墙。

这一切都是完全正常。它没有提供任何证据表明存在问题。

由于您不提供 ping 数据，我们无法判断网络是否存在拥塞。

你可能会发现mtr https://github.com/traviscross/mtr给你一些更好的见解。

相关内容