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 sudo en ambos.
  • UFW activo en el servidor, o ningún cortafuegos bloqueando el puerto 5201.

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.

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 con ss -tlnp | grep 5201.
  • unable to connect to server: Connection timed out: un cortafuegos bloquea el puerto 5201, en el servidor o en la red. Revisa sudo 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 -R y con -P 4 para ver si el problema es de un sentido o de un solo flujo, y revisa los contadores de errores de la interfaz con ip -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.