Cómo comprobar si Windows está usando auto-tuning de TCP y optimizar su rendimiento

¿Cómo comprobar si Windows está usando auto-tuning de TCP? En los últimos años muchos usuarios se han sorprendido al descubrir que su conexión a Internet no va tan rápida como debería, a pesar de tener contratado un buen ancho de banda, cables de red en buen estado y routers modernos. Cuando has comprobado todo lo «típico» (ISP, WiFi, cableado…) y la velocidad sigue sin cuadrar, toca mirar dentro de Windows.

Desde Windows Vista, el sistema incorpora una característica llamada auto-tuning de la ventana de recepción TCP (Windows Auto-Tuning) que ajusta automáticamente ciertos parámetros de red para intentar exprimir mejor la conexión. El problema es que, según la combinación de sistema operativo, drivers genéricos, routers y firewalls, puede mejorar mucho el rendimiento o, al contrario, provocar lentitud y cortes. Por eso es fundamental saber cómo comprobar si está activado, qué nivel está usando y cómo cambiarlo con seguridad.

Qué es el auto-tuning de TCP y por qué te debería importar

La pila TCP/IP de Windows utiliza una ventana de recepción TCP para almacenar los datos que van llegando antes de que la aplicación los procese. El tamaño de esa ventana es clave: si es demasiado pequeña, desperdicias ancho de banda; si es excesiva, puedes saturar equipos intermedios o provocar comportamientos extraños en ciertas redes.

La característica de auto-tuning de ventana de recepción permite que Windows vigile continuamente las condiciones de la ruta de red: ancho de banda disponible, latencia (retardo), tiempo que tarda la aplicación en leer los datos, etc. Con esa información el sistema ajusta dinámicamente el tamaño de la ventana usando el mecanismo de escala de ventana TCP (RFC 1323) para aprovechar al máximo la conexión.

En la práctica, el auto-tuning calcula el llamado producto ancho de banda-retardo (BDP). A partir de ahí decide qué tamaño de ventana es óptimo para una transferencia concreta, y lo va variando sobre la marcha para rellenar el «tubo» de datos sin dejar huecos de ancho de banda sin usar. En redes de alta velocidad y alta latencia (por ejemplo enlaces entre sedes geográficamente alejadas) esto marca una diferencia enorme de rendimiento.

Aunque la idea es muy buena, aquí viene el matiz: no todos los routers, firewalls o sistemas remotos implementan correctamente RFC 1323. Algunos dispositivos antiguos o mal configurados reaccionan mal ante tamaños de ventana grandes o a ciertas opciones TCP, provocando transferencias lentas, cortes de conexión o bloqueos de aplicaciones.

Por este motivo Microsoft decidió que, en versiones como Windows Vista, las aplicaciones que usan la interfaz WinHTTP (Windows Update, Escritorio remoto, ciertas funciones del Explorador de archivos, SharePoint vía WebDAV, etc.) no aprovechen de serie el auto-tuning, salvo que se active explícitamente mediante el Registro.

Cómo saber si Windows está usando auto-tuning de TCP

Antes de tocar nada conviene comprobar qué configuración de auto-tuning está usando tu sistema. Windows ofrece dos caminos principales: la herramienta clásica netsh en el Símbolo del sistema y los cmdlets de PowerShell.

Comprobar el auto-tuning con netsh

El método más directo en equipos cliente y servidor modernos consiste en usar netsh desde una ventana de comandos con privilegios de administrador. Esta utilidad permite consultar la configuración global de la pila TCP y, entre otras cosas, ver qué nivel de auto-tuning está activo.

Para ello abre el Símbolo del sistema (cmd) como administrador y ejecuta:

netsh interface tcp show global

Dentro de la salida del comando debes fijarte en la línea que hace referencia al «Nivel de ajuste automático de ventana de recepción» (o texto similar, cambia ligeramente según la versión de Windows). Cuando el auto-tuning está funcionando normalmente, el valor suele aparecer como «normal». Si aparece «disabled» o un valor equivalente, sabrás que el sistema no está ajustando automáticamente la ventana de recepción.

En escenarios donde se han hecho pruebas A/B, se ha visto que con autotuninglevel=normal una conexión de 1 Gbps que antes se quedaba en 50-60 Mbps puede llegar a rondar los 900-950 Mbps de bajada y cerca del máximo de subida, siempre que el resto de la infraestructura acompañe.

Comprobar el auto-tuning con PowerShell

En versiones de Windows más recientes, especialmente en entornos de servidor como Windows Server 2016/2019 y sucesivos, es muy práctico utilizar PowerShell para ver y ajustar el auto-tuning asociado a distintos perfiles TCP.

Abre PowerShell como administrador y ejecuta:

Get-NetTCPSetting | Format-List SettingName,Autotuninglevel*

Este comando muestra una lista de configuraciones TCP (por ejemplo Internet, Datacenter, Compat, etc.) junto con su propiedad AutotuninglevelLocal. Si ese valor figura como Normal, el auto-tuning está habilitado para ese perfil; si aparece como Disabled o un estado equivalente, el ajuste automático no se aplica a esas conexiones.

Si quieres forzar que todas las configuraciones usen el auto-tuning normal, puedes ejecutar algo como:

Get-NetTCPSetting | Set-NetTCPSetting -AutoTuningLevelLocal Normal

De este modo garantizas que todas las plantillas TCP (las que usan clientes, servidores y aplicaciones especiales) se beneficien del ajuste dinámico, siempre que la red y los dispositivos intermedios lo soporten.

Activar o desactivar el auto-tuning global en Windows

Si al revisar la configuración ves que el auto-tuning no está como te interesa, puedes modificar el nivel global con un solo comando. Esto es muy útil para hacer pruebas comparando rendimiento con auto-tuning activado y desactivado.

Para deshabilitarlo totalmente en la pila TCP, abre una consola de administrador (cmd) y escribe:

netsh int tcp set global autotuninglevel=disabled

Tras ejecutar el comando, es recomendable reiniciar el equipo para asegurarse de que todas las conexiones nuevas usan la nueva configuración. A partir de ese momento el sistema dejará de adaptar el tamaño de la ventana de recepción y usará valores más conservadores, lo que puede evitar problemas con routers o firewalls antiguos, a costa de sacrificar rendimiento en enlaces rápidos o de alta latencia.

Si quieres volver al comportamiento estándar de Windows, que en la mayoría de escenarios modernos suele ser la mejor opción, utiliza:

netsh int tcp set global autotuninglevel=normal

De nuevo, después del cambio conviene reiniciar y repetir las pruebas de velocidad (por ejemplo con speedtest.net u otras herramientas similares) para comprobar si la variación ha mejorado, empeorado o no ha afectado prácticamente al caudal disponible.

En muchos casos reales se ha observado que con autotuninglevel=disabled las descargas se quedan muy por debajo de lo contratado, mientras que con autotuninglevel=normal se logra acercarse mucho al máximo teórico de la línea, demostrando que la ventana de recepción estaba claramente subdimensionada cuando el ajuste automático estaba apagado.

Auto-tuning específico para WinHTTP y WinINet mediante el Registro

Además de la configuración global de la pila TCP, Windows permite controlar si el auto-tuning se aplica o no al tráfico HTTP gestionado por WinHTTP y WinINet, que son las capas usadas por muchos servicios y aplicaciones de Microsoft.

Habilitar auto-tuning para WinHTTP en Windows Vista y derivados

En Windows Vista, y en algunos escenarios heredados, el tráfico HTTP que pasa por WinHTTP (Windows Update, actualizaciones automáticas, Escritorio remoto, explorador de archivos en red usando WebDAV, SharePoint, etc.) no aprovechaba el auto-tuning de fábrica. Para activarlo debes tocar el Registro:

1. Haz clic en Inicio, escribe regedit en el cuadro de búsqueda y pulsa Intro.
2. Navega hasta la clave HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp.
3. Haz clic derecho en WinHttp, elige Nuevo y luego Valor DWORD (32 bits).
4. Llámalo TcpAutotuning y pulsa Intro.
5. Haz clic derecho sobre TcpAutotuning, selecciona Modificar y pon 1 en Información del valor.
6. Cierra el Editor del Registro y reinicia el equipo.

Cuando la entrada TcpAutotuning está presente y establecida en 1, el auto-tuning se aplica al tráfico HTTP que utiliza WinHTTP. Si el valor no existe o es distinto de 1, la función permanece desactivada para ese tipo de tráfico.

Habilitar auto-tuning para WinINet en Windows 7 y sistemas posteriores

En Windows 7 y sucesores, el componente WinINet (usado por aplicaciones como Internet Explorer, y por otras basadas en sus librerías) también puede controlarse mediante el Registro para aprovechar o no el auto-tuning.

Los pasos son muy parecidos:

1. Abre regedit como administrador.
2. Ve a HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings.
3. Crea un nuevo valor DWORD llamado TcpAutotuning y asígnale el valor 1.
4. Repite el mismo proceso en la clave de 32 bits sobre sistemas de 64 bits: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Internet Settings.
5. Cierra el editor y reinicia el equipo.

En este caso WinINet estará usando el auto-tuning solo cuando ambas entradas TcpAutotuning tengan valor 1. Si no existen o tienen un valor diferente, el componente se comportará como si el ajuste automático no estuviese permitido para su tráfico.

Cuándo puede dar problemas el auto-tuning de TCP

Aunque sobre el papel el auto-tuning es una mejora clara, en entornos reales no siempre es así. Hay redes donde, al habilitarlo, se producen transferencias de datos muy lentas o incluso pérdida intermitente de conectividad. Esto suele ocurrir cuando en el camino hay:

• Routers antiguos que no implementan correctamente RFC 1323.
• Firewalls viejos que no entienden las opciones avanzadas de TCP o las bloquean a medias.
• Sistemas operativos remotos obsoletos con pilas de red limitadas.

En estos escenarios, al activar el ajuste automático, el equipo local empieza a aumentar el tamaño de la ventana de recepción para aprovechar mejor la conexión, pero el dispositivo intermedio no soporta adecuadamente ese funcionamiento. Como resultado, pueden aparecer síntomas como páginas web que cargan a trompicones, descargas que nunca terminan, aplicaciones que se quedan «colgadas» o interrupciones frecuentes de la sesión (por ejemplo, en Escritorio remoto).

Si los dispositivos problemáticos están fuera de tu organización (por ejemplo, routers de tu proveedor de Internet o infraestructura de un tercero), puede que no tengas margen para actualizarlos o reconfigurarlos. En ese caso, la solución práctica pasa por deshabilitar el auto-tuning en tus equipos para recuperar estabilidad, aceptando un posible sacrificio de rendimiento.

Cuando la causa está en tu propia red (routers o firewalls corporativos, appliances, balanceadores, etc.), lo recomendable es consultar con el fabricante y revisar si existe firmware actualizado o configuraciones específicas que permitan trabajar correctamente con ventanas TCP escaladas.

Otros factores de rendimiento TCP relacionados (RSS, VMQ y bucle invertido)

El auto-tuning no es el único parámetro que puede hacer que una conexión rápida vaya como un tiro o, al contrario, parezca una línea mucho más lenta. Windows incorpora otras funciones como RSS (Receive Side Scaling), VMQ (Virtual Machine Queue) y optimizaciones del bucle invertido TCP que influyen de forma notable en el rendimiento.

Rendimiento en redes de alta latencia y alto ancho de banda

Cuando tienes dos servidores separados geográficamente, unidos por un enlace de alta capacidad pero con bastante latencia, es muy frecuente observar que el rendimiento medido con herramientas como ctsTraffic se queda muy por debajo de la línea base esperada. En muchos casos el motivo es tan simple como que la opción de escala de ventanas TCP no está habilitada porque el auto-tuning permanece desactivado.

En ese tipo de enlaces, sin auto-tuning el tamaño de la ventana de recepción se queda muy pequeño comparado con el ancho de banda disponible, por lo que solo se aprovecha una fracción de la capacidad real del enlace. Habilitando el ajuste automático con:

netsh int tcp set global autotuninglevel=normal

o mediante PowerShell con:

Get-NetTCPSetting | Set-NetTCPSetting -AutoTuningLevelLocal Normal

los servidores empiezan a llenar el «túnel» de datos de forma mucho más efectiva, lo que se refleja en un aumento muy notable del caudal útil en las pruebas.

Rendimiento en redes de baja latencia y alto ancho de banda: RSS y VMQ

En el caso contrario, cuando la red tiene baja latencia pero mucho ancho de banda (por ejemplo dentro de un CPD con switches 10/25/40 Gbps), puedes encontrarte con que el procesador apenas se mueve de la CPU 0 mientras el resto de núcleos están prácticamente ociosos. Esto provoca que el rendimiento global de TCP se quede muy corto respecto a lo que debería.

Este comportamiento suele deberse a que la característica Receive Side Scaling (RSS) o la Virtual Machine Queue (VMQ) no están habilitadas o configuradas correctamente. En servidores físicos que actúan como hipervisores conviene usar VMQ; en máquinas que no virtualizan, lo ideal es activar RSS tanto en el sistema operativo como en las tarjetas de red.

Para habilitar RSS desde una consola de administrador puedes usar:

netsh int tcp set global rss=enabled

Y en PowerShell, ajustando los adaptadores de red concretos:

Set-NetAdapterRss -Name <nombre_interfaz> -Enabled $True

También es importante revisar las propiedades avanzadas de la tarjeta de red. Desde PowerShell:

Get-NetAdapterAdvancedProperty | Where-Object -property RegistryKeyword -Like *rss* | Format-Table -AutoSize

o mediante la interfaz gráfica (ncpa.cpl, propiedades de la conexión, botón Configurar, pestaña Avanzadas, y buscar la opción «Escalado lateral de recepción»). Si fuera necesario se puede habilitar RSS con:

Set-NetAdapterAdvancedProperty -Name <nombre_interfaz> -RegistryKeyword *RSS -RegistryValue 1

Mejoras de bucle invertido TCP en Windows Server 2019

A partir de Windows Server 2019 Microsoft revisó el modelo de procesamiento de bucle invertido TCP/IP para reducir cuellos de botella en comunicaciones en las que el tráfico no sale realmente del equipo (cliente y servidor en la misma máquina). Cuando una aplicación se comunica con otra usando TCP loopback (127.0.0.1 o ::1), el rendimiento puede ser crítico.

Se añadieron varios parámetros configurables vía netsh para IPv4 e IPv6, como:

netsh int ipv4|ipv6 set global loopbackexecutionmode=adaptive|inline|worker
netsh int ipv4|ipv6 set global loopbackworkercount=<valor>
netsh int ipv4|ipv6 set global loopbacklargemtu=enable|disable

Los modos disponibles permiten elegir entre dar prioridad a la baja latencia (modo Inline, donde el procesamiento se hace en los hilos de la aplicación), maximizar el rendimiento bruto (modo Worker, con colas y subprocesos dedicados) o buscar un punto intermedio (modo Adaptive, que empieza en línea y luego delega en hilos de trabajo).

Parámetros como loopbackworkercount permiten ajustar el número de subprocesos de trabajo usados para procesar tráfico en bucle invertido, y loopbacklargemtu habilita o deshabilita el uso de MTU grandes para reducir overhead cuando todo el tráfico se mantiene dentro del propio host.

Cómo detectar problemas de red subyacentes que afectan a TCP

En ocasiones el auto-tuning está bien configurado, RSS y VMQ también, pero el rendimiento de TCP sigue siendo deficiente. En estos casos compensa bajar al detalle de los paquetes con herramientas de captura de tráfico como Microsoft Network Monitor, Wireshark o la propia capacidad de tracing integrada en Windows.

Capturar tráfico para analizar retransmisiones y pérdidas

Para obtener registros de bajo nivel puedes:

1. Iniciar una captura en ambos extremos de la conexión con Network Monitor o Wireshark, o usar el trazado integrado de Windows desde una consola de administrador:

   NETSH TRACE START CAPTURE=YES REPORT=DISABLED TRACEFILE=<ruta_archivo>.etl MAXSIZE=512

2. Lanzar una prueba con ctsTraffic u otra herramienta que genere tráfico TCP controlado y produzca un archivo .csv con estadísticas.
3. Detener el registro con:

   NETSH TRACE STOP

Una vez capturado el tráfico, se puede abrir el archivo en Network Monitor, filtrar por retransmisiones TCP (por ejemplo usando Property.TCPRetransmit==1 && tcp.Port==4444) y localizar marcos que se envían varias veces sin recibir confirmación.

Si al comparar las capturas de cliente y servidor ves que ciertos paquetes salen del emisor pero nunca llegan al receptor, tienes una indicación clara de que hay pérdida en algún dispositivo intermedio (router, switch, firewall, enlace inalámbrico, etc.). En estos casos, más que tocar parámetros como auto-tuning, RSS o VMQ, lo que procede es escalar el problema al equipo de red para que revise la infraestructura.

Puertos TCP, herramientas netstat y seguridad en Windows

Todo lo anterior se apoya en la base de cómo funcionan los puertos TCP y UDP en la capa de transporte. Cada conexión se asocia a un par de puertos (origen y destino) que indican qué aplicación está hablando con cuál. En Windows, además de los puertos físicos (Ethernet, USB, etc.), existen puertos lógicos numerados que se usan para servicios concretos (HTTP en el 80, HTTPS en el 443, etc.).

Para diagnosticar conflictos de puertos o ver qué procesos están ligados a un puerto específico, Windows ofrece la herramienta netstat. Por ejemplo, para saber qué proceso está usando el puerto 8080 en Windows puedes ejecutar:

netstat -nao | findstr 8080

La salida mostrará las conexiones y sockets en escucha, indicando la dirección local, el puerto y el PID del proceso. A partir de ese PID podrás ir al Administrador de tareas o a herramientas más avanzadas para identificar de qué aplicación se trata.

En entornos Linux el equivalente típico sería algo como netstat -nepal | grep 8080, mientras que en AIX o Solaris hay comandos adicionales (rmsock, pfiles, etc.) para llegar desde el socket hasta el proceso. El objetivo en todos los casos es el mismo: averiguar quién está atando un puerto concreto para evitar conflictos y diagnosticar problemas.

En Windows 10 y 11 también es posible listar todos los puertos y conexiones activas con:

netstat -ab

Este comando puede tardar unos minutos y muestra, para cada conexión, el ejecutable asociado y los puertos que está usando. Los sockets con estado LISTENING indican puertos en escucha, mientras que los conectados reflejan comunicaciones activas. Es una herramienta muy útil para detectar servicios inesperados o aplicaciones que están exponiendo puertos que no deberían.

Para quien prefiera herramientas gráficas, existen utilidades como TCPView o CurrPorts que muestran en una interfaz amigable todos los procesos que utilizan la red, los puertos locales y remotos, los protocolos y el estado de cada conexión. Desde ellas incluso se pueden cerrar conexiones concretas, terminar procesos o generar informes detallados.

Controlar los puertos abiertos resulta esencial no solo para el rendimiento, sino también para la seguridad. Cada puerto escuchando es una posible puerta de entrada para malware, troyanos, ataques de fuerza bruta o barridos automáticos desde Internet. Por eso Windows combina estas herramientas de diagnóstico con mecanismos como el Firewall de Windows, políticas de seguridad, antivirus y antimalware integrados.

Al final, entender cómo funciona el auto-tuning de TCP, cómo comprobar su estado y cómo se relaciona con otros elementos de la pila de red (RSS, VMQ, bucle invertido, puertos abiertos, firewall, etc.) te permite tener un control mucho más fino sobre la conexión: puedes exprimir al máximo las líneas rápidas cuando la infraestructura lo soporta, o priorizar estabilidad y compatibilidad cuando hay hardware antiguo en medio, todo ello sabiendo qué cambios haces, cómo medir su impacto y cómo deshacerlos si no te convencen.