☰

ComCast를 통해 TigerVNC 몇 분 동안 일시 중지되는 근본 원인 찾기 왜 "* * *"

tag-icon • tag-icon ssh networking internet troubleshooting tigervnc
ComCast를 통해 TigerVNC 몇 분 동안 일시 중지되는 근본 원인 찾기 왜 "* * *"

TigerVNC 세션에서 간헐적이고 때로는 매우 긴 지연의 근본 원인을 추적하는 몇 가지 기술은 무엇입니까?

TigerVNC를 사용하여 SSH를 통해 원격으로 작업합니다. 대부분의 경우 화면이 반응합니다. 그러나 하루에도 여러 번 응답이 지연되는 경우가 있습니다. 이는 0.5초에서 몇 초까지 다양할 수 있습니다.분, 입력된 문자와 마우스 이동 및 동작이 버퍼링된 상태로 유지됩니다. 이는 코드를 작성하는 도중에 발생하면 매우 파괴적입니다.

이러한 지연 동안 핑은 (지금까지) 아무런 문제 없이 진행되며 다른 인터넷 액세스도 정상적으로 작동합니다.

우리는 상대적으로 높은 성능 계획을 가지고 ComCast를 사용하고 있습니다. 내 노트북은 스위치를 통해 라우터/케이블 모뎀에 연결되어 있으므로 WiFi는 문제가 되지 않습니다. 제가 일하고 있는 회사는 다른 ISP를 사용하고 있습니다. IT는 ComCast를 사용하는 다른 사람들도 비슷한 문제를 겪었다고 밝혔습니다. 그러나 현재 제가 살고 있는 곳에서는 사용할 수 있는 다른 ISP 옵션이 없습니다.

추적 경로(약간 수정됨)...일시 중지Hop 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   *  *  *

Comcast 기술 지원팀에 전화하면 지금까지 지원 티켓 번호가 생성되었으며 아마도 반사적으로 (상당히 새로운) 케이블 모뎀을 변경하도록 유도했으며 (현재까지) 회신 전화가 없었습니다. 그러나 문제는 정상 작동 중 느린 속도가 아니며 연결이 (내가 아는 한) 끊어지지 않습니다. 핑 및 기타 인터넷 액세스는 일시 중지 중에도 지연 없이 계속 작동하며 키 입력 및 마우스 동작은 버퍼링된 상태로 유지됩니다.

다음에 대한 어떤 아이디어라도 감사하겠습니다:

  • 문제를 소프트웨어, 네트워킹 문제 또는 문제로 분리하는 방법은 무엇입니까?
  • 격리에 도움이 되는 도구
  • 후자의 경우 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(Time-To-Live) 필드가 있습니다.

모든 라우터는 패킷이 전달될 때마다 TTL 필드를 줄여야 합니다.

TTL이 1 미만이 되면 라우터는 TTL 필드가 만료되었음을 알리는 ICMP 패킷을 다시 보내야 합니다. 또한 패킷을 삭제해야 합니다.

tracerouteTTL 1로 3개의 패킷을 보내고 ICMP 패킷을 수신하는 방식으로 작동합니다. 필요한 시간과 보고서의 출처를 보고합니다. 그런 다음 TTK 2로 3개의 패킷을 전송하고 호스트와 시간을 보고합니다. TTL은 3이고 그 다음에는 TTL이 4입니다. 그러나 프로그램은 무한정 기다리지 않습니다. ICMP 응답을 받지 못하면 *.

따라서 TTL이 9인 경우 ICMP 응답이 수신되지 않습니다. 이는 라우터가 응답을 보내지 않도록 구성되었거나 패킷을 차단하는 방화벽 규칙이 있기 때문일 수 있습니다. 느린 반응은 단지 응답을 기다리고 있습니다.

TTL 값이 16~64이면 방화벽 때문이라고 생각합니다.

이 모든 것은완벽하게 정상. 문제가 있다는 어떠한 증거도 제공하지 않습니다.

핑 데이터를 제공하지 않기 때문에 네트워크에 정체가 있는지 알 수 없습니다.

당신은 찾을 수 있습니다mtr https://github.com/traviscross/mtr더 나은 통찰력을 제공합니다.

관련 정보