☰

透過 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 回應。這可能是因為路由器配置為不發送回應，或者可能有防火牆規則阻止封包。緩慢只是等待響應。

對於 16 到 64 的 TTL 值，我會怪罪防火牆。

這一切都是完全正常。它沒有提供任何證據表明存在問題。

由於您不提供 ping 數據，我們無法判斷網路是否有擁塞。

你可能會發現mtr https://github.com/traviscross/mtr給你一些更好的見解。

相關內容