![ComCast를 통해 TigerVNC 몇 분 동안 일시 중지되는 근본 원인 찾기, "* * *" 이유](https://linux55.com/image/197379/ComCast%EB%A5%BC%20%ED%86%B5%ED%95%B4%20TigerVNC%20%EB%AA%87%20%EB%B6%84%20%EB%8F%99%EC%95%88%20%EC%9D%BC%EC%8B%9C%20%EC%A4%91%EC%A7%80%EB%90%98%EB%8A%94%20%EA%B7%BC%EB%B3%B8%20%EC%9B%90%EC%9D%B8%20%EC%B0%BE%EA%B8%B0%2C%20%22*%20*%20*%22%20%EC%9D%B4%EC%9C%A0.png)
TigerVNC 세션에서 간헐적이고 때로는 긴 지연의 근본 원인을 추적하는 데 사용할 수 있는 기술은 무엇입니까?
TigerVNC를 사용하여 SSH를 통해 원격으로 작업하세요. 화면은 대부분 반응합니다. 그러나 매일 여러 번 응답 지연이 발생하며 이는 0.5초에서 최대 몇 초까지 발생할 수 있습니다.분, 입력된 문자와 마우스 움직임 및 작업은 버퍼링된 상태로 유지됩니다. 코드를 작성하는 도중에 이런 일이 발생하면 매우 해로울 수 있습니다.
이러한 지연 동안에는 핑(지금까지)에 문제가 없으며 다른 인터넷 액세스도 잘 작동합니다.
우리는 ComCast에 대해 상대적으로 높은 성능 계획을 가지고 있습니다. 내 노트북은 스위치를 통해 라우터/케이블 모뎀으로 연결되어 있으므로 WiFi는 문제가 되지 않습니다. 제가 일하는 회사는 다른 ISP를 사용하고 있습니다. IT 부서에서는 ComCast를 사용하는 다른 사용자들도 비슷한 문제를 겪고 있다고 밝혔지만 현재 제가 살고 있는 지역에는 다른 ISP 옵션이 없습니다.
Traceroute(약간 편집됨)...정지시키다점프 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 패킷을 다시 보내야 합니다. 또한 패킷을 삭제해야 합니다.
traceroute
TTL이 1인 3개의 패킷을 보내고 ICMP 패킷을 수신하는 방식으로 작동합니다. 소요 시간과 보고서 출처를 보고합니다. 그런 다음 TTK 2로 3개의 패킷을 보내고 호스트와 시간을 보고합니다. TTL은 3이고 TTL은 4입니다. 그러나 프로그램은 무한정 기다리지 않습니다. ICMP 응답을 받지 못하면 하나를 인쇄합니다 *
.
따라서 TTL이 9인 경우 ICMP 응답이 수신되지 않습니다. 이는 라우터가 응답을 보내지 않도록 구성되었거나 패킷을 차단하는 방화벽 규칙이 있기 때문일 수 있습니다. 느림은 단지 응답을 기다리고 있을 뿐입니다.
TTL 값이 16~64이면 방화벽 때문이라고 생각합니다.
이 모든 것은완전히 정상. 문제가 있다는 증거는 제시되지 않았습니다.
ping 데이터를 제공하지 않기 때문에 네트워크에 정체가 있는지 여부를 알 수 없습니다.
당신은 찾을 수 있습니다mtr
https://github.com/traviscross/mtr더 나은 통찰력을 제공하십시오.