패킷 손실을 어떻게 진단합니까?

나는 이것이 매우 주관적이고 많은 변수에 의존한다는 것을 알고 있지만, 대부분의 사람들이 주어진 시스템에서 패킷 손실을 진단해야 할 때 어떤 단계를 거쳐야하는지 궁금합니다.

저는 네트워크 엔지니어이므로이를 내 관점에서 설명하겠습니다.

나를 위해, 패킷 손실 진단은 일반적으로 "잘 작동하지 않습니다"로 시작합니다. 거기에서 나는 보통 통신의 양쪽 끝 (일반적으로 사무실의 워크 스테이션과 서버)에 가까운 키트를 찾고 가능한 한 다른 쪽 끝에 핑 (이상적으로는 "원격 끝점")을 찾으려고 노력합니다. 그러나 때로는 핑을 보낼 수없는 방화벽이 있으므로 라우터에서 LAN 인터페이스를 설정해야합니다)) 내가 손실을 볼 수 있는지 확인하십시오.

손실을 볼 수있는 경우 대개 중간에 "대역폭 부족"또는 "문제가있는 링크"가 발생하므로 네트워크를 통한 경로를 찾아 중간에서 시작하여 일반적으로 한쪽 또는 다른 쪽을 제공합니다.

손실이 보이지 않으면 다음 두 단계는 "더 많은 핑 보내기"또는 "더 큰 핑 보내기"경향이 있습니다. 그것이 정렬되지 않으면 문제가 무엇인지를 나타내지 않으면, 엔드 포인트 사이의 전체 경로를 통해 QoS 정책 및 인터페이스 통계를 살펴볼 차례입니다.

그것이 아무것도 발견되지 않으면 이제 가정에 의문을 제기 할 시간입니다. 실제로 패킷 손실로 고통 받고 있습니까? 호스트에서 WireShark (또는 이와 동등한 기능)을 사용하거나 네트워크 탭을 통해 스니퍼 시스템 (WireShark 또는 유사 기능 사용)을 연결하여 양쪽 끝을 동시에 캡처하는 유일한 확실한 방법입니다. 그런 다음 두 패킷 캡처를 비교하는 재미가 온다 ...

때때로 "패킷 손실"로 간주되는 것은 단순히 서버 쪽에서 무언가를 느리게하는 것입니다 (예 : "같은 LAN에서"데이터베이스를 "20ms 떨어짐"으로 옮기고 엄청나게 많은 쿼리가 필요한 쿼리 사용) 프론트 엔드와 데이터베이스 사이의 앞뒤로).

리눅스 시스템의 관점에서, 먼저 네트워크 인터페이스에서 패킷 손실을 찾아 보겠다 ethtool -S ethX.

대부분의 경우 링 버퍼를 늘리면 ethtool -G ethX rx VALUE이 문제 가 해결됩니다.

시스템에 irqbalance 서비스가 없어 인터럽트가 밸런싱되지 않는 경우가 있으므로 chkconfig(EL) 또는 update-rc(Debuntu)에서이 서비스가 실행 중인지 확인하십시오. /proc/interrupts모든 IRQ 채널을 서비스하는 코어 0 만 표시 하므로 인터럽트가 밸런싱되지 않는지 알 수 있습니다 .

이 작업에 실패 net.core.netdev_max_backlog하면 시스템이 몇 기가비트 이상의 트래픽을 통과하는 경우 증가해야 할 수 있습니다 net.core.netdev_budget.

그래도 문제가 해결되지 않으면 인터럽트 통합 값을로 조정할 수 ethtool -C있습니다.

네트워크 인터페이스에 패킷 손실이없는 netstat -s경우 소켓 버퍼에 손실이 있는지 살펴 보고 " pruned from receive queue"및 " dropped from out-of-order queue" 와 같은 통계로보고 합니다.

적절한 프로토콜 (예 : net.ipv4.tcp_rmemTCP)에 대한 기본 및 최대 소켓 버퍼를 늘릴 수 있습니다 .

응용 프로그램이 자체 소켓 버퍼 크기를 설정하면 응용 프로그램의 구성 변경이 필요할 수 있습니다. 응용 프로그램에 하드 코드 된 소켓 버퍼 크기가있는 경우 응용 프로그램 공급 업체에 문의하십시오.

개인적으로 NIC에 대한 프로토콜 오프로드 (체크섬, 세그먼테이션 오프로드, 큰 수신 오프로드)가 가치보다 더 많은 문제를 일으키는 것처럼 싫어합니다. 이러한 설정을 사용하여 놀아 보는 ethtool -K것이 좋습니다.

modinfo <drivername>일부 기능을 변경해야 할 수도 있으므로 NIC ( ) 의 모듈 옵션을 확인하십시오 . 하나의 큰 TCP 스트림을 처리하는 시스템에서 Intel의 Flow Director를 사용하면 해당 스트림의 효율성이 떨어질 수 있으므로 FDir을 끄십시오.

그 외에도 특정 작업량에 맞게이 특정 시스템을 수동 조정하는 것 외에도 귀하의 질문 범위를 벗어난 것 같습니다.

wireshark (Windows) 및 tcpdump (Linux 터미널)와 같은 패킷 캡처 도구를 사용하여 시작합니다.

방화벽 구성 (네트워크 방화벽뿐만 아니라 호스트 방화벽)도 확인합니다.

분리 한 다음 제거하십시오.

문제가있는 경로의 가장 작은 하위 집합을 찾으십시오. 다른 조합을 테스트하거나 사용자 보고서를 추출하여이를 수행하십시오. 적도의 시간을 고려하는 것을 잊지 마십시오. 특정 네트워크에 대한 모든 트래픽에서 패킷 손실이 발생하거나 무선 클라이언트 만 겪고있을 수 있습니다. 다른 트래픽 유형을 고려하십시오 (ping 제한 속도). 가장 신뢰할 수 있고 쉽게 반복 가능한 테스트 방법을 찾으십시오.

그런 다음 잠재적 원인을 제거하십시오. 링크의 트래픽을 일시적으로 줄이고 스펙트럼에서 간섭 원을 제거하고 특정 클라이언트의 연결을 끊습니다. 결국 문제의 원인을 찾을 수 있습니다.

때때로 패킷 덤프를 보거나 추측을 통해 바로 가기를 수행 할 수 있습니다 (항상 비트 토렌트 임). 또한 교수 서버 오류가 훌륭하다고 말합니다.

큰 핑을 보내지 않으면 핑에 패킷 손실이 표시되지 않을 수 있습니다! 핑 패킷 크기를 늘릴 때까지 네트워크에서 패킷 손실이 보이지 않았습니다.

창문 :

ping -n 30 -l <largevalue> <target>

들어 largevalue나는 40960을 사용 (40K 패킷)

들어 target난에서 처음 몇 IP 주소를 사용tracert google.com

(내 라우터 및 케이블 모뎀이었습니다). 체인 아래로 내려가는 장치 중 하나는 큰 패킷의 경우 끔찍한 패킷 손실 (> 60 %) 이었지만 작은 값의 경우 0 %였습니다. 다시 시작하여 수정했지만 케이블이나 교체해야 할 내부 장치 일 수도 있습니다.