Ciclo de vida de las conexiones TCP en Windows 11 25H2

Respuesta breve

Estos parámetros controlan el ciclo de vida de la conexión TCP: extensiones del protocolo, TIME_WAIT, keep-alive y detección de problemas de Path MTU. No establecen el ping ni aceleran una conexión ya establecida.

Qué se comprobó

Se comprobó cómo tcpipreg.sys y NSI leen los parámetros del ciclo de vida de TCP, qué valores predeterminados y rangos están en vigor y si la configuración se actualiza sin reinicio.

Ámbito del estudio

Windows 11 25H2 build 26200.9168, tcpipreg.sys y NSI. No se realizó una captura controlada de trazas de red en distintas redes y aplicaciones.

Metodología

Análisis estático de los componentes del sistema, análisis del bootlog y observación de la actualización de la configuración en vivo.

Valores canónicos

Registry path	Value	Type	Default/estado típico	Rol
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters	Tcp1323Opts	REG_DWORD	3, si está ausente	legacy extensions policy
la misma ruta	TcpTimedWaitDelay	REG_DWORD	120 segundos, 30..300	TIME_WAIT duration
la misma ruta	KeepAliveTime	REG_DWORD	7200000 ms	idle keep-alive interval
la misma ruta	EnablePMTUBHDetect	REG_DWORD	0	PMTU black-hole detection

Los parámetros TCP obsoletos los lee tcpipreg.sys y los transmite a través de NSI al componente tcpip.sys. Para parte de los valores se utiliza ZwNotifyChangeKey, lo que permite releer la configuración sin un reinicio completo de la pila de red.

Valores

Tcp1323Opts se conserva por compatibilidad. Sus valores 0..3 describían históricamente el escalado de la ventana TCP y las marcas de tiempo. En Windows 11 25H2 el parámetro lo lee tcpipreg.sys, y además el valor 1 se transforma antes de transmitirse a NSI. La configuración automática moderna de la ventana de recepción se rige por una política aparte. Por eso la antigua tabla de bits no determina el estado real de cada conexión.

TcpTimedWaitDelay define el tiempo que se retiene el bloque de control TCP en TIME_WAIT tras cerrar la conexión. El rango documentado es de 30..300 segundos, el valor predeterminado es 120. Reducir la espera libera antes los puertos temporales, pero deja menos tiempo para protegerse frente a segmentos tardíos de la conexión antigua.

KeepAliveTime define el intervalo hasta el paquete de comprobación keep-alive para una conexión inactiva. De forma predeterminada es de 7 200 000 ms. La aplicación debe habilitar por separado el keep-alive para el socket, por lo que reducir el intervalo global no inicia comprobaciones en segundo plano de todas las conexiones.

EnablePMTUBHDetect=1 habilita la detección de «agujeros negros» de Path MTU, cuando las notificaciones ICMP sobre la necesidad de fragmentación no llegan al emisor. El mecanismo ayuda a trabajar con esa ruta problemática y puede aumentar el número de retransmisiones. No acelera una red que funciona correctamente.

Utilidad y limitaciones

Los parámetros son útiles para servidores y clientes con un gran número de conexiones TCP cortas o con MTU inestable. No hay que esperar una aceleración universal de las aplicaciones habituales por cambiar un solo valor. El resultado depende de la otra parte de la conexión, el NAT, el enrutador, el controlador de la tarjeta de red, la VPN y el control de congestión.

El estudio se refiere a Windows 11 25H2 build 26200.9168. No se realizó una captura controlada de trazas de red en distintas redes y aplicaciones.

tcpipreg.sys supervisa los cambios de la clave y puede actualizar parte de los ajustes obsoletos sin reinicio. Las conexiones TCP ya abiertas no necesariamente renegocian sus parámetros. Para comparar correctamente el estado inicial y el modificado, cree conexiones nuevas.

Qué está confirmado

• Las rutas, los tipos, los valores predeterminados y los rangos de los parámetros en la build estudiada.
• La lectura a través de tcpipreg.sys y NSI; parte de los valores se actualiza sin un reinicio completo de la pila.
• Para Tcp1323Opts el valor 1 se transforma antes de transmitirse a NSI.
• El keep-alive requiere una habilitación aparte para el socket.

Qué no está confirmado

• La aceleración de aplicaciones por cambiar valores concretos.
• El comportamiento en redes concretas, detrás de NAT, VPN y con pérdidas de paquetes.
• La renegociación de parámetros por conexiones ya abiertas.

Conclusión práctica

Deje los valores predeterminados. Cambie los parámetros solo para servidores y clientes con un gran número de conexiones cortas o con MTU inestable y compare el resultado en conexiones nuevas.

Restauración del estado

Devuelva los valores originales o elimine las entradas opcionales. Compruebe el resultado en conexiones nuevas: las ya abiertas pueden conservar los parámetros anteriores.

Fuentes

Para saber cómo reproducir la parte dinámica de las observaciones, consulte Cómo comprobarlo por su cuenta.

El estudio y las herramientas utilizadas pertenecen al desarrollador de BoosterX, por lo que el desarrollador tiene un interés directo en los resultados. La metodología y los límites de aplicabilidad se describen arriba, y las conclusiones pueden verificarse con los datos abiertos y las fuentes públicas enumeradas.

• TCP/IP registry values, Microsoft Learn, comprobado el 2026-09-01.
• TCP/IP performance tuning, Microsoft Learn, comprobado el 2026-09-01.

Fuentes públicas comprobadas: 2026-09-02.

Historial de cambios

• 2026-09-20: añadido el descargo de responsabilidad sobre el conflicto de intereses y el enlace a la comprobación independiente de las observaciones dinámicas en la metodología.
• 2026-09-02: primera publicación; confirmados los readers, defaults y live reload, añadidos los límites del efecto práctico.