iperf3 튜토리얼: Linux 및 Windows에서 네트워크 성능 측정하기

iperf3는 두 대의 컴퓨터 간 네트워크 대역폭, 지터(jitter), 패킷 손실을 측정하는 명령줄 도구입니다. 이 도구는 클라이언트-서버 모델을 사용합니다. 한 대의 컴퓨터가 수신 대기하고, 다른 한 대가 트래픽을 전송하면 정확한 처리량 수치를 얻을 수 있습니다. 이 가이드에서는 설치 방법, 기본 및 고급 테스트, 그리고 고속 링크에서 정확한 결과를 얻기 위해 시스템을 튜닝하는 방법을 다룹니다.

iperf3 설치

데비안 / 우분투

sudo apt update
sudo apt install iperf3

다음 명령어로 설치 여부를 확인하십시오 iperf3 --version. 서버와 클라이언트 머신 모두에 설치하십시오.

Fedora / CentOS / Rocky / Alma

Fedora 22 이상, CentOS 8 이상, Rocky 또는 AlmaLinux의 경우:

sudo dnf install iperf3

CentOS 7에서는 yum 를 대신 사용하십시오. 패키지를 찾을 수 없는 경우, 먼저 EPEL 저장소를 활성화하십시오:

sudo yum install epel-release
sudo yum install iperf3

방화벽이 활성화되어 있다면 포트 5201을 열어주세요:

sudo firewall-cmd --add-port=5201/tcp --permanent
sudo firewall-cmd --reload

Windows

iperf.fr 또는 ar51an/iperf3-win-builds GitHub 저장소에서 독립 실행형 파일을 다운로드하십시오. 이를 C:\iperf3와 같은 폴더에 압축을 풀고, 다음을 확인하십시오:

cd C:\iperf3
iperf3.exe -v

어떤 디렉터리에서든 iperf3를 실행하려면, 시스템 속성 > 고급 > 환경 변수를 통해 해당 폴더를 시스템 PATH에 추가하십시오. 또한 Windows Defender 방화벽에서 포트 5201의 TCP를 허용하는 인바운드 방화벽 규칙을 생성해야 합니다.

서버 설정

다음 명령어로 서버를 시작합니다:

iperf3 -s

기본적으로 TCP 포트 5201에서 연결을 수신합니다. 백그라운드에서 실행하고 로그를 기록하려면 다음 명령을 실행하십시오:

iperf3 -s -D --logfile /var/log/iperf3.log

다음 명령어로 실행 중인지 확인합니다: ss -tulpn | grep 5201.

다음 명령어로 실행 중인지 확인하십시오: -p 를 사용하여 다른 포트를 지정하십시오. 특정 인터페이스에 바인딩하려면 -B:

iperf3 -s -B 192.168.1.10

일회성 테스트의 경우, iperf3 -s -1 는 단일 클라이언트 연결을 처리한 후 종료됩니다. 고대역폭 링크(40 Gbps 이상)에서는 단일 스레드 CPU 제한을 우회하기 위해 서로 다른 포트에서 여러 서버 인스턴스를 실행하십시오.

선택한 포트에 대한 트래픽이 방화벽을 통과할 수 있도록 설정하십시오. UFW가 설치된 Ubuntu/Debian의 경우:

sudo ufw allow 5201/tcp
sudo ufw allow 5201/udp   # if testing UDP

클라이언트 테스트 실행

기본 TCP 테스트

iperf3 -c 192.168.1.10

이 테스트는 10초 동안 TCP를 통한 업로드 대역폭을 측정합니다. 지속 시간을 늘리려면 -t:

iperf3 -c 192.168.1.10 -t 30

10Gbps 또는 25Gbps 링크에서는 단일 코어 CPU의 한계로 인해 단일 TCP 스트림의 최대 속도가 3~5Gbps에 그치는 경우가 많습니다. 링크를 포화 상태로 만들려면 병렬 스트림을 사용하십시오:

iperf3 -c 192.168.1.10 -P 8

결과 확인

각 간격 행에는 전송량(전송된 데이터)과 비트레이트(처리량)가 표시됩니다. TCP의 경우 다음 항목도 확인하십시오:

• Retr(재전송). 수치가 높으면 패킷 손실이나 혼잡을 의미합니다.
• Cwnd(혼잡 창). 이 값이 낮거나 정체된 경우, 버퍼 또는 창 크기 제한으로 인해 처리량이 제한되고 있습니다.

오류가 없는 1 Gbps 링크에서는 프로토콜 오버헤드를 고려했을 때 약 940 Mbps의 처리량을 기대할 수 있습니다. 테스트는 송신자 및 수신자 요약 행으로 종료됩니다. 안정적인 네트워크 환경에서는 이 두 수치가 거의 일치해야 합니다.

UDP 테스트(-u flag)의 경우, 출력 결과에 지터(패킷 도착 변동성)와 손실된/총 데이터그램 수가 추가됩니다. 지터가 1ms 미만이고 손실률이 0%인 경우 VoIP와 같은 실시간 트래픽에 이상적입니다.

유용한 플래그

고급 테스트

양방향 테스트

--bidir 플래그(iperf3 3.7+)는 업로드와 다운로드를 동시에 테스트합니다:

iperf3 -c 192.168.1.10 --bidir

두 연결 모두 클라이언트에서 시작되므로, 별도의 포트를 열지 않고도 NAT를 통해 작동합니다. 양방향 테스트 결과가 단방향 테스트보다 훨씬 낮다면, 라우터나 케이블 모뎀이 전이중 트래픽 처리에 어려움을 겪고 있을 수 있습니다.

리버스 모드

' -R 플래그는 데이터 흐름을 반전시켜 서버가 전송하고 클라이언트가 수신하도록 합니다. 이는 역할을 바꾸지 않고 다운로드 속도를 측정합니다:

iperf3 -c 192.168.1.10 -t 30 -i 5 -R

전방 및 역방향 결과 간에 큰 차이가 난다면, 비대칭 경로, 혼잡 또는 버퍼 설정 오류가 원인일 수 있습니다.

UDP 테스트

UDP 테스트는 TCP가 재전송으로 숨기는 지터와 패킷 손실을 드러냅니다. iperf3는 UDP의 기본값을 1 Mbps로 설정하므로, 항상 -b, iperf3는 UDP의 경우 기본적으로 1 Mbps로 설정되어 있기 때문입니다:

iperf3 -c 192.168.1.10 -u -b 1G

VoIP 트래픽 시뮬레이션(100통화, 200바이트 패킷):

iperf3 -c 192.168.1.10 -u -b 8M -l 200

품질 벤치마크: 5ms 미만의 지터는 VoIP에 적합하며, 30ms를 초과하면 음질 문제가 발생합니다. 0.1% 이상의 패킷 손실은 실시간 미디어 품질을 현저히 저하시킵니다.

튜닝 및 문제 해결

일반적인 문제

기가비트 링크에서 100 Mbps만 나오나요? 다음 명령어로 물리적 인터페이스 속도를 확인하세요 ethtool eth0확인해 보세요. 자동 협상(Auto-negotiation)이 실패하여 링크 속도가 더 낮은 수준으로 떨어지는 경우가 있습니다.

이더넷에서 MSS가 536바이트로 표시되나요? Path MTU Discovery가 비활성화되어 있을 가능성이 높습니다. 1,500바이트 MTU의 기본 MSS는 1,460바이트입니다. 테스트 중에 -m 를 사용하여 테스트해 보세요. 536바이트 MSS는 대역폭을 낭비하고 오버헤드를 증가시킵니다.

고속 링크에서 CPU 사용률이 최대치에 도달하나요? -Z (zerocopy)를 사용하여 CPU 부하를 줄이세요. 40Gbps 이상의 경우, 서로 다른 포트에서 여러 서버 인스턴스를 실행하고 CPU 코어에 분산시키세요.

결과가 일관되지 않나요? -O 3 를 사용하여 TCP 혼잡 창이 확장되는 동안 처음 몇 초를 생략하십시오. 네트워크 버퍼를 비우기 위해 테스트 실행 사이에 30초의 간격을 두십시오.

단일 스트림이 병렬 스트림 합계보다 훨씬 느린가요? 단일 스트림이 200 Mbps를 기록하지만 8개 스트림을 합치면 1.6 Gbps에 도달한다면, TCP 윈도우나 OS 버퍼가 단일 스트림의 속도를 제한하고 있는 것입니다. 아래의 버퍼를 조정하십시오.

TCP 버퍼 조정

먼저 대역폭-지연 곱(BDP)을 계산하십시오: 대역폭 x 왕복 시간(RTT). 10 Gbps 링크에 50 ms RTT를 적용하면 BDP는 62.5 MB가 됩니다. 최대 버퍼 크기를 BDP의 최소 2배로 설정하십시오.

이 값들을 /etc/sysctl.d/99-tcp-tuning.conf 다음과 같이 추가하고 sudo sysctl -p:

이 값을 net.ipv4.tcp_moderate_rcvbuf 값을 1로 설정하여 커널이 이 범위 내에서 자동 조정되도록 하십시오. 64 KB보다 큰 TCP 윈도우의 경우 net.ipv4.tcp_window_scaling (1로 설정)을 활성화하면 64KB보다 큰 TCP 윈도우를 사용할 수 있습니다.

기본 CUBIC 혼잡 알고리즘에서 Google의 BBR로 전환할 수도 있습니다. 일부 패킷 손실이 발생하는 지연 시간이 긴 링크에서 BBR은 CUBIC보다 지속적으로 더 높은 처리량을 제공합니다.

iperf3의 -w flag를 사용하여 특정 버퍼 크기를 테스트할 수 있지만, 이는 커널의 rmem_max 또는 wmem_max을 초과할 수 없다는 점에 유의하십시오. 기가비트 링크의 경우 8MB, 100Mbps의 경우 512KB로 시작하십시오.

전용 서버를 프로비저닝하고 네트워크 성능을 검증하려는 경우, 설정 직후와 네트워크 변경 후 바로 iperf3 기준 테스트를 실행하여 성능 저하를 조기에 파악하십시오.

추천 동영상