Which is the default TCP connect timeout in Windows?

Question

Which is the default TCP connect timeout in Windows? There is a registry key to configure it or it's set dynamically?

Answer 1

In Windows the value is dynamic for established conections, though the default for initial connections is 72 seconds. The Registry settings are defined in this article:

http://technet.microsoft.com/en-us/library/cc739819(WS.10).aspx

HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services: \Tcpip \Parameters

TcpInitialRTT: Defines what the initial time-out settings are for new connections. This number in seconds is doubled each time it retransmits before timing a connection out. Defaults to 3.

TcpMaxConnectRetransmissions: Defines the number of retransmissions while establishing the connection before timing a connection out. Defaults to 2.

Answer 2

Usually "connect timeout" refers to the timeout for creating the initial connection to a host. In many systems (Windows 7 included), this value is configured using separate settings from timeouts for ongoing communications after a connection has been established. This answer addresses the "initial connect" scenario for Windows 7, which is different from XP.

For Windows 7, two hotfixes are required to support adjusting connect timeout settings. The new settings can be configured with the 'netsh' command.

• Hotfix #2786464: Hotfix enables the configuration of the TCP maximum SYN retransmission amount in Windows 7 or Windows Server 2008 R2

• Hotfix #2472264: You cannot customize some TCP configurations by using the netsh command in Windows Server 2008 R2

From the 2786464 hotfix article:

Note In Windows 7 and Windows Server 2008 R2, the TCP maximum SYN retransmission (JH: MaxSynRetransmissions) value is set to 2, and is not configurable. Because of the 3-second limit of the initial time-out value (JH: InitialRTO), the TCP three-way handshake is limited to a 21-second timeframe (3 seconds + 2*3 seconds + 4*3 seconds = 21 seconds).

The first hotfix adds a 'MaxSynRetransmissions' setting which allows changing the retry setting from the default value of 2. The second adds 'InitialRto' setting which allows changing the Initial RTO value from the default of 3000ms (yes, milliseconds), but only to something shorter than 3000ms; it cannot be increased. Depending on your situation, you may only need the 'MaxSynRetransmissions' hotfix.

Install both hotfixes, reboot, then open a command window as Administrator. Further reboots are not required for subsequent netsh command invocations.

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

Note: Windows telnet is used for the reference for actual connection timeout. It needs to be installed separately, but is easy to do.

Additional links / kudos:

• Windows 7: Enabling Telnet Client
• How to measure execution time of command in windows command line?
• Batch script: how to check for admin rights

Answer 3

TcpInitialRTT and TcpMaxConnectRetransmissions may not be present in Vista and Windows 2008. This Microsoft document does not include them. http://download.microsoft.com/download/c/2/6/c26893a6-46c7-4b5c-b287-830216597340/TCPIP_Reg.doc

And this says at least TcpInitialRTT is gone, although I don't know how reliable it is. http://pul.se/Blog-Post-TCP-IP-Stack-hardening-in-Operating-Systems-starting-with-Windows-Vista_SharePoint-kHPTTCP0WJ5,7zq00hH0wINE

Answer 4

If I understand your question correctly, you are referring to:

TcpTimedWaitDelay

This key determines the time that must elapse before TCP/IP can release a closed connection and reuse its resources. This interval between closure and release is known as the TIME_WAIT state or twice the maximum segment lifetime (2MSL) state. During this time, reopening the connection to the client and server costs less than establishing a new connection. By reducing the value of this entry, TCP/IP can release closed connections faster and provide more resources for new connections. Adjust this parameter if the running application requires rapid release, the creation of new connections, or an adjustment because of a low throughput caused by multiple connections in the TIME_WAIT state.

The exact key is: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Tcpip\Parameters\TcpTimedWaitDelay

You may not have it set if you are using Win2008 or later, but the default is 240 decimal (240 seconds or 4 minutes that is). You can add the key to the registry with a different value and it will take effect after a reboot (tested on Windows Server 2008R2 in a production environment). This is an absurdly high value given the quality of modern networks.

I had an application literally less than a month ago running on a server that exhausted the maximum number of connections Windows can support and killed every network service on that server regularly. 16,000+ connections in netstat -a when you even manage to RDP to the server. We set the value to 30 decimal (30 seconds) and voila, the issue was solved - less than 10,000 simultaneous connections (since the app was rapidly opening and closing them) and no throughput issues.