iperf3 mide el caudal máximo que puede transportar la red entre dos equipos, ya sea por TCP o por UDP. Uno de los equipos actúa como servidor y el otro como cliente que genera el tráfico. En este tutorial instalarás iperf3 en dos servidores Ubuntu 24.04, medirás el ancho de banda en ambos sentidos, probarás UDP para ver jitter y pérdida de paquetes, y guardarás los resultados en JSON.
Requisitos previos
- Dos servidores con Ubuntu 24.04 LTS, por ejemplo dos VPS de CubePath. En esta guía se llaman servidor (recibe las conexiones, IP
your_server_ip) y cliente (lanza las pruebas). - Un usuario no root con privilegios
sudoen ambos. - UFW activo en el servidor, o ningún cortafuegos bloqueando el puerto 5201.
Notaiperf3 mide el camino completo entre los dos equipos. Si el cliente es tu ordenador de casa, el resultado estará limitado por tu conexión, no por el servidor. Para medir la red de un servidor, usa como cliente otra máquina con buena conectividad.
Paso 1: Instalar iperf3 en ambos servidores
Ejecuta en los dos equipos:
sudo apt update
sudo apt install iperf3
Durante la instalación, el paquete pregunta si quieres arrancar iperf3 como demonio al iniciar el sistema. Responde No: solo lo necesitas mientras haces pruebas y no conviene dejar el puerto abierto de forma permanente.
Comprueba la versión:
iperf3 --version
iperf 3.16 (cJSON 1.7.15)
Paso 2: Abrir el puerto en el servidor
iperf3 escucha por defecto en el puerto 5201 y usa TCP para el control y los datos, y UDP para las pruebas UDP. En el servidor, permite ese puerto solo desde la IP del cliente (your_client_ip):
sudo ufw allow from your_client_ip to any port 5201 proto tcp
sudo ufw allow from your_client_ip to any port 5201 proto udp
Comprueba que las reglas están activas:
sudo ufw status
To Action From
-- ------ ----
5201/tcp ALLOW your_client_ip
5201/udp ALLOW your_client_ip
Paso 3: Iniciar iperf3 en modo servidor
En el servidor, lanza iperf3 en primer plano:
iperf3 -s
-----------------------------------------------------------
Server listening on 5201 (test #1)
-----------------------------------------------------------
El proceso queda esperando conexiones. Déjalo en esa terminal y trabaja desde el cliente. Un servidor iperf3 atiende una sola prueba a la vez; si quieres que termine tras la primera prueba, añade -1 (iperf3 -s -1).
Paso 4: Medir el ancho de banda TCP
En el cliente, lanza una prueba de 10 segundos hacia el servidor:
iperf3 -c your_server_ip
Connecting to host your_server_ip, port 5201
[ 5] local 198.51.100.20 port 49812 connected to your_server_ip port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 112 MBytes 938 Mbits/sec 0 3.05 MBytes
[ 5] 1.00-2.00 sec 112 MBytes 941 Mbits/sec 0 3.05 MBytes
...
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 1.10 GBytes 941 Mbits/sec 4 sender
[ 5] 0.00-10.00 sec 1.09 GBytes 938 Mbits/sec receiver
Cómo leer el resultado:
- Bitrate en la línea
receiver: el caudal real que llegó al servidor. Es la cifra que debes anotar. - Retr: segmentos TCP retransmitidos. Unos pocos son normales; cientos o miles indican pérdida o congestión en el camino.
- Cwnd: ventana de congestión. Si se queda pequeña en enlaces de alta latencia, limita el caudal.
En un enlace de 1 Gbps, unos 940 Mbits/s es el máximo práctico por la sobrecarga de las cabeceras Ethernet, IP y TCP.
Para una medida más estable, alarga la prueba a 30 segundos y descarta los 3 primeros, en los que TCP todavía está acelerando:
iperf3 -c your_server_ip -t 30 -O 3
Paso 5: Probar el sentido inverso y ambos sentidos a la vez
Por defecto el cliente envía y el servidor recibe, es decir, mides la subida del cliente. Con -R el servidor envía y el cliente recibe:
iperf3 -c your_server_ip -R
Las diferencias grandes entre un sentido y otro apuntan a enlaces asimétricos, limitación de tráfico en uno de los lados o rutas distintas de ida y vuelta.
Para enviar en los dos sentidos al mismo tiempo, como ocurre en una replicación o una VPN, usa --bidir:
iperf3 -c your_server_ip --bidir
La salida muestra por separado las líneas marcadas [TX-C] (del cliente al servidor) y [RX-C] (del servidor al cliente).
Paso 6: Usar flujos paralelos
Un solo flujo TCP puede quedarse por debajo de la capacidad del enlace, sobre todo en enlaces de 10 Gbps o con latencia alta. Con -P abres varios flujos simultáneos:
iperf3 -c your_server_ip -P 4 -t 30 -O 3
[SUM] 0.00-30.00 sec 32.6 GBytes 9.34 Gbits/sec 215 sender
[SUM] 0.00-30.00 sec 32.6 GBytes 9.33 Gbits/sec receiver
La línea [SUM] suma todos los flujos. Si con 4 flujos obtienes bastante más que con uno, el límite estaba en el flujo individual (CPU de un núcleo o ventana TCP) y no en la red. Desde iperf3 3.16, cada flujo se ejecuta en su propio hilo, así que aprovecha varios núcleos.
Paso 7: Medir jitter y pérdida con UDP
UDP no tiene control de congestión: iperf3 envía exactamente al ritmo que le indiques con -b y mide cuántos paquetes llegan. Es la prueba adecuada para evaluar tráfico de voz, vídeo o juegos. Empieza por un caudal moderado:
iperf3 -c your_server_ip -u -b 200M -t 20
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-20.00 sec 477 MBytes 200 Mbits/sec 0.000 ms 0/345354 (0%) sender
[ 5] 0.00-20.00 sec 477 MBytes 200 Mbits/sec 0.012 ms 12/345354 (0.0035%) receiver
- Jitter: variación del retardo entre paquetes, medida en el receptor. Por debajo de 1 ms es excelente para tiempo real.
- Lost/Total Datagrams: pérdida real de paquetes al caudal indicado.
Sube el caudal (-b 500M, -b 900M...) hasta que la pérdida empiece a crecer: ese es el caudal UDP sostenible. Sin -b, iperf3 envía UDP a solo 1 Mbit/s, así que indica siempre el caudal.
Advertenciauna prueba UDP a un caudal superior al del enlace satura la red de ambos extremos. No la lances contra servidores de terceros ni en horas de tráfico real.
Paso 8: Guardar los resultados en JSON
Con -J, iperf3 genera un informe JSON completo, útil para comparar ejecuciones o procesarlo en scripts. Instala jq en el cliente para consultarlo:
sudo apt install jq
Lanza una prueba TCP y guarda el resultado:
iperf3 -c your_server_ip -t 30 -O 3 -J > tcp-$(date +%F).json
Extrae el caudal recibido en Mbit/s:
jq '.end.sum_received.bits_per_second / 1e6' tcp-$(date +%F).json
938.472116
Para una prueba UDP, los datos están en .end.sum:
iperf3 -c your_server_ip -u -b 200M -t 20 -J > udp.json
jq '{jitter_ms: .end.sum.jitter_ms, lost_percent: .end.sum.lost_percent}' udp.json
{
"jitter_ms": 0.0123,
"lost_percent": 0.0035
}
Paso 9: Cerrar el puerto al terminar
Detén el servidor con Ctrl+C y elimina las reglas de UFW que añadiste:
sudo ufw delete allow from your_client_ip to any port 5201 proto tcp
sudo ufw delete allow from your_client_ip to any port 5201 proto udp
Solución de problemas
unable to connect to server: Connection refused: iperf3 no está corriendo en el servidor o escucha en otro puerto. Comprueba conss -tlnp | grep 5201.unable to connect to server: Connection timed out: un cortafuegos bloquea el puerto 5201, en el servidor o en la red. Revisasudo ufw status.the server is busy running a test. try again later: otra prueba está en curso. El servidor solo atiende una a la vez.- Caudal bajo con muchas retransmisiones: repite la prueba con
-Ry con-P 4para ver si el problema es de un sentido o de un solo flujo, y revisa los contadores de errores de la interfaz conip -s link show.
Conclusión
Ya sabes medir el ancho de banda TCP en ambos sentidos, detectar si un flujo único es el cuello de botella y evaluar jitter y pérdida con UDP, además de guardar resultados en JSON. Como siguientes pasos, puedes repetir las pruebas entre servidores de distintas ubicaciones para comparar latencia y caudal, complementar iperf3 con mtr para localizar en qué salto se produce la pérdida, o medir el disco con fio para tener una visión completa del rendimiento del servidor.
