이 글의 내용은 핑에서 명백한 패킷 손실이 감지되었을 때 링크 테스트를 수행하는 방법에 대한 것입니다. 필요한 친구들이 참고할 수 있기를 바랍니다.
Windows 인스턴스 네트워크 액세스 패킷 손실 지연이 높습니다
웹 사이트 액세스가 매우 느리거나 액세스할 수 없는 경우, 다른 명백한 문제가 제거되고 ping에서 명백한 패킷 손실이 감지되면 링크 테스트를 수행하는 것이 좋습니다. Windows 환경에서는 WinMTR 도구(권장) 또는 TRACERT 명령줄 도구를 사용하여 링크 테스트를 수행하여 문제의 원인을 확인할 수 있습니다.
일반적으로 다음 단계를 따르십시오.
링크 테스트 도구를 사용하여 네트워크 상태 및 서버 상태를 감지합니다.
링크 테스트 결과를 기반으로 분석 및 처리합니다.
WinMTR 도구(선호)
mtr(My Traceroute)는 네트워크 테스트 도구로서 Tracert 및 ping 두 명령의 그래픽 인터페이스를 통합합니다. Ping 및 Tracert는 일반적으로 네트워크 상태 및 서버 상태를 감지하는 데 사용됩니다. 구체적인 설명은 다음과 같습니다.
WinMTR은 Windows 환경에서 경로 추적 및 핑 테스트에 적합합니다. 윈도우. WinMTR은 기본적으로 감지를 위해 ICMP 패킷을 보내며 전환할 수 없습니다.
TRACERT 명령줄 도구와 비교하여 WinMTR은 노드 변동이 테스트 결과에 미치는 영향을 피할 수 있으며 테스트 결과가 더 정확합니다. Windows 환경에서는 먼저 링크 테스트를 위해 WinMTR을 사용하는 것이 좋습니다. (다운로드 및 다운로드는 공식 홈페이지를 클릭하세요.)
작업 단계
공식 홈페이지에서 WinMTR을 다운로드한 후 압축을 풀고 직접 실행하세요. 프로그램을 실행한 후 호스트 필드에 대상 서버 도메인 이름 또는 IP를 선행 공백 없이 입력합니다.
테스트를 시작하려면 시작을 클릭하세요. (테스트가 시작되면 해당 버튼이 중지로 변경됩니다.)
일정 실행 후 중지를 클릭하면 테스트가 중지됩니다.
지침: 몇 분 더 테스트하고 테스트가 완료된 후 결과를 내보낼 수 있습니다.
텍스트를 클립보드에 복사: 테스트 결과를 텍스트 형식으로 클립보드에 복사합니다.
HTML을 클립보드에 복사: 테스트 결과를 HTML 형식으로 클립보드에 복사합니다.
텍스트 내보내기: 테스트 결과를 지정된 파일로 텍스트 형식으로 내보냅니다.
HTML 내보내기: 테스트 결과를 HTML 형식의 지정된 파일로 내보냅니다.
옵션: 선택적 매개변수입니다. 구체적인 세부 정보는 다음과 같습니다.
간격(초): 각 감지의 간격(만료) 시간, 기본값은 1초입니다.
핑 크기(바이트): 핑 감지에 사용되는 패킷 크기, 기본값은 64바이트입니다.
LRU 목록의 최대 호스트: LRU 목록에서 지원하는 최대 호스트 수, 기본값은 128입니다.
이름 확인: 역방향 IP 쿼리를 통해 도메인 이름별로 관련 노드를 표시합니다.
WinMTR 실행 후 반환 결과를 확인하세요.
설명: 기본 구성에서 WinMTR 테스트 결과는 다음과 같이 설명됩니다.
첫 번째 열(호스트 이름): 대상 서버에 도달하기 위해 통과해야 하는 각 노드 호스트의 IP 또는 도메인 이름입니다.
두 번째 열(Nr): 노드 번호.
세 번째 열(손실%): 노드 패킷 손실률입니다. 핑 패킷 응답 실패율을 보면 서버가 위치한 전산실인지, 국제 라우팅 간선 도로인지 어느 노드(회선)에 결함이 있는지 판단할 수 있습니다.
네 번째 열(전송): 전송된 패킷 수입니다.
다섯 번째 열(Recv): 성공적으로 수신된 패킷 수입니다.
6번째, 7번째, 8번째, 9번째 열(Best, Avg, Worst, Last): 각각 응답 시간의 최소값, 평균, 최대값 및 마지막 패킷의 응답 시간입니다.
TRACERT 명령줄 도구
TRACERT(경로 추적)는 Windows와 함께 제공되는 네트워크 진단 명령줄 유틸리티로, IP(인터넷 프로토콜) 패킷이 대상 주소로 전달되는 경로를 추적하는 데 사용됩니다.
TRACERT는 ICMP 패킷을 대상 주소로 보내 대상 주소에 대한 경로를 결정합니다. 이러한 패킷에서 TRACERT는 다양한 IP TTL(Time to Live) 값을 사용합니다. 도중에 있는 라우터는 패킷을 전달하기 전에 TTL을 1 이상 줄여야 하므로 TTL은 실제로 홉 카운터와 동일합니다. 패킷의 TTL이 0에 도달하면 노드는 ICMP 시간 초과 메시지를 원본 컴퓨터로 보냅니다.
TRACERT는 처음으로 TTL이 1인 패킷을 전송하고 대상 주소가 응답하거나 TTL의 최대값에 도달할 때까지 후속 전송마다 TTL을 1씩 늘립니다. 중간 라우터가 다시 보내는 ICMP Timeout 메시지에는 해당 노드의 정보가 포함되어 있습니다.
단계
바탕화면 하단의 시작 메뉴를 클릭하고 실행을 선택하세요.
실행 상자를 연 후 상자에 cmd를 입력하고 확인을 클릭하세요.
명령 실행 인터페이스에서 Tracert를 입력하고 Enter를 누르면 인터페이스에 Tracert 사용 지침이 표시됩니다.
특정 용도에 따라 추적할 대상 주소를 입력하세요.
예
C:\> tracert -d 223.5.5.5 通过最多 30 个跃点跟踪到 223.5.5.5 的路由 1 * * * 请求超时。 2 9 ms 3 ms 12 ms 192.168.17.20 3 4 ms 9 ms 2 ms 111.1.20.41 4 9 ms 2 ms 1 ms 111.1.34.197 5 11 ms * * 211.140.0.57 6 3 ms 2 ms 2 ms 211.138.114.62 7 2 ms 2 ms 1 ms 42.120.244.190 8 32 ms 4 ms 3 ms 42.120.244.238 9 * * * 请求超时。 10 3 ms 2 ms 2 ms 223.5.5.5
링크 테스트 결과 분석
정교는 다음 링크 테스트 결과 예시 다이어그램을 기반으로 합니다.
작업 단계
각 영역에서 여부를 판단하세요. 예외가 있으며, 각 지역의 사정에 따라 별도로 처리합니다.
A 영역: 클라이언트 로컬 네트워크, 즉 로컬 LAN 및 로컬 네트워크 공급자 네트워크. 이 영역의 이상 및 클라이언트의 로컬 네트워크와 관련된 노드 문제의 경우 로컬 네트워크 문제를 해결하고 분석하고 로컬 네트워크 공급자의 네트워크와 관련된 노드 문제는 로컬 운영자에게 피드백을 제공하십시오.
B구역: 통신사 백본 네트워크. 이 영역에 이상이 있는 경우 비정상적인 노드 IP를 기반으로 운영자에게 문의한 후 해당 운영자에게 직접 문제를 보고하거나 Alibaba Cloud 애프터 기술 지원을 통해 문제를 보고할 수 있습니다.
C 영역: 대상 서버의 로컬 네트워크, 즉 대상 호스트가 속한 네트워크 공급자 네트워크입니다. 이 부분에 이상이 있을 경우 대상 호스트가 속한 네트워크 제공업체에 문제를 보고해야 합니다.
Avg(평균)와 StDev(표준편차)를 결합하여 각 노드에 이상이 있는지 확인합니다.
StDev가 매우 높으면 해당 노드의 Best와 Wrst를 동시에 관찰하여 해당 노드에 이상이 있는지 확인합니다.
StDev가 높지 않은 경우 Avg를 사용하여 해당 노드에 이상이 있는지 확인합니다.
참고: 위의 StDev가 높은지 여부에 대한 특정 시간 범위 표준은 없습니다. 동일한 노드의 다른 열의 지연 값을 기반으로 상대적인 평가가 이루어져야 합니다. 예를 들어 Avg가 30ms인 경우 StDev가 25ms이면 이는 높은 편차로 간주됩니다. 그리고 Avg가 325ms인 경우 동일한 StDev(25ms)는 낮은 편차로 간주됩니다.
노드 패킷 손실률을 확인하세요. Loss%가 0이 아니면 이 홉 네트워크에 문제가 있을 수 있다는 의미입니다.
노드 패킷 손실에는 일반적으로 두 가지 이유가 있습니다.
노드의 ICMP 전송 속도를 인위적으로 제한하여 패킷 손실이 발생합니다.
실제로 노드에 이상이 있어 패킷 손실이 발생했습니다.
현재 비정상 노드의 패킷 손실 원인을 파악합니다.
다음 노드에서 패킷 손실이 발생하지 않으면 현재 노드의 패킷 손실은 운영자 정책 제한으로 인한 것이므로 무시할 수 있음을 의미합니다. 이전 링크 테스트 결과 예시 다이어그램의 2nd 홉과 같습니다.
다음 노드에서도 패킷 손실이 발생하면 현재 노드에 네트워크 이상이 있어 패킷 손실이 발생한다는 의미입니다. 위의 링크 테스트 결과 예시도와 같이 홉 5가 표시되어 있습니다.
참고: 위 두 가지 상황이 동시에 발생할 수 있습니다. 즉, 해당 노드에 정책 속도 제한과 네트워크 이상이 모두 있을 수 있습니다. 이러한 상황에서 현재 노드와 후속 노드에서 지속적으로 패킷 손실이 발생하고 각 노드의 패킷 손실률이 다른 경우 일반적으로 마지막 몇 홉의 패킷 손실률이 우세합니다. 위의 링크 테스트 결과 예시 그림에서 볼 수 있듯이 5번째, 6번째, 7번째 홉에서 패킷 손실이 발생했습니다. 따라서 최종 패킷 손실 상황은 7번째 홉의 40%를 기준으로 한다.
명백한 지연이 있는지 확인하여 노드에 이상이 있는지 확인하세요. 분석은 다음 두 가지 측면에서 진행됩니다.
특정 홉 이후 지연이 크게 증가하면 일반적으로 해당 노드에 네트워크 이상이 있다고 판단합니다. 위의 링크 테스트 결과 예시 그림에서 볼 수 있듯이 5번째 홉 이후 후속 노드들의 지연이 크게 증가하여 5번째 홉 노드에서 네트워크 이상이 발생한 것으로 유추된다.
참고: 지연 시간이 높다고 해서 반드시 해당 노드에 이상이 있는 것은 아닙니다. 데이터 반환 링크로 인해 지연 시간이 길어질 수도 있으므로 역방향 링크 테스트와 함께 분석하는 것이 좋습니다.
ICMP 정책 속도 제한으로 인해 해당 노드의 지연 시간이 급격히 증가할 수도 있지만 일반적으로 후속 노드는 정상으로 돌아옵니다. 위의 링크 테스트 결과 예시에서 볼 수 있듯이 세 번째 홉의 패킷 손실률은 100%이며, 지연도 크게 증가합니다. 그러나 노드 지연은 즉시 정상으로 돌아왔습니다. 따라서 노드의 지연 및 패킷 손실이 급격하게 증가하는 것은 정책적 속도 제한에 따른 것으로 판단된다.
기타 제안
중국 본토 및 기타 국가 또는 지역의 알리바바 클라우드 컴퓨터실에는 네트워크 통신을 위한 전용 회선이 있습니다. 통신 중 패킷 손실률을 줄이기 위해 고속 채널을 사용하는 것이 좋습니다.
호스트 패킷 드롭 및 지연이 매우 높은 경우 WinMTR 양방향 테스트, 즉 로컬에서 서버로, 서버에서 로컬로 테스트를 수행하는 것이 좋습니다. 원격으로 로그인이 되지 않을 경우 관리단말기를 통해 로그인 하시기 바랍니다.
위 내용은 핑에서 명백한 패킷 손실이 감지된 경우 링크 테스트를 수행하는 방법의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!