Tutorial su iperf3: misurare le prestazioni di rete su Linux e Windows

iperf3 è uno strumento a riga di comando per misurare la larghezza di banda di rete, il jitter e la perdita di pacchetti tra due macchine. Utilizza un modello client-server: una macchina ascolta, l'altra invia il traffico e si ottengono dati precisi sulla velocità effettiva. Questa guida tratta l'installazione, i test di base e avanzati e come ottimizzare il sistema per ottenere risultati accurati su collegamenti ad alta velocità.

Installazione di iperf3

Debian / Ubuntu

sudo apt update
sudo apt install iperf3

Confermare l'installazione con iperf3 --version. Installarlo sia sul server che sui computer client.

Fedora / CentOS / Rocky / Alma

Su Fedora 22+ o CentOS 8+, Rocky o AlmaLinux:

sudo dnf install iperf3

Su CentOS 7, utilizzare yum . Se il pacchetto non viene trovato, abilita prima il repository EPEL:

sudo yum install epel-release
sudo yum install iperf3

Se il firewall è attivo, aprire la porta 5201:

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

Windows

Scarica l'eseguibile standalone da iperf.fr o dal repository GitHub ar51an/iperf3-win-builds. Estrailo in una cartella come C:\iperf3, quindi verifica:

cd C:\iperf3
iperf3.exe -v

Per eseguire iperf3 da qualsiasi directory, aggiungi la cartella al PATH di sistema tramite Proprietà del sistema > Avanzate > Variabili d'ambiente. Dovrai anche creare una regola di firewall in entrata che consenta il TCP sulla porta 5201 nel Firewall di Windows Defender.

Configurazione del server

Avviare il server con:

iperf3 -s

Questo ascolta sulla porta TCP 5201 per impostazione predefinita. Per eseguirlo in background con la registrazione:

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

Verificare che sia in esecuzione con ss -tulpn | grep 5201.

Se la porta 5201 è bloccata sulla tua rete, usa -p per scegliere una porta diversa. Per associarlo a un'interfaccia specifica, usa -B:

iperf3 -s -B 192.168.1.10

Per test una tantum, iperf3 -s -1 gestisce una singola connessione client e poi si chiude. Su collegamenti a banda larga (40 Gbps+), esegui più istanze del server su porte diverse per aggirare i limiti della CPU a thread singolo.

Assicurati che il tuo firewall consenta il traffico sulla porta scelta. Su Ubuntu/Debian con UFW:

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

Esecuzione dei test client

Test TCP di base

iperf3 -c 192.168.1.10

Questo misura la larghezza di banda in upload su TCP per 10 secondi. Estendere la durata con -t:

iperf3 -c 192.168.1.10 -t 30

Su collegamenti a 10 Gbps o 25 Gbps, un singolo flusso TCP spesso raggiunge un massimo di 3–5 Gbps a causa dei limiti della CPU single-core. Utilizza flussi paralleli per saturare il collegamento:

iperf3 -c 192.168.1.10 -P 8

Lettura dei risultati

Ogni riga di intervallo mostra Trasferimento (dati inviati) e Velocità di trasmissione (throughput). Per il TCP, controlla anche:

• Retr (ritrasmissioni). Valori elevati indicano perdita di pacchetti o congestione.
• Cwnd (finestra di congestione). Se è basso o bloccato, i limiti delle dimensioni del buffer o della finestra stanno limitando la velocità effettiva.

Su una connessione pulita da 1 Gbps, aspettati circa 940 Mbps al netto dell'overhead del protocollo. Il test termina con le righe di riepilogo del mittente e del destinatario. Su una rete stabile, questi valori dovrebbero corrispondere quasi perfettamente.

Per i test UDP (-u flag), l'output aggiunge il jitter (varianza di arrivo dei pacchetti) e i datagrammi persi/totali. Un jitter inferiore a 1 ms e una perdita dello 0% sono ideali per il traffico in tempo reale come il VoIP.

Flag utili

Test avanzati

Test bidirezionali

Il --bidir flag (iperf3 3.7+) esegue test di upload e download simultanei:

iperf3 -c 192.168.1.10 --bidir

Entrambe le connessioni hanno origine dal client, quindi questo funziona attraverso il NAT senza aprire porte aggiuntive. Se i risultati bidirezionali sono molto inferiori rispetto ai test unidirezionali, il router o il modem via cavo potrebbero avere difficoltà con il traffico full-duplex.

Modalità inversa

Il -R flag inverte il flusso di dati in modo che il server invii e il client riceva. Questo misura la velocità di download senza scambiare i ruoli:

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

Grandi differenze tra i risultati in avanti e in reverse indicano percorsi asimmetrici, congestione o configurazioni errate del buffer.

Test UDP

I test UDP rivelano jitter e perdita di pacchetti, che il TCP nasconde dietro le ritrasmissioni. Impostare sempre una larghezza di banda target con -b, poiché iperf3 imposta di default 1 Mbps per l'UDP:

iperf3 -c 192.168.1.10 -u -b 1G

Per simulare il traffico VoIP (100 chiamate, pacchetti da 200 byte):

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

Parametri di riferimento di qualità: un jitter inferiore a 5 ms è buono per il VoIP, mentre oltre i 30 ms causa problemi udibili. Una perdita di pacchetti superiore allo 0,1% degrada sensibilmente i media in tempo reale.

Ottimizzazione e risoluzione dei problemi

Problemi comuni

Raggiungi solo 100 Mbps su un collegamento gigabit? Controlla la velocità della tua interfaccia fisica con ethtool eth0. A volte l'auto-negoziazione fallisce e riduce la velocità del collegamento.

L'MSS mostra 536 byte su Ethernet? Probabilmente il Path MTU Discovery è disabilitato. L'MSS predefinito per un MTU da 1.500 byte è 1.460 byte. Utilizza -m durante i test per verificare. Un MSS di 536 byte spreca larghezza di banda e aggiunge overhead.

La CPU va al massimo su collegamenti veloci? Usa -Z (zerocopy) per ridurre il carico della CPU. Per velocità superiori a 40 Gbps, esegui più istanze del server su porte diverse e distribuiscile tra i core della CPU.

Risultati incoerenti? Usa -O 3 per omettere i primi secondi mentre la finestra di congestione TCP aumenta gradualmente. Lascia 30 secondi tra un'esecuzione del test e l'altra per svuotare i buffer di rete.

Il singolo flusso è molto più lento rispetto ai flussi paralleli combinati? Se un flusso raggiunge i 200 Mbps ma otto flussi combinati raggiungono 1,6 Gbps, la finestra TCP o i buffer del sistema operativo stanno limitando il singolo flusso. Ottimizza i buffer qui sotto.

Ottimizzazione del buffer TCP

Inizia calcolando il prodotto larghezza di banda-ritardo (BDP): larghezza di banda x RTT. Un collegamento da 10 Gbps con un RTT di 50 ms dà un BDP di 62,5 MB. Imposta il buffer massimo ad almeno 2 volte il BDP.

Aggiungili a /etc/sysctl.d/99-tcp-tuning.conf e applicare con sudo sysctl -p:

Impostare net.ipv4.tcp_moderate_rcvbuf impostato su 1 in modo che il kernel si regoli automaticamente entro questi intervalli. Abilita net.ipv4.tcp_window_scaling (impostare su 1) per finestre TCP superiori a 64 KB.

È anche possibile passare dall'algoritmo di congestione predefinito CUBIC al BBR di Google. Su collegamenti ad alta latenza con una certa perdita di pacchetti, il BBR offre costantemente un throughput più elevato rispetto a CUBIC.

Utilizza il -w flag in iperf3 per testare dimensioni specifiche del buffer, ma si noti che queste non possono superare il valore rmem_max o wmem_max. Iniziare con 8 MB per collegamenti gigabit, 512 KB per 100 Mbps.

Se state configurando server dedicati e volete verificare le prestazioni di rete, eseguite i test di riferimento di iperf3 subito dopo l'installazione e dopo ogni modifica alla rete per individuare tempestivamente eventuali regressioni.

Raccomandazione video