tutorial de iperf3: Medir el rendimiento de la red en Linux y Windows

iperf3 es una herramienta de línea de comandos para medir el ancho de banda de la red, el jitter y la pérdida de paquetes entre dos máquinas. Utiliza un modelo cliente-servidor: una máquina escucha, la otra envía tráfico, y se obtienen cifras precisas de rendimiento. Esta guía cubre la instalación, las pruebas básicas y avanzadas y cómo ajustar el sistema para obtener resultados precisos en enlaces de alta velocidad.

Instalación de iperf3

Debian / Ubuntu

sudo apt update
sudo apt install iperf3

Confirme la instalación con iperf3 --version. Instálelo tanto en el servidor como en las máquinas cliente.

Fedora / CentOS / Rocky / Alma

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

sudo dnf install iperf3

En CentOS 7, utilice yum en su lugar. Si no encuentra el paquete, active primero el repositorio EPEL:

sudo yum install epel-release
sudo yum install iperf3

Si su cortafuegos está activo, abra el puerto 5201:

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

Windows

Descarga el ejecutable independiente de iperf.fr o del repositorio GitHub ar51an/iperf3-win-builds. Extráelo a una carpeta como C:\iperf3 y, a continuación, verifícalo:

cd C:\iperf3
iperf3.exe -v

Para ejecutar iperf3 desde cualquier directorio, añada la carpeta a su PATH del sistema a través de Propiedades del sistema > Avanzadas > Variables de entorno. También tendrá que crear una regla de firewall de entrada que permita TCP en el puerto 5201 en el Firewall de Windows Defender.

Configuración del servidor

Inicie el servidor con:

iperf3 -s

Este escucha en el puerto TCP 5201 por defecto. Para ejecutarlo en segundo plano con registro:

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

Compruebe que se está ejecutando con ss -tulpn | grep 5201.

Si el puerto 5201 está bloqueado en su red, utilice -p para elegir un puerto diferente. Para enlazar con una interfaz específica, utilice -B:

iperf3 -s -B 192.168.1.10

Para pruebas puntuales, iperf3 -s -1 gestiona una única conexión de cliente y luego sale. En enlaces de gran ancho de banda (40 Gbps o más), ejecute varias instancias de servidor en diferentes puertos para evitar los límites de CPU de un solo hilo.

Asegúrese de que su cortafuegos permite el tráfico en el puerto elegido. En Ubuntu/Debian con UFW:

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

Ejecución de pruebas de cliente

Prueba TCP básica

iperf3 -c 192.168.1.10

Mide el ancho de banda de subida a través de TCP durante 10 segundos. Amplíe la duración con -t:

iperf3 -c 192.168.1.10 -t 30

En enlaces de 10 Gbps o 25 Gbps, un único flujo TCP suele alcanzar un máximo de 3-5 Gbps debido a los límites de la CPU de un solo núcleo. Utilice flujos paralelos para saturar el enlace:

iperf3 -c 192.168.1.10 -P 8

Lectura de los resultados

Cada línea de intervalo muestra Transfer (datos enviados) y Bitrate (rendimiento). Para TCP, observa también

• Retr (retransmisiones). Los números altos significan pérdida de paquetes o congestión.
• Cwnd (ventana de congestión). Si es baja o está atascada, los límites de tamaño del búfer o de la ventana están limitando el rendimiento.

En un enlace limpio de 1 Gbps, se esperan unos 940 Mbps después de la sobrecarga del protocolo. La prueba termina con las líneas de resumen del emisor y el receptor. En una red estable, deberían coincidir.

Para las pruebas UDP( indicador-u ), la salida añade jitter (varianza de llegada de paquetes) y datagramas perdidos/totales. Un jitter inferior a 1 ms y una pérdida del 0% es ideal para tráfico en tiempo real como VoIP.

Indicadores útiles

Pruebas avanzadas

Pruebas bidireccionales

La opción --bidir (iperf3 3.7+) comprueba simultáneamente la carga y la descarga:

iperf3 -c 192.168.1.10 --bidir

Ambas conexiones se originan en el cliente, por lo que funciona a través de NAT sin necesidad de abrir puertos adicionales. Si los resultados bidireccionales son mucho más bajos que los de las pruebas unidireccionales, es posible que su router o módem por cable tenga problemas con el tráfico full-duplex.

Modo inverso

La opción -R invierte el flujo de datos, de modo que el servidor envía y el cliente recibe. Así se mide la velocidad de descarga sin intercambiar los papeles:

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

Las grandes diferencias entre los resultados hacia delante y hacia atrás indican rutas asimétricas, congestión o errores de configuración del búfer.

Pruebas UDP

Las pruebas UDP revelan el jitter y la pérdida de paquetes, que TCP oculta tras las retransmisiones. Establezca siempre un ancho de banda objetivo con -b, ya que iperf3 establece por defecto 1 Mbps para UDP:

iperf3 -c 192.168.1.10 -u -b 1G

Para simular tráfico VoIP (100 llamadas, paquetes de 200 bytes):

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

Puntos de referencia de calidad: un jitter inferior a 5 ms es bueno para VoIP, más de 30 ms causa problemas audibles. La pérdida de paquetes superior al 0,1% degrada notablemente los medios en tiempo real.

Puesta a punto y resolución de problemas

Problemas comunes

¿Sólo obtiene 100 Mbps en un enlace gigabit? Compruebe la velocidad de su interfaz física con ethtool eth0. La autonegociación a veces falla y deja el enlace a una velocidad inferior.

¿El MSS muestra 536 bytes en Ethernet? Es probable que Path MTU Discovery esté desactivado. La MSS por defecto para una MTU de 1.500 bytes es de 1.460 bytes. Utilice -m durante las pruebas para comprobarlo. Un MSS de 536 bytes desperdicia ancho de banda y añade sobrecarga.

¿La CPU está al máximo en enlaces rápidos? Utilice -Z (zerocopy) para reducir la carga de la CPU. Para más de 40 Gbps, ejecute varias instancias de servidor en diferentes puertos y distribúyalas entre los núcleos de la CPU.

¿Resultados incoherentes? Utilice -O 3 para omitir los primeros segundos mientras la ventana de congestión TCP aumenta. Deje 30 segundos entre las pruebas para limpiar los búferes de red.

¿Un único flujo es mucho más lento que los flujos paralelos combinados? Si un flujo obtiene 200 Mbps pero ocho flujos combinados alcanzan 1,6 Gbps, la ventana TCP o los búferes del sistema operativo están limitando el flujo único. Ajuste los búferes a continuación.

Ajuste del búfer TCP

Empiece calculando el producto ancho de banda-retardo: ancho de banda x RTT. Un enlace de 10 Gbps con un RTT de 50 ms da un BDP de 62,5 MB. Establece tu búfer máximo en al menos 2 veces el BDP.

Añada esto a /etc/sysctl.d/99-tcp-tuning.conf y aplíquelo con sudo sysctl -p:

Mantén net.ipv4.tcp_moderate_rcvbuf a 1 para que el kernel se autoajuste dentro de estos rangos. Activa net.ipv4.tcp_window_scaling (a 1) para ventanas TCP mayores de 64 KB.

También puede cambiar del algoritmo de congestión CUBIC por defecto al BBR de Google. En enlaces de alta latencia con cierta pérdida de paquetes, BBR ofrece sistemáticamente un mayor rendimiento que CUBIC.

Utilice el indicador -w en iperf3 para probar tamaños de búfer específicos, pero tenga en cuenta que no pueden superar los valores rmem_max o wmem_max del núcleo. Empieza con 8 MB para enlaces gigabit, 512 KB para 100 Mbps.

Si está aprovisionando servidores dedicados y desea validar el rendimiento de la red, ejecute las pruebas de referencia de iperf3 justo después de la configuración y después de cualquier cambio en la red para detectar regresiones a tiempo.

Recomendación de vídeo