esercitazione iperf3: Misurare le prestazioni della rete su Linux e Windows

iperf3 è uno strumento a riga di comando per misurare la larghezza di banda della rete, il jitter e la perdita di pacchetti tra due macchine. Utilizza un modello client-server: una macchina ascolta, l'altra invia traffico e si ottengono numeri precisi di throughput. Questa guida tratta dell'installazione, dei test di base e avanzati e di come mettere a punto il sistema per ottenere risultati precisi sui collegamenti ad alta velocità.

Installazione di iperf3

Debian / Ubuntu

sudo apt update
sudo apt install iperf3

Confermare l'installazione con iperf3 --version. Installatelo sia sul server che sul client.

Fedora / CentOS / Rocky / Alma

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

sudo dnf install iperf3

Su CentOS 7, utilizzare invece yum. Se il pacchetto non viene trovato, attivare 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

Scaricare l'eseguibile standalone da iperf.fr o dal repo GitHub di ar51an/iperf3-win-builds. Estrarlo in una cartella come C:\iperf3, quindi verificare:

cd C:\iperf3
iperf3.exe -v

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

Impostazione del server

Avviare il server con:

iperf3 -s

Per impostazione predefinita, il server è in ascolto sulla porta TCP 5201. Per eseguirlo in background con 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 rete, usare -p per scegliere una porta diversa. Per eseguire il binding a un'interfaccia specifica, usare -B:

iperf3 -s -B 192.168.1.10

Per i test una tantum, iperf3 -s -1 gestisce una singola connessione client e poi esce. Sui collegamenti a elevata larghezza di banda (40 Gbps+), eseguire più istanze del server su porte diverse per aggirare i limiti della CPU a thread singolo.

Assicurarsi che il 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 sui client

Test TCP di base

iperf3 -c 192.168.1.10

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

Sui 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. Utilizzare flussi paralleli per saturare il collegamento:

iperf3 -c 192.168.1.10 -P 8

Lettura dei risultati

Ogni riga di intervallo mostra il Trasferimento (dati inviati) e il Bitrate (throughput). Per il TCP, osservare anche:

• Retr (ritrasmissioni). Numeri elevati significano perdita di pacchetti o congestione.
• Cwnd (finestra di congestione). Se è basso o bloccato, significa che i limiti di dimensione del buffer o della finestra stanno limitando il throughput.

Su un collegamento pulito da 1 Gbps, ci si aspetta circa 940 Mbps dopo l'overhead del protocollo. Il test si conclude con le righe di riepilogo del mittente e del destinatario. Su una rete stabile, queste dovrebbero corrispondere fedelmente.

Per i test UDP( flag-u ), 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 bidirezionale

Il flag --bidir (iperf3 3.7+) testa simultaneamente l'upload e il download:

iperf3 -c 192.168.1.10 --bidir

Entrambe le connessioni provengono dal client, quindi funzionano attraverso il NAT senza aprire porte aggiuntive. Se i risultati dei test bidirezionali sono molto inferiori a quelli dei test unidirezionali, il router o il modem via cavo potrebbero avere problemi con il traffico full-duplex.

Modalità inversa

Il flag -R inverte il flusso dei dati in modo che il server invii e il client riceva. In questo modo si 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 di forward e reverse indicano percorsi asimmetrici, congestione o errate configurazioni del buffer.

Test UDP

I test UDP rivelano il jitter e la perdita di pacchetti, che il TCP nasconde dietro le ritrasmissioni. Impostate sempre una larghezza di banda target con -b, poiché iperf3 ha come impostazione predefinita 1 Mbps per 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 qualità: il jitter sotto i 5 ms è buono per il VoIP, oltre i 30 ms provoca problemi di ascolto. La perdita di pacchetti superiore allo 0,1% degrada sensibilmente i media in tempo reale.

Messa a punto e risoluzione dei problemi

Problemi comuni

Ricevi solo 100 Mbps su un collegamento gigabit? Controllare la velocità dell'interfaccia fisica con ethtool eth0. A volte l'auto-negoziazione fallisce e fa cadere il collegamento a una velocità inferiore.

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

La CPU è al limite sui collegamenti veloci? Usare -Z (zerocopy) per ridurre il carico della CPU. Per i collegamenti a 40 Gbps e oltre, eseguire più istanze del server su porte diverse e distribuirle tra i core della CPU.

Risultati incoerenti? Usate -O 3 per omettere i primi secondi, mentre la finestra di congestione TCP aumenta. Lasciare 30 secondi tra i test per svuotare i buffer di rete.

Un singolo flusso è molto più lento dei flussi paralleli combinati? Se un flusso raggiunge 200 Mbps ma otto flussi combinati raggiungono 1,6 Gbps, la finestra TCP o i buffer del sistema operativo stanno limitando il singolo flusso. Sintonizzate i buffer di seguito.

Regolazione del buffer TCP

Iniziate calcolando il prodotto larghezza di banda-ritardo: larghezza di banda x RTT. Un collegamento da 10 Gbps con RTT di 50 ms fornisce un BDP di 62,5 MB. Impostate il vostro buffer massimo ad almeno 2 volte il BDP.

Aggiungere questi parametri a /etc/sysctl.d/99-tcp-tuning.conf e applicarli con sudo sysctl -p:

Mantenere net.ipv4.tcp_moderate_rcvbuf impostato su 1 in modo che il kernel si autoregoli entro questi intervalli. Abilitare net.ipv4.tcp_window_scaling (impostato su 1) per le finestre TCP più grandi di 64 KB.

È anche possibile passare dall'algoritmo di congestione CUBIC predefinito al BBR di Google. Sui collegamenti ad alta latenza con una certa perdita di pacchetti, BBR fornisce costantemente un throughput superiore a CUBIC.

Usate il flag -w in iperf3 per testare specifiche dimensioni di buffer, ma notate che non possono superare i valori rmem_max o wmem_max del kernel. Iniziate con 8 MB per i collegamenti gigabit, 512 KB per 100 Mbps.

Se state facendo il provisioning di server dedicati e volete convalidare le prestazioni della rete, eseguite i test di base di iperf3 subito dopo la configurazione e dopo qualsiasi modifica della rete per individuare tempestivamente eventuali regressioni.

Raccomandazioni video