--- title: "Ajuste de TCP en Ubuntu 24.04: BBR, buffers y colas" description: "Optimiza la pila TCP de Ubuntu 24.04 con BBR, buffers mayores y colas de conexión más amplias, y mide la mejora real con iperf3, ss y nstat antes y después." category: "Optimización de Rendimiento" language: es source: https://cubepath.com/es/docs/optimización-de-rendimiento/ajuste-de-tcp-ip-para-alto-rendimiento updated: 2026-09-25 --- # Ajuste de TCP en Ubuntu 24.04: BBR, buffers y colas La configuración TCP por defecto de Linux está pensada para funcionar bien en cualquier red, no para exprimir enlaces rápidos con latencia alta ni para servidores que aceptan miles de conexiones por segundo. En este tutorial ajustarás la pila TCP de Ubuntu 24.04 en tres frentes: el algoritmo de control de congestión (BBR), el tamaño de los buffers y las colas de conexiones entrantes. Mediremos el rendimiento con `iperf3` antes y después para comprobar que cada cambio aporta algo. ## Requisitos previos - Un servidor con Ubuntu 24.04 LTS, por ejemplo un VPS de CubePath. Los parámetros son iguales en Debian 12 y Rocky Linux 9. - Un usuario no root con privilegios `sudo`. - Una segunda máquina con Linux para las pruebas de rendimiento, idealmente en otra ubicación para medir con latencia real. - Haber leído la guía de parámetros del kernel con sysctl, o saber qué hace `/etc/sysctl.d/`. ## Paso 1: Medir el rendimiento actual Instala `iperf3` en ambas máquinas. En Ubuntu, el instalador pregunta si quieres arrancarlo como servicio; responde **No**, lo lanzarás a mano: ```bash sudo apt update sudo apt install iperf3 ``` En el servidor que vas a optimizar, abre el puerto de iperf3 en el firewall y arráncalo en modo servidor: ```bash sudo ufw allow 5201/tcp iperf3 -s ``` Desde la otra máquina, primero mide la latencia y después lanza una prueba de 30 segundos. Sustituye `your_server_ip` por la IP del servidor: ```bash ping -c 10 your_server_ip iperf3 -c your_server_ip -t 30 ``` ```output [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-30.00 sec 1.12 GBytes 320 Mbits/sec 1843 sender [ 5] 0.00-30.04 sec 1.11 GBytes 318 Mbits/sec receiver ``` Repite con `-R` para medir en sentido contrario (el servidor envía, que es lo habitual en un servidor web): ```bash iperf3 -c your_server_ip -t 30 -R ``` Anota el `Bitrate` y la columna `Retr` (retransmisiones) de ambas pruebas. Detén el servidor iperf3 con `Ctrl+C` cuando termines cada tanda. Consulta también los contadores de desbordamiento de la cola de conexiones, que indican si el servidor rechaza conexiones bajo carga: ```bash nstat -az TcpExtListenOverflows TcpExtListenDrops ``` ```output #kernel TcpExtListenOverflows 0 0.0 TcpExtListenDrops 0 0.0 ``` ## Paso 2: Activar BBR y la cola fq Ubuntu 24.04 usa por defecto el control de congestión `cubic`, que reduce la velocidad al detectar pérdida de paquetes. BBR, desarrollado por Google, estima el ancho de banda y la latencia del camino y suele dar más rendimiento en enlaces con latencia alta o algo de pérdida, como las conexiones entre continentes. Comprueba el algoritmo actual y los disponibles: ```bash sysctl net.ipv4.tcp_congestion_control net.ipv4.tcp_available_congestion_control ``` ```output net.ipv4.tcp_congestion_control = cubic net.ipv4.tcp_available_congestion_control = reno cubic ``` BBR es un módulo del kernel. Cárgalo y configúralo para que se cargue en cada arranque: ```bash sudo modprobe tcp_bbr echo tcp_bbr | sudo tee /etc/modules-load.d/bbr.conf ``` Crea un archivo de configuración para los ajustes de red de este tutorial: ```bash sudo nano /etc/sysctl.d/60-tcp-tuning.conf ``` ```ini # Control de congestión BBR con la cola fq, que reparte el envío en el tiempo net.core.default_qdisc = fq net.ipv4.tcp_congestion_control = bbr ``` Aplica la configuración: ```bash sudo sysctl --system ``` `net.core.default_qdisc` solo afecta a las colas que se creen a partir de ahora. Para aplicarlo a la interfaz actual sin reiniciar, averigua su nombre y reemplaza su cola: ```bash ip route show default ``` ```output default via 203.0.113.1 dev eth0 proto static ``` ```bash sudo tc qdisc replace dev eth0 root fq ``` Verifica ambos cambios. Sustituye `eth0` por el nombre de tu interfaz: ```bash sysctl net.ipv4.tcp_congestion_control tc qdisc show dev eth0 ``` ```output net.ipv4.tcp_congestion_control = bbr qdisc fq 8001: root refcnt 2 limit 10000p flow_limit 100p buckets 1024 ... ``` ## Paso 3: Ampliar los buffers TCP El rendimiento máximo de una conexión TCP está limitado por su ventana: como mucho puede enviar el tamaño del buffer por cada viaje de ida y vuelta. Para saber cuánto buffer necesitas, calcula el producto ancho de banda por retardo (BDP): ```text BDP = ancho de banda (bytes/s) x RTT (s) 1 Gbit/s con 100 ms de RTT = 125.000.000 x 0,1 = 12,5 MB ``` Los máximos por defecto de Ubuntu 24.04 son 6 MB para recepción y 4 MB para envío, insuficientes para ese caso. Consulta los valores actuales: ```bash sysctl net.ipv4.tcp_rmem net.ipv4.tcp_wmem net.core.rmem_max net.core.wmem_max ``` ```output net.ipv4.tcp_rmem = 4096 131072 6291456 net.ipv4.tcp_wmem = 4096 16384 4194304 net.core.rmem_max = 212992 net.core.wmem_max = 212992 ``` Los tres valores de `tcp_rmem` y `tcp_wmem` son mínimo, inicial y máximo por conexión. El kernel ajusta cada conexión entre esos límites de forma automática, así que subir el máximo no reserva memoria por adelantado. `net.core.rmem_max` y `wmem_max` limitan lo que una aplicación puede pedir explícitamente con `setsockopt`. Añade al archivo `/etc/sysctl.d/60-tcp-tuning.conf`: ```ini # Buffers de hasta 64 MB por conexión (suficiente para 1-10 Gbit/s con latencia alta) net.core.rmem_max = 67108864 net.core.wmem_max = 67108864 net.ipv4.tcp_rmem = 4096 131072 67108864 net.ipv4.tcp_wmem = 4096 65536 67108864 # No volver a arranque lento tras un periodo sin tráfico en conexiones persistentes net.ipv4.tcp_slow_start_after_idle = 0 # Detectar problemas de MTU en rutas que bloquean ICMP net.ipv4.tcp_mtu_probing = 1 ``` No hace falta activar `tcp_window_scaling`, `tcp_timestamps` ni `tcp_sack`: ya vienen a `1` y el escalado de ventana es imprescindible para usar buffers de más de 64 KB. Compruébalo: ```bash sysctl net.ipv4.tcp_window_scaling net.ipv4.tcp_timestamps net.ipv4.tcp_sack ``` ## Paso 4: Ampliar las colas de conexiones entrantes Cuando llegan muchas conexiones a la vez, se encolan en dos sitios: la cola de conexiones a medio abrir (SYN recibido) y la cola de aceptación de cada socket, donde esperan hasta que la aplicación llama a `accept()`. Si se llenan, el kernel descarta conexiones y los clientes ven latencia o errores. Añade al mismo archivo: ```ini # Cola de aceptación máxima por socket (la aplicación también debe pedirla) net.core.somaxconn = 8192 # Conexiones a medio abrir pendientes de completar el handshake net.ipv4.tcp_max_syn_backlog = 8192 # Paquetes pendientes de procesar por la CPU en cada interfaz net.core.netdev_max_backlog = 16384 ``` `net.core.somaxconn` es solo un tope. Cada aplicación indica su propio backlog al abrir el socket y el kernel usa el menor de los dos. En Nginx, por ejemplo, se configura en la directiva `listen`: ```nginx listen 80 backlog=8192; ``` Comprueba el backlog real de los sockets en escucha. En sockets `LISTEN`, la columna `Send-Q` es el tamaño máximo de la cola y `Recv-Q` las conexiones que esperan en ese momento: ```bash ss -ltn ``` ```output State Recv-Q Send-Q Local Address:Port Peer Address:Port LISTEN 0 8192 0.0.0.0:80 0.0.0.0:* LISTEN 0 4096 0.0.0.0:22 0.0.0.0:* ``` ## Paso 5: Ajustar puertos locales y conexiones cerradas Estos ajustes solo importan si el servidor abre muchas conexiones salientes, por ejemplo un proxy inverso o un balanceador que conecta con backends. ```ini # Más puertos locales para conexiones salientes (por defecto 32768-60999) net.ipv4.ip_local_port_range = 10240 65535 # Reutilizar sockets en TIME_WAIT para nuevas conexiones salientes net.ipv4.tcp_tw_reuse = 1 # Liberar antes las conexiones cerradas por nuestro lado que esperan al otro extremo net.ipv4.tcp_fin_timeout = 15 ``` Algunas aclaraciones, porque es la parte con más mitos: - `tcp_fin_timeout` controla el estado `FIN_WAIT_2`, no `TIME_WAIT`. La duración de `TIME_WAIT` (60 segundos) es fija en el kernel. - `tcp_tw_reuse = 1` solo afecta a conexiones salientes y es seguro. `tcp_tw_recycle`, que aparece en guías antiguas, rompía conexiones detrás de NAT y se eliminó del kernel en la versión 4.12. - El rango de puertos empieza en 10240 para no chocar con servicios que escuchan en puertos bajos. Si algún servicio escucha en un puerto de ese rango, añádelo a `net.ipv4.ip_local_reserved_ports`. Aplica todo el archivo: ```bash sudo sysctl --system ``` ## Paso 6: Verificar la mejora Arranca de nuevo `iperf3 -s` en el servidor y repite las mismas pruebas desde la otra máquina: ```bash iperf3 -c your_server_ip -t 30 iperf3 -c your_server_ip -t 30 -R ``` ```output [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-30.00 sec 3.21 GBytes 919 Mbits/sec 212 sender [ 5] 0.00-30.04 sec 3.20 GBytes 915 Mbits/sec receiver ``` La mejora depende mucho de la latencia: en una red local casi no notarás diferencia, mientras que entre continentes BBR y los buffers mayores pueden multiplicar el rendimiento. Mientras corre la prueba `-R`, comprueba en el servidor que la conexión usa BBR y que su ventana ha crecido: ```bash ss -tin dst your_client_ip ``` ```output ESTAB 0 3145728 203.0.113.10:5201 198.51.100.20:41822 bbr wscale:10,10 rto:304 rtt:101.2/0.8 mss:1448 cwnd:1024 ... ``` Con tráfico real, vigila los desbordamientos de cola durante unos días. Si `TcpExtListenOverflows` sigue creciendo, la aplicación no acepta conexiones lo bastante rápido o su backlog es menor que `somaxconn`: ```bash nstat -az TcpExtListenOverflows TcpExtListenDrops ``` Cuando termines las pruebas, cierra el puerto de iperf3: ```bash sudo ufw delete allow 5201/tcp ``` ## Solución de problemas **`sysctl: setting key "net.ipv4.tcp_congestion_control": No such file or directory`.** El módulo `tcp_bbr` no está cargado. Ejecuta `sudo modprobe tcp_bbr` y comprueba que existe `/etc/modules-load.d/bbr.conf`. **`iperf3: error - unable to connect to server`.** El puerto 5201 está bloqueado en el firewall del servidor o en un firewall intermedio, o `iperf3 -s` no está en marcha. **El rendimiento no mejora.** Si el RTT es bajo (menos de 5 ms), los buffers por defecto ya bastan y el límite está en la tarjeta de red, la CPU o el disco. Comprueba el uso de CPU con `top` durante la prueba. ## Conclusión Has cambiado el control de congestión a BBR, ampliado los buffers TCP según el producto ancho de banda por retardo, dimensionado las colas de conexiones y medido el resultado con iperf3. Como siguientes pasos, ajusta el backlog de tu servidor web o balanceador para que aproveche el nuevo `somaxconn`, sube el límite de archivos abiertos por proceso si manejas decenas de miles de conexiones, y monitoriza las retransmisiones con `nstat` en producción.