패킷 손실을 디버그하는 방법은 무엇입니까?

Question

약 400kbps의 RTP 스트림을 제공하는 C++ 응용 프로그램 (Linux에서 실행)을 작성했습니다. 대부분의 목적지에 이것은 정상적으로 작동하지만 일부 목적지는 패킷 손실을 경험합니다. 문제가있는 목적지는 일반적인 연결 속도가 느린 것 같지만 보내려는 스트림에 충분히 빠른 속도 여야합니다.

이러한 대상은 패킷 손실없이 다른 응용 프로그램에 대해 유사한 RTP 스트림을 수신 할 수 있으므로 내 응용 프로그램에 문제가있는 것일 수 있습니다.

은 이미 몇 가지 확인 : 을 - tcpdump와, 나는 모든 RTP 패킷을 전송하는 시스템이 에 외출 참조 -은 UDP 장소 (내가 64킬로바이트과 300킬로바이트 사이의 크기를 시도) 을에 버퍼를 보내도합니다 - RTP 패킷은 대부분 조각화를 피하기 위해 1400 바이트 이하로 유지됩니다.

패킷 손실의 가능성을 최소화하기 위해 송신 응용 프로그램에서 수행 할 수있는 작업과 이러한 상황을 디버깅하는 가장 좋은 방법은 무엇입니까?

Answer 1

큰 버스트 덩어리로 패킷을 보내지 마십시오.

패킷 손실은 일반적으로 패킷 버퍼 크기가 제한되어있는 느린 라우터로 인해 발생합니다. 속도가 느린 라우터는 다른 10 개를 수신하기 전에 10 패킷을 전송할 시간이 있다면 1 Mbps를 처리 할 수 ​​있지만 100 Mbps 전송 측에서는 50 패킷의 큰 덩어리를 전송하는 경우 드롭하지 않아도됩니다. 40 명.

각 시간대에 쓸 내용 만 쓰도록 보내기를 시도하십시오. 1 초당 5 패킷 씩 쓰는 대신 1 초마다 5 패킷 씩 작성해야합니다.

Answer 2

이것은 원하는 답변이 아닐지 모르지만 패킷 손실 문제가있는 경우 TCP를 사용하도록 애플리케이션을 전환하려고 할 것이고 패킷 손실에 대한 대부분의 걱정은 내 마음에 들지 않습니다.

Answer 3

패킷 전송 속도를 줄여야합니다. 느린 연결은 모든 종류의 일을 의미 할 수 있으며 높은 속도로 패킷 (작거나 큰)을 보내려고하면 도움이되지 않습니다.

Answer 4

netstat에는 상황을 디버그하는 데 유용한 몇 가지 옵션이 있습니다.

먼저 하나가 NETSTAT -su입니다 (UDP 통계를 덤프) :

dima@linux-z8mw:/media> netstat -su              
IcmpMsg:                     
    InType3: 679 
    InType4: 20 
    InType11: 548 
    OutType3: 100 
Udp: 
    12945 packets received 
    88 packets to unknown port received. 
    0 packet receive errors 
    13139 packets sent 
    RcvbufErrors: 0 
    SndbufErrors: 0 
UdpLite: 
    InDatagrams: 0 
    NoPorts: 0 
    InErrors: 0 
    OutDatagrams: 0 
    RcvbufErrors: 0 
    SndbufErrors: 0 
IpExt: 
    InNoRoutes: 0 
    InTruncatedPkts: 0 
    InMcastPkts: 3877 
    OutMcastPkts: 3881 
    InBcastPkts: 0 
    OutBcastPkts: 0 
    InOctets: 7172779304 
    OutOctets: 785498393 
    InMcastOctets: 525749 
    OutMcastOctets: 525909 
    InBcastOctets: 0 
    OutBcastOctets: 0 

공지 사항 "RcvbufErrors"와 "SndbufErrors을"

추가 옵션 수신 프로세스의 UDP 버퍼를 보내 모니터하는 것입니다 :

dima@linux-z8mw:/media> netstat -ua 
Active Internet connections (servers and established) 
Proto Recv-Q Send-Q Local Address   Foreign Address   State 
udp  0  0 *:bootpc    *:* 
udp  0  0 *:40134     *:* 
udp  0  0 *:737     *:* 
udp  0  0 *:mdns     *:* 

관심있는 연결의 Recv-Q 및 Send-Q 열을 확인해야합니다. 값이 높고 0으로 떨어지지 않으면 프로세스가로드를 처리 할 수 ​​없습니다.

이 명령은 송신 및 수신 컴퓨터에서 사용할 수 있습니다.

은 또한 당신은 경로 추적 및 핑 (ping)을 결합 MTR을 사용할 수 있습니다 - 그것은 경로의 각 홉을 핑. 경로에서 느린 홉을 감지 할 수 있습니다. 다른 컴퓨터에서 실행하여 두 번째 컴퓨터와의 연결을 확인하십시오.

Answer 5

RTP은 일반적으로 손실이 많은 UDP을 사용합니다. 송신자와 수신자 사이에 패킷이 손실 될 수 있으므로 로컬 디버그는 유용하지 않다는 것을 보여줍니다.

명백한해야할 일 :

는

• A : 전체 데이터 속도를
• 나 감소 : 보내는 작은 패킷 더 자주 보다는 하나의 거대한 덩어리마다 몇을함으로써 '피크'데이터 속도를 줄입니다 초. 즉, UDP를 버퍼를 보내 주면됩니다. 어쩌면 단지 1400 바이트 일 수도 있습니다.
• c : RTP 변형 인 TCP 으로 전환 할 수 있는지 확인하십시오.

기타 모두 실패한 경우 WireShark은 친구입니다. 그것은 당신에게 당신의 앱에 의해 얼마나 많은 양의 데이터가 보내 졌는지에 대한 진정한 그림을 줄 것이다.