WFH 느린 응답 시간 디버깅
VPN은 터널링 프로토콜이기 때문에 이 작업을 수행해야 합니다. VPN은 의사 지점 간 연결 역할을 합니다. 80년대 중반에 메인프레임이 했던 것처럼 엔드포인트에 대한 직접 연결을 에뮬레이트합니다.
다음 단계
엔드포인트 위치의 진입점에 대한 추적 프로그램을 실행합니다. 이것은 라우터에서 라우터로의 응답 시간을 알려주는 것입니다.
추적
1 3 ms 3 ms 4 ms 192.168.1.1
2 * * * Request timed out.
3 13 ms 22 ms 20 ms 096-034-028-228.lmg.special.com [96.34.28.228]
4 11 ms 10 ms 11 ms crr01abqnm-bue-3.albuquerque.nm.chatter.com [96.34.25.12]
5 18 ms 17 ms 17 ms crr01stcdmn-bue-6.stcd.mn.chatter.com [96.34.25.0]
6 22 ms 24 ms 20 ms bbr02slidla-tge-0-1-0-6.slid.la.chatter.com [96.34.1.188]
7 27 ms 28 ms 22 ms bbr01euclwi-tge-0-0-0-8.eucl.wi.chatter.com [96.34.0.114]
8 48 ms 73 ms 44 ms bbr02dnvrco-bue-3.dnvr.co.chatter.com [96.34.1.82]
9 39 ms 40 ms 39 ms bbr01oxfrma-tge-0-1-0-6.oxfr.ma.chatter.com [96.34.0.204]
10 74 ms 79 ms 78 ms bbr02snjsca-bue-2.snjs.ca.chatter.com [96.34.0.2]
11 74 ms 80 ms 66 ms prr01snjsca-bue-6.snjs.ca.chatter.com [96.34.3.3]
12 * 120 ms 117 ms 99.82.176.224
13 67 ms 77 ms 71 ms 52.93.47.129
14 65 ms 73 ms 64 ms 54.240.242.17
15 * * * Request timed out.
16 117 ms 100 ms 96 ms 52.93.131.226
17 103 ms 95 ms 140 ms 54.239.46.104
18 * * * Request timed out.
19 89 ms 180 ms 91 ms 52.93.13.42
20 93 ms 89 ms 90 ms 52.93.13.35
21 91 ms 89 ms 87 ms 52.93.12.182
22 99 ms 135 ms 101 ms 52.93.12.207
23 98 ms 87 ms 89 ms 52.93.15.211
24 87 ms 86 ms 87 ms 205.251.233.67
25 * * * Request timed out.
26 * * * Request timed out.
27 * * * Request timed out.
28 * * * Request timed out.
29 * * * Request timed out.
30 * * * Request timed out.1 3 ms 3 ms 4 ms 192.168.1.1
2 * * * Request timed out.
3 13 ms 22 ms 20 ms 096-034-028-228.lmg.special.com [96.34.28.228]
4 11 ms 10 ms 11 ms crr01abqnm-bue-3.albuquerque.nm.chatter.com [96.34.25.12]
5 18 ms 17 ms 17 ms crr01stcdmn-bue-6.stcd.mn.chatter.com [96.34.25.0]
6 22 ms 24 ms 20 ms bbr02slidla-tge-0-1-0-6.slid.la.chatter.com [96.34.1.188]
7 27 ms 28 ms 22 ms bbr01euclwi-tge-0-0-0-8.eucl.wi.chatter.com [96.34.0.114]
8 48 ms 73 ms 44 ms bbr02dnvrco-bue-3.dnvr.co.chatter.com [96.34.1.82]
9 39 ms 40 ms 39 ms bbr01oxfrma-tge-0-1-0-6.oxfr.ma.chatter.com [96.34.0.204]
10 74 ms 79 ms 78 ms bbr02snjsca-bue-2.snjs.ca.chatter.com [96.34.0.2]
11 74 ms 80 ms 66 ms prr01snjsca-bue-6.snjs.ca.chatter.com [96.34.3.3]
12 * 120 ms 117 ms 99.82.176.224
13 67 ms 77 ms 71 ms 52.93.47.129
14 65 ms 73 ms 64 ms 54.240.242.17
15 * * * Request timed out.
16 117 ms 100 ms 96 ms 52.93.131.226
17 103 ms 95 ms 140 ms 54.239.46.104
18 * * * Request timed out.
19 89 ms 180 ms 91 ms 52.93.13.42
20 93 ms 89 ms 90 ms 52.93.13.35
21 91 ms 89 ms 87 ms 52.93.12.182
22 99 ms 135 ms 101 ms 52.93.12.207
23 98 ms 87 ms 89 ms 52.93.15.211
24 87 ms 86 ms 87 ms 205.251.233.67
25 * * * Request timed out.
26 * * * Request timed out.
27 * * * Request timed out.
28 * * * Request timed out.
29 * * * Request timed out.
30 * * * Request timed out.
분석
먼저 홉 수는 대기 시간에 큰 영향을 미치며 위에 표시된 각 홉은 라우터입니다. 홉이 많을수록 속도가 느려집니다.
30 홉은 좋지 않지만 우리는 그것을 제어할 수 없습니다.
TraceRt는 1에서 시작하여 대상이 표시될 때까지 증가하는 홉 카운트와 함께 Ping을 사용하여 작동합니다. 느린 응답을 쉽게 발견할 수 있습니다.
요청 시간이 초과되었습니다
이러한 메시지는 그렇지 않은 경우를 제외하고는 가양성입니다. 많은 라우터가 이 문제를 일으키는 Ping을 허용하지 않습니다.
그러나 이 증상은 라우터가 혼잡할 때 정확히 나타납니다. 그 이유는 라우터가 열을 처리할 수 없을 때 원하는 패킷을 버릴 수 있기 때문입니다. 그들은 많은 패킷을 버리고 다시 느려지기 시작할 때까지 자가 치유되는 "호흡"으로 알려진 행동을 보이기 시작합니다. 이것은 트래픽이 감소할 때까지 무한 반복됩니다. TraceRt에서 이를 확인하려면 타임아웃이 다시 발생하는지 확인하기 위해 여러 번 실행해야 합니다.
응답 시간
60-70밀리초 이상은 잠재적인 문제입니다. 100ms 범위의 모든 것은 노란색 플래그이고 150+ 영역의 모든 것은 좋지 않습니다. 우리는 200ms 이상을 우리의 타이핑, 마우스 클릭, 심지어 원격 터미널을 사용할 때 복사 및 붙여넣기에 반응하지 않는 미친 감각으로 감지할 수 있습니다.
3단계 네트워크 제공자에게 전화하기
위에 표시된 것과 같은 흔적이 보이면 공급자에게 연락하여 막대에서 제거해야 할 것입니다. 자, 이제 해결하세요. 제발, 이쁘게 해주세요.... 난 여기서 죽어가고 있어요 Mr.Network 친구.
그러나 골대를 뛰어 넘어야 할 준비가 되었습니다. 그들은 모두 당신이 그들보다 훨씬 덜 똑똑하다고 생각한다는 것을 알 수 있습니다! 그들의 첫 번째 성향은 무선인 경우 무선에서와 같이 마지막 홉 연결 지점이라는 것입니다. 지금은 게임을 하고 아무 것도 변하지 않았을 때 서비스가 좋다는 말은 하지 마십시오. 사실 그들이 그 기술자가 그에게 제공한 서비스를 평가하기 위해 다시 전화할 때 정직하고 그들에게 F를 줍니다. (서비스 기술자가 개인적으로가 아니라 서비스만).
그것이 해결될 때까지 나쁜 평가를 계속 반복하십시오. 당신은 또한 그들의 페이스 북 페이지에 가서 몇 가지 나쁜 서비스 경고 샷을 발사할 수 있습니다. 그렇게 일요일 아침에 전화를 받습니다.
업데이트:
2일 후
After two days of trying, Charter finally contacted me back. The tech person was good. However, he wanted to focus on my local wireless. I'm skeptical but went along for the ride. He sold me a service visit to install a new wireless router at extra $5.00 per month and one time $9.99 activation fee. I still think this is a congested network issue out in CharterLand.
3일 후
Three days later, a very good tech came to house. He took one measurement at cable modem. Claimed service was a perfect 200mb down and 160mb up. He asked where the entry to the cable was went downstairs and came back up. He was just like the phone representative "it's your wireless". Ok thanks dude, it should be here early next week. Bye.
4일 후
Got a early morning wake up call from Charter 8:00 am Sunday, spoke with the nice tech rep for a long time. I was able to convince him not to attempt to send another person out based on current history. He thought that was a good idea and for the first time agreed to send a letter over to their NOC folks (I think it was Network Operations Center) not sure. He phoned me back later the NOC folks had moved the issue to another OC center, I didn't catch the name. But that these dudes were the ones who could look into router logs and do stuff, real stuff.
5일 후
Was on RDP network with VPN all day and could not detect any slowness issues all day long! It's as if I'm typing on the Remote Terminal locally!
7일 후
New wireless mode arrived, plugged it in and connected to the 5G leg. Result was that all my issues went away.
고백
분명히 내 무선이었습니다. 네트워크 학교로 돌아가야 할 것 같습니다.
잠깐만 두 트레이스에서 두 번째 홉이 시간 초과되지 않았습니까? 홉 1은 무선이었고 홉 2는 케이블 모뎀이었습니다. 흠...
JWP2020
Reference
이 문제에 관하여(WFH 느린 응답 시간 디버깅), 우리는 이곳에서 더 많은 자료를 발견하고 링크를 클릭하여 보았다 https://dev.to/jwp/remote-terminal-bullshit-4134텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
우수한 개발자 콘텐츠 발견에 전념 (Collection and Share based on the CC Protocol.)