1. Instalación y arquitectura del primer escenario
La herramienta está disponible en prácticamente cualquier entorno. Para comenzar, se requieren dos nodos conectados en la misma red o con rutas IP accesibles entre sí:
# Debian, Ubuntu y derivados
sudo apt install iperf3
# Fedora, RHEL, AlmaLinux
sudo dnf install iperf3
# Arch Linux
sudo pacman -S iperf3
# macOS mediante Homebrew
brew install iperf3
# Windows: descargar binarios desde iperf.fr o usar winget
winget install iperf3
La arquitectura de prueba requiere un daemon receptor y un generador de tráfico. En el equipo que actuará como destino de las mediciones:
iperf3 --server --port 5001
El modificador --port (o -p) permite personalizar el puerto de escucha cuando el predeterminado 5201 está ocupado por otros servicios.
Desde el equipo origen, iniciar la medición hacia la dirección del receptor:
iperf3 --client 192.168.1.50 --port 5001
La salida típica muestra intervalos temporales con tres valores esenciales:
[ 5] 0.00-10.00 sec 1.09 GBytes 935 Mbits/sec 0 sender
[ 5] 0.00-10.00 sec 1.08 GBytes 928 Mbits/sec receiver
La discrepancia entre sender y receiver indica pérdida de segmentos TCP o limitaciones en el buffer del sistema operativo destino. Una diferencia mayor al 1% sugiere congestión o descartes en equipos intermedios.
2. Métricas críticas: más allá del caudal bruto
El caudal (throughput) es solo una variable en la ecuación del rendimiento. Para evaluaciones completas, iperf3 expone parámetros que revelan el comportamiento de la pila de red:
2.1 Jitter y datagramas UDP
TCP oculta la fluctuación de latencia mediante retransmisiones y control de congestión. Para exponer el comportamiento real del enlace, especialmente en aplicaciones de tiempo real (VoIP, streaming), UDP resulta revelador:
# Servidor
iperf3 --server --udp
# Cliente con tasa objetivo de 100 Mbps y duración extendida
iperf3 --client 192.168.1.50 --udp --bandwidth 100M --time 30 --json
La bandera --json genera salida estructurada ideal para procesamiento automatizado. Los campos relevantes incluyen:
jitter: variación en la llegada de paquetes, crítico para calidad de vozlost_packetsylost_percent: tasa de descarte directamente observableout_of_order: datagramas que llegaron desordenados, indicativo de rutas asimétricas
2.2 Ventana de congestión y RTT
Para identificar si el caudal se ve limitado por la latencia de ida y vuelta (especialmente en enlaces WAN o satelitales), forzar ventanas específicas:
# Ventana de 256 KB, útil para enlaces de alta latencia
iperf3 --client 10.0.0.5 --window 256K --set-mss 1360
# Comparativa: dejar que TCP negocie automáticamente
iperf3 --client 10.0.0.5 --window 0
La opción --set-mss ajusta el tamaño máximo de segmento, útil cuando MTU path discovery falla o se sospecha de fragmentación.
3. Patrones de tráfico avanzados
Las pruebas de caudal constante rara vez reflejan aplicaciones reales. iperf3 permite simular cargas variables:
# Perfil escalonado: 10s a 50M, luego 20s a 150M, finalmente 10s a 25M
iperf3 --client 192.168.1.50 --udp --bandwidth 50M --time 10
iperf3 --client 192.168.1.50 --udp --bandwidth 150M --time 20
iperf3 --client 192.168.1.50 --udp --bandwidth 25M --time 10
Para flujos paralelos que simulen múltiples usuarios o conexiones de base de datos:
# 8 flujos simultáneos, útil para saturar buffers de equipos de red
iperf3 --client 192.168.1.50 --parallel 8 --time 60
La comparación entre resultado agregado y flujos individuales revela equidad en la distribución de recursos (fair queuing) en routers intermedios.
4. Interpretación de anomalías comunes
| Síntoma en salida | Interpretación técnica | Acción diagnóstica |
|---|---|---|
| Caudo decreciente en intervalos finales | Buffers de red saturándose, posible tail drop | Reducir --bandwidth o verificar QoS en routers |
| Alta variación de jitter con UDP | Colas de prioridad mal configuradas o cnotención de CPU | Verificar irqbalance y afinidad de NIC |
| Retransmisiones TCP concentradas en intervalos específicos | Eventos de congestión periódicos, posiblemente por tráfico de fondo | Correlacionar con horarios de backup o sincronización |
| Receiver << Sender consistentemente | Descartes en capa de red o aplicación receptor saturada | Verificar netstat -s en destino por drops de socket |
5. Automatización y persistencia de resultados
Para monitoreo continuo o integración en pipelines CI/CD, combinar opciones de formato con herramientas de procesamiento:
# Script de prueba periódica con salida estructurada
#!/bin/bash
DESTINO=${1:-10.0.0.5}
TIMESTAMP=$(date +%Y%m%d_%H%M%S)
ARCHIVO="iperf_${TIMESTAMP}.json"
iperf3 --client "$DESTINO" --json --time 30 --interval 1 > "$ARCHIVO"
# Extracción de métricas clave con jq
jq '.end.sum_sent.bits_per_second, .end.sum_received.bits_per_second, .end.sum_sent.retransmits' "$ARCHIVO"
La salida JSON incluye arrays por intervalo que permiten graficar evolución temporal del caudal, identificando patrones de throttling o inestabilidad que promedios globales ocultan.
6. Consideraciones de seguridad en entornos productivos
El modo servidor de iperf3 no requiere autenticación por diseño. Para despliegues en infraestructura compartida:
- Restringir escucha a interfaces específicas:
--bind 192.168.1.1 - Limitar duración máxima:
--server --one-offpara terminar tras una única conexión - Implementar filtrado en firewall: permitir solo rangos de administración
- Considerar
--rsa-private-key-pathpara autenticación mediante claves cuando la versión lo soporte
En entornos contenedorizados, el modo servidor funciona correctamente mapeando el puerto, aunque las métricas de red reflejarán la virtualización del stack:
docker run --rm -p 5201:5201 networkstatic/iperf3 --server