iPerf를 사용하여 UDP 패킷 손실을 테스트하고 문제를 해결하는 방법

이 기사의 내용은 iPerf를 사용하여 UDP 패킷 손실 문제를 테스트하고 해결하는 방법에 대한 것입니다. 필요한 친구가 참고할 수 있기를 바랍니다.

iPerf를 사용하여 UDP 패킷 손실 문제 테스트 및 해결

현상 설명

Express 채널을 사용하여 동일한 지역에 있는 두 개의 VPC 네트워크 유형 ECS 인스턴스를 연결한 후 iPerf를 사용하여 두 인스턴스 UDP를 테스트합니다. 네트워크 간 패킷 손실률을 살펴보면, 테스트 대역폭이 50Mbps 이상에 도달할 때 패킷 손실이 발생했으며, 대역폭이 증가할수록 패킷 손실률이 증가하는 경향을 보였다. 아래와 같이

Problem Analysis

두 네트워크 유형 ECS 인스턴스의 프라이빗 IP가 VPC ECS A(192.168.104.235) 및 ECS B(10.182.83.13)라고 가정하고 Netcat( NC) UDP 데이터 패킷을 모니터링하고 전송합니다. 네트워크 유형의 ECS 인스턴스 A와 인스턴스 B 간의 통신 링크 다이어그램은 다음과 같습니다.

데이터 흐름 방향은 다음과 같습니다.

ECS A(192.168.104.235)-> NC 1(100.105.59.3)-> VGW(10.141.166.253)-> NC 2(100.105.59.9)-> ECS B(10.182.83.13)

링크 문제를 해결하고 분석해야 합니다. 손실을 알아내기 위해 패키지의 최종 이유입니다.

Solution

참고: 원본 Netcat(예: NC 1)과 대상 Netcat(예: NC 2) 간의 이전 통신만 볼 수 있으므로 패킷 캡처 및 문제 해결 중에 오해를 피해야 합니다. 무작위로 Netcat(NC)이라고 판단하여 패킷 간의 직접 통신이 끊어집니다.

문제 해결 시 원본 끝에서 캡처된 eth0 패킷이 VGW로 전송되지만 대상 끝에서 패킷을 캡처할 때는 다음 예와 같이 셸이 대상 NC 2 IP를 캡슐화하는 것을 발견합니다.

 [Time ] 17:32:07.130844   Point: `input `
 [ETHER] 24:4c:07:33:0e:02 -> 00:04:37:28:00:65, eth_type: 0x0800
 [IPv4 ] 100.105.59.3 -> 10.141.166.253
 proto: 17, ver: 04, ihl: 05, len: 1534, ident: 59824,R: 0, DF: 1, MF: 0, offset: 0, ttl: 60, chksum: 0xfe47
 [UDP  ] sport: 46703, dport: 250, size: 1514, chksum: 0x0000
 [VxLan] debug_flag: 0, vlan_tag: 0, payload_type: 0, version: 1, tunnel_id: 1878597, tos: 0, tof: 0
 [IPv4 ] 192.168.104.235 -> 10.182.83.13
 proto: 17, ver: 04, ihl: 05, len: 1498, ident: 55469,R: 0, DF: 1, MF: 0, offset: 0, ttl: 64, chksum: 0xd50e
 [UDP  ] sport: 36687, dport: 5001, size: 1478, chksum: 0xa0aa
 [Time ] 17:32:07.130854   Point: `output`
 [ETHER] 24:4c:07:33:0e:02 -> 00:04:37:28:00:65, eth_type: 0x0800
 [IPv4 ] 100.105.59.3 -> 100.105.59.9
 proto: 17, ver: 04, ihl: 05, len: 1534, ident: 59824,R: 0, DF: 1, MF: 0, offset: 0, ttl: 60, chksum: 0x0000
 [UDP  ] sport: 46703, dport: 250, size: 1514, chksum: 0x0000
 [VxLan] debug_flag: 0, vlan_tag: 0, payload_type: 0, version: 1, tunnel_id: 2125861, tos: 0, tof: 0
 [IPv4 ] 192.168.104.235 -> 10.182.83.13
 proto: 17, ver: 04, ihl: 05, len: 1498, ident: 55469,R: 0, DF: 1, MF: 0, offset: 0, ttl: 64, chksum: 0xd50e
 [UDP  ] sport: 36687, dport: 5001, size: 1478, chksum: 0xa0aa

데이터 패킷이 VGW를 통과한 것을 확인한 후 패킷 캡처 정보 카운트를 시작합니다.

ECS A는 iPerf를 통해 UDP 트래픽을 수신합니다: iperf -c 10.182.83.13 -u -b 600m

ECS B는 iPerf를 통해 수신합니다: iperf -u -s

인스턴스 내부의 패킷을 캡처합니다.

ECS A：sudo tcpdump -w ~/client.pcap -n -i eth0 src host 192.168.104.25 and src port 1234
ECS B：sudo tcpdump -w ~/server.pcap -n -i eth0 src host 192.168.104.25 and src port 1234

두 개의 NC eth0에서 패킷을 포착했습니다.

NC 1：sudo houyi-tcpdump -w /apsara/i-6we6pnh19n2q7srkgomd.pcap -nnK -i eth0
 udp and src inner_port 1234 and dst inner_host 10.182.83.13
NC 2：sudo houyi-tcpdump -B 4096 -w /apsara/i-6we53i9h3ducbju5rmuw.pap -nn -i eth0 
udp -K and src inner_host 192.168.104.235 and src inner_port 1234

ASW 및 LSW에 스트림 시스템 배포.

100.105.59.3:46728 -> 10.141.166.253:250

참고: 대상 패킷 셸은 대상 NC 1 IP를 자동으로 캡슐화하므로 VGW 측 데이터 패킷의 메시지 형식은 100.105.59.3:46728 ->

패킷 캡처 결과를 기반으로 분석합니다.

ECS A 패킷 손실/전송: 171/510203

NC 1 eth0 패킷 전송: 510204

ASW 및 LSW 흐름 통계 아웃바운드 패킷: 510204

NC 2 eth0 패킷 수신: 510204

ECS B 패킷 수신: 5 10 204 ,커널 2162에 의해 삭제된 507442

위 분석에서는 인스턴스 프로토콜 스택에서 패킷 손실을 찾습니다. 인스턴스의 내부 UDP 버퍼 크기를 조정하여 네트워크 스택(스택)을 조정합니다. 기본 UDF 버퍼 크기는 212992(208KB)입니다. 2097152(2MB)로 조정할 수 있습니다.

/proc/sys/net/core/rmem_default #默认的接收数据包内存大小
/proc/sys/net/core/rmem_max #最大的接收数据包内存大小

조정 후 UDP 패킷 손실을 테스트합니다.

위 내용은 iPerf를 사용하여 UDP 패킷 손실을 테스트하고 문제를 해결하는 방법의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!