--- title: "Cómo medir el ancho de banda con iperf3 en Ubuntu 24.04" description: "Mide el ancho de banda TCP y UDP entre dos servidores Ubuntu 24.04 con iperf3: pruebas en ambos sentidos, flujos paralelos, jitter, pérdida y salida JSON." category: "Rendimiento y Benchmarking" language: es source: https://cubepath.com/es/docs/rendimiento-y-benchmarking/pruebas-de-rendimiento-de-red-con-iperf3 updated: 2026-09-25 --- # Cómo medir el ancho de banda con iperf3 en Ubuntu 24.04 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. > Nota: iperf3 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: ```bash 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: ```bash iperf3 --version ``` ```output 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`): ```bash 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: ```bash sudo ufw status ``` ```output 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: ```bash iperf3 -s ``` ```output ----------------------------------------------------------- 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: ```bash iperf3 -c your_server_ip ``` ```output 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: ```bash 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: ```bash 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`: ```bash 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: ```bash iperf3 -c your_server_ip -P 4 -t 30 -O 3 ``` ```output [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: ```bash iperf3 -c your_server_ip -u -b 200M -t 20 ``` ```output [ 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. > Advertencia: una 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: ```bash sudo apt install jq ``` Lanza una prueba TCP y guarda el resultado: ```bash iperf3 -c your_server_ip -t 30 -O 3 -J > tcp-$(date +%F).json ``` Extrae el caudal recibido en Mbit/s: ```bash jq '.end.sum_received.bits_per_second / 1e6' tcp-$(date +%F).json ``` ```output 938.472116 ``` Para una prueba UDP, los datos están en `.end.sum`: ```bash 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 ``` ```output { "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: ```bash 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.