Linux 환경에서 mtr 명령줄 도구를 통해 링크 테스트를 수행하는 방법-리눅스 운영 및 유지 관리-php.cn

이 글에서는 Linux 환경에서 mtr 명령줄 도구를 통해 링크 테스트를 수행하는 방법을 소개하고 구체적인 단계에 중점을 두고 있습니다. 이 글에서 뭔가를 얻으실 수 있기를 바랍니다.

Linux 인스턴스 웹 사이트 액세스 패킷 손실 지연이 높습니다

웹 사이트 액세스가 매우 느리거나 액세스할 수 없는 경우, 다른 명백한 문제가 제거되고 ping에서 명백한 패킷 손실이 감지되면 링크 테스트를 수행하는 것이 좋습니다. Linux 환경에서는 mtr 명령줄 도구(권장) 또는 Traceroute 명령줄 도구를 사용하여 링크 테스트를 수행하여 문제의 원인을 확인할 수 있습니다.

일반적으로 다음 단계를 따르십시오.

링크 테스트 도구를 사용하여 네트워크 상태 및 서버 상태를 감지합니다.

링크 테스트 결과를 기반으로 분석 및 처리합니다.

mtr 명령줄 도구(선호)

mtr(My Traceroute)는 거의 모든 Linux 배포판에 사전 설치된 네트워크 테스트 도구로, Tracert 및 ping 명령의 그래픽 인터페이스를 통합하며 매우 강력합니다. .

ping 및 Tracert는 일반적으로 네트워크 상태 및 서버 상태를 감지하는 데 사용됩니다. 구체적인 지침은 다음과 같습니다.

Linux 환경에서 mtr 명령줄 도구를 통해 링크 테스트를 수행하는 방법

mtr은 기본적으로 링크 감지를 위해 ICMP 패킷을 보내고, 감지를 위해 UDP 패킷을 지정하기 위해 -u 매개변수를 사용합니다. . 링크 추적 테스트를 한 번만 수행하는 Traceroute와 비교하여 mtr은 링크에서 관련 노드를 지속적으로 감지하고 해당 통계 정보를 제공합니다. mtr은 노드 변동이 테스트 결과에 미치는 영향을 피할 수 있으므로 테스트 결과가 더 정확하므로 먼저 사용하는 것이 좋습니다.

사용 지침

mtr [-hvrctglspni46] [--help] [--version] [--report]
                [--report-cycles=COUNT] [--curses] [--gtk]
                [--raw] [--split] [--no-dns] [--address interface]
                [--psize=bytes/-s bytes]
                [--interval=SECONDS] HOSTNAME [PACKETSIZE]

로그인 후 복사

출력 예

[root@centos ~]# mtr 223.5.5.5
                                  My traceroute  [v0.75]
mycentos6.6 (0.0.0.0)                                             Wed Jun 15 23:16:27 2016
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
                                                  Packets               Pings
 Host                                           Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. ???
 2. 192.168.17.20                                0.0%     7   13.1   5.6   2.1  14.7   5.7
 3. 111.1.20.41                                  0.0%     7    3.0  99.2   2.7 632.1 235.4
 4. 111.1.34.197                                 0.0%     7    1.8   2.0   1.2   2.9   0.6
 5. 211.138.114.25                               0.0%     6    0.9   4.7   0.9  13.9   5.8
 6. 211.138.114.70                               0.0%     6    1.8  22.8   1.8  50.8  23.6
    211.138.128.134
    211.138.114.2
    211.138.114.66
 7. 42.120.244.186                               0.0%     6    1.4   1.6   1.3   1.8   0.2
    42.120.244.198
 8. 42.120.244.246                               0.0%     6    2.8   2.9   2.6   3.2   0.2
    42.120.244.242
 9. ???
10. 223.5.5.5                                    0.0%     6    2.7   2.7   2.5   3.2   0.3

로그인 후 복사

공통 선택적 매개변수 설명

-r 또는 --report: 보고서 모드에서 출력을 표시합니다.

-p 또는 --split: --report와 같이 전체 결과를 계산하는 대신 각 추적 결과를 개별적으로 나열합니다.

-s 또는 --psize: 핑 패킷의 크기를 지정합니다.

-n 또는 —no-dns: IP 주소에 대해 도메인 이름 역방향 확인을 수행하지 않습니다.

-a 또는 --address: 패킷 전송을 위한 IP 주소를 설정합니다. 호스트에 IP가 여러 개 있을 때 사용됩니다.

-4: IPv4 프로토콜만 사용하세요.

-6: IPv6 프로토콜만 사용하세요.

mtr이 실행되는 동안 해당 문자를 입력하여 모드를 빠르게 전환할 수도 있습니다.

또는 h: 도움말 메뉴를 표시합니다.

d: 디스플레이 모드를 전환합니다.

n: DNS 도메인 이름 확인 활성화 또는 비활성화를 전환합니다.

u: 검색에 ICMP 또는 UDP 패킷 사용 간에 전환합니다.

반환 결과 설명

기본 구성에서 반환된 결과의 각 데이터 열에 대한 설명은 다음과 같습니다.

첫 번째 열(호스트): 노드 IP 주소 및 도메인 이름. 앞에서 설명한 것처럼 n 키를 누르면 표시가 전환됩니다.

두 번째 열(손실%): 노드 패킷 손실률입니다.

세 번째 열(Snt): 초당 전송된 패킷 수입니다. 기본값은 10이며 -c 매개변수로 지정할 수 있습니다.

네 번째 열(마지막): 최신 감지 지연 값입니다.

다섯 번째, 여섯 번째, 일곱 번째 열(Avg, Best, Wrst): 각각 감지 지연의 평균, 최소, 최대값입니다.

8번째 열(StDev): 표준편차. 크기가 클수록 해당 노드가 불안정해집니다.

traceroute 명령줄 도구

traceroute는 거의 모든 Linux 배포판에 사전 설치되어 제공되는 네트워크 테스트 도구로, IP(인터넷 프로토콜) 패킷이 대상 주소로 전달되는 경로를 추적하는 데 사용됩니다.

traceroute는 먼저 작은 최대 수명 값(Max_TTL)을 사용하여 UDP 프로브 패킷을 보낸 다음 게이트웨이에서 시작하는 전체 링크에서 ICMP TIME_EXCEEDED 응답을 수신합니다. 검색은 TTL=1로 시작하고 ICMP PORT_UNREACHABLE 메시지가 수신될 때까지 TTL 값을 늘립니다. ICMP PORT_UNREACHABLE 메시지는 대상 호스트를 찾았는지 또는 명령이 추적에 허용되는 최대 TTL 값에 도달했는지 식별하는 데 사용됩니다.

traceroute는 링크 감지를 위해 기본적으로 UDP 패킷을 보냅니다. -I 매개변수를 사용하여 검색을 위해 ICMP 패킷을 보낼 수 있습니다.

사용 지침

traceroute [-I] [ -m Max_ttl ] [ -n ] [ -p Port ] [ -q Nqueries ] [ -r ] 
[ -s SRC_Addr ] [  -t TypeOfService ] [ -f flow ] [ -v ] [  -w WaitTime ] Host [ PacketSize ]

로그인 후 복사

샘플 출력

[root@centos ~]# traceroute -I 223.5.5.5
traceroute to 223.5.5.5 (223.5.5.5), 30 hops max, 60 byte packets
 1  * * *
 2  192.168.17.20 (192.168.17.20)  3.965 ms  4.252 ms  4.531 ms
 3  111.1.20.41 (111.1.20.41)  6.109 ms  6.574 ms  6.996 ms
 4  111.1.34.197 (111.1.34.197)  2.407 ms  2.451 ms  2.533 ms
 5  211.138.114.25 (211.138.114.25)  1.321 ms  1.285 ms  1.304 ms
 6  211.138.114.70 (211.138.114.70)  2.417 ms 211.138.114.66 (211.138.114.66)  
 1.857 ms 211.138.114.70 (211.138.114.70)  2.002 ms
 7  42.120.244.194 (42.120.244.194)  2.570 ms  2.536 ms 42.120.244.186 (42.120.244.186)  1.585 ms
 8  42.120.244.246 (42.120.244.246)  2.706 ms  2.666 ms  2.437 ms
 9  * * *
10  public1.alidns.com (223.5.5.5)  2.817 ms  2.676 ms  2.401 ms

로그인 후 복사

공통 선택적 매개변수에 대한 지침

-d 소켓 수준 디버깅 기능을 사용합니다.

-f는 처음 감지된 패킷의 생존 값 TTL 크기를 설정합니다.

-F 분할 플래그를 설정하지 않습니다.

-g 소스 라우팅 게이트웨이를 설정합니다. 최대 8개까지 설정할 수 있습니다.

-i 지정된 네트워크 카드를 사용하여 데이터 패킷을 보냅니다. 호스트에 여러 개의 네트워크 카드가 있을 때 사용됩니다.

-I 프로브에는 UDP 패킷 대신 ICMP 패킷을 사용합니다.

-m은 감지 패킷의 최대 TTL 크기를 설정합니다.

-n 호스트 이름 대신 IP 주소를 직접 사용합니다(DNS 역방향 조회 비활성화).

-p UDP 전송 프로토콜의 통신 포트를 설정합니다.

-r은 일반 라우팅 테이블을 무시하고 데이터 패킷을 원격 호스트로 직접 보냅니다.

-s 패킷을 보낼 로컬 호스트의 IP 주소를 설정합니다.

-t 탐지 패킷의 TOS 값을 설정합니다.

-v는 명령의 실행 과정을 자세히 표시합니다.

-w는 원격 호스트로부터 패킷 응답을 기다리는 시간을 설정합니다.

-x 데이터 패킷의 정확성 검사를 켜거나 끕니다.

링크 테스트 결과 분석

다음 링크 테스트 결과 예시 다이어그램을 바탕으로

Linux 환경에서 mtr 명령줄 도구를 통해 링크 테스트를 수행하는 방법

작업 단계

각 영역에 이상 유무를 판단하고, 상황에 따라 별도로 처리합니다. 각 지역 .

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%이며, 지연도 크게 증가합니다. 그러나 노드 지연은 즉시 정상으로 돌아왔습니다. 따라서 이 노드의 지연 및 패킷 손실이 급격하게 증가한 것은 정책적 속도 제한에 따른 것으로 판단된다.

위 내용은 Linux 환경에서 mtr 명령줄 도구를 통해 링크 테스트를 수행하는 방법의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!