¿Cuál es el tiempo de espera de conexión TCP predeterminado en Windows? ¿Hay una clave de registro para configurarlo o se configura dinámicamente?
¿Cuál es el tiempo de espera de conexión TCP predeterminado en Windows? ¿Hay una clave de registro para configurarlo o se configura dinámicamente?
Respuestas:
En Windows, el valor es dinámico para las conexiones establecidas , aunque el valor predeterminado para las conexiones iniciales es de 72 segundos. La configuración del Registro se define en este artículo:
http://technet.microsoft.com/en-us/library/cc739819(WS.10).aspx
HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services: \ Tcpip \ Parameters
TcpInitialRTT : define cuáles son las configuraciones iniciales de tiempo de espera para nuevas conexiones. Este número en segundos se duplica cada vez que se retransmite antes de desconectar una conexión. El valor predeterminado es 3.
TcpMaxConnectRetransmissions : define el número de retransmisiones antes de que se agote el tiempo de espera de una conexión. El valor predeterminado es 5.
Por lo general, "tiempo de espera de conexión" se refiere al tiempo de espera para crear la conexión inicial a un host. En muchos sistemas (incluido Windows 7), este valor se configura usando configuraciones separadas de los tiempos de espera para las comunicaciones en curso después de que se haya establecido una conexión. Esta respuesta aborda el escenario de "conexión inicial" para Windows 7, que es diferente de XP.
Para Windows 7, se requieren dos revisiones para admitir el ajuste de la configuración del tiempo de espera de conexión. La nueva configuración se puede configurar con el comando 'netsh'.
Del artículo de revisión 2786464:
Nota En Windows 7 y Windows Server 2008 R2, el valor de retransmisión SYN máxima de TCP (JH: MaxSynRetransmissions) se establece en 2 y no es configurable. Debido al límite de 3 segundos del valor de tiempo de espera inicial (JH: InitialRTO), el protocolo de enlace de tres vías TCP está limitado a un marco de tiempo de 21 segundos (3 segundos + 2 * 3 segundos + 4 * 3 segundos = 21 segundos )
La primera revisión agrega una configuración de 'MaxSynRetransmissions' que permite cambiar la configuración de reintento del valor predeterminado de 2. La segunda agrega la configuración 'InitialRto' que permite cambiar el valor de RTO inicial de 3000ms (sí, milisegundos), pero solo a algo más corto que 3000ms; No se puede aumentar. Dependiendo de su situación, es posible que solo necesite la revisión 'MaxSynRetransmissions'.
Instale ambas revisiones, reinicie, luego abra una ventana de comandos como Administrador. No se requieren reinicios adicionales para invocaciones de comandos netsh posteriores.
C:\Windows\system32>NET SESSION >nul 2>&1
C:\Windows\system32>IF %ERRORLEVEL% EQU 0 (ECHO Administrator PRIVILEGES Detected!) ELSE ( ECHO NOT AN ADMIN! )
Administrator PRIVILEGES Detected!
C:\Windows\system32>netsh interface tcp show global
Querying active state...
TCP Global Parameters
----------------------------------------------
Receive-Side Scaling State : enabled
Chimney Offload State : automatic
NetDMA State : enabled
Direct Cache Acess (DCA) : disabled
Receive Window Auto-Tuning Level : normal
Add-On Congestion Control Provider : none
ECN Capability : disabled
RFC 1323 Timestamps : disabled
Initial RTO : 3000
Non Sack Rtt Resiliency : disabled
Max SYN Retransmissions : 2
** The above autotuninglevel setting is the result of Windows Scaling heuristics
overriding any local/policy configuration on at least one profile.
C:\Windows\system32>cmd /v:on /c "echo !TIME! & telnet 192.168.1.254 & echo !TIME!"
14:10:30.53
Connecting To 192.168.1.254...Could not open connection to the host, on port 23: Connect failed
14:10:51.60
C:\Windows\system32>netsh interface tcp set global MaxSynRetransmissions=3
Ok.
C:\Windows\system32>netsh interface tcp show global
Querying active state...
TCP Global Parameters
----------------------------------------------
Receive-Side Scaling State : enabled
Chimney Offload State : automatic
NetDMA State : enabled
Direct Cache Acess (DCA) : disabled
Receive Window Auto-Tuning Level : normal
Add-On Congestion Control Provider : none
ECN Capability : disabled
RFC 1323 Timestamps : disabled
Initial RTO : 3000
Non Sack Rtt Resiliency : disabled
Max SYN Retransmissions : 3
** The above autotuninglevel setting is the result of Windows Scaling heuristics
overriding any local/policy configuration on at least one profile.
C:\Windows\system32>cmd /v:on /c "echo !TIME! & telnet 192.168.1.254 & echo !TIME!"
14:27:02.33
Connecting To 192.168.1.254...Could not open connection to the host, on port 23:
Connect failed
14:27:47.41
C:\Windows\system32>netsh interface tcp set global MaxSynRetransmissions=2
Ok.
C:\Windows\system32>netsh interface tcp set global InitialRto=1000
Ok.
C:\Windows\system32>netsh interface tcp show global
Querying active state...
TCP Global Parameters
----------------------------------------------
Receive-Side Scaling State : enabled
Chimney Offload State : automatic
NetDMA State : enabled
Direct Cache Acess (DCA) : disabled
Receive Window Auto-Tuning Level : normal
Add-On Congestion Control Provider : none
ECN Capability : disabled
RFC 1323 Timestamps : disabled
Initial RTO : 1000
Non Sack Rtt Resiliency : disabled
Max SYN Retransmissions : 2
** The above autotuninglevel setting is the result of Windows Scaling heuristics
overriding any local/policy configuration on at least one profile.
C:\Windows\system32>cmd /v:on /c "echo !TIME! & telnet 192.168.1.254 & echo !TIME!"
14:29:06.13
Connecting To 192.168.1.254...Could not open connection to the host, on port 23:
Connect failed
14:29:13.20
Nota: Windows Telnet se utiliza como referencia para el tiempo de espera de conexión real. Debe instalarse por separado, pero es fácil de hacer.
Enlaces / felicitaciones adicionales:
TcpInitialRTT y TcpMaxConnectRetransmissions pueden no estar presentes en Vista y Windows 2008. Este documento de Microsoft no los incluye. http://download.microsoft.com/download/c/2/6/c26893a6-46c7-4b5c-b287-830216597340/TCPIP_Reg.doc
Y esto dice que al menos TcpInitialRTT se ha ido, aunque no sé qué tan confiable es. http://pul.se/Blog-Post-TCP-IP-Stack-hardening-in-Operating-Systems-starting-with-Windows-Vista_SharePoint-kHPTTCP0WJ5,7zq00hH0wINE
Si entiendo su pregunta correctamente, se refiere a:
TcpTimedWaitDelay
Esta clave determina el tiempo que debe transcurrir antes de que TCP / IP pueda liberar una conexión cerrada y reutilizar sus recursos. Este intervalo entre el cierre y la liberación se conoce como el estado TIME_WAIT o el doble del estado de duración máxima del segmento (2MSL). Durante este tiempo, reabrir la conexión al cliente y al servidor cuesta menos que establecer una nueva conexión. Al reducir el valor de esta entrada, TCP / IP puede liberar conexiones cerradas más rápido y proporcionar más recursos para nuevas conexiones. Ajuste este parámetro si la aplicación en ejecución requiere una liberación rápida, la creación de nuevas conexiones o un ajuste debido a un bajo rendimiento causado por múltiples conexiones en el estado TIME_WAIT.
La clave exacta es: HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Tcpip \ Parameters \ TcpTimedWaitDelay
Es posible que no lo tenga configurado si está utilizando Win2008 o posterior, pero el valor predeterminado es 240 decimales (240 segundos o 4 minutos). Puede agregar la clave al registro con un valor diferente y surtirá efecto después de un reinicio (probado en Windows Server 2008R2 en un entorno de producción). Este es un valor absurdamente alto dada la calidad de las redes modernas.
Tuve una aplicación literalmente hace menos de un mes ejecutándose en un servidor que agotó la cantidad máxima de conexiones que Windows puede admitir y eliminó todos los servicios de red en ese servidor regularmente. Más de 16,000 conexiones en netstat -a cuando incluso logras RDP en el servidor. Establecimos el valor en 30 decimales (30 segundos) y listo, el problema se resolvió: menos de 10,000 conexiones simultáneas (ya que la aplicación las abría y cerraba rápidamente) y no hubo problemas de rendimiento.
TcpMaxDataRetransmissions
a 16 (se supone que el valor predeterminado es 5), pero mi PuTTY todavía deja las conexiones realmente rápidas en breves interrupciones, mientras que ssh en OS X y la misma red las mantiene bien. superuser.com/questions/529511/...