Quelle est la temporisation de connexion par défaut TCP dans Windows?
Quelle est la valeur par défaut TCP timeout de connexion dans Windows? Il existe une clé de registre pour la configurer ou elle est définie dynamiquement?
Sous Windows, la valeur est dynamique pour les connexions établies, bien que la valeur par défaut pour connexions initiales soit 72 secondes. Les paramètres du Registre sont définis dans cet article:
http://technet.Microsoft.com/en-us/library/cc739819 (WS.10) .aspx
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services:\Tcpip\Parameters
TcpInitialRTT : définit les paramètres de délai d'attente initial pour les nouvelles connexions. Ce nombre en secondes est doublé chaque fois qu'il retransmet avant de temporiser une connexion. La valeur par défaut est 3.
TcpMaxConnectRetransmissions : définit le nombre de retransmissions avant de temporiser une connexion. La valeur par défaut est 5.
Habituellement, "délai d'expiration de connexion" fait référence au délai d'expiration pour la création de la connexion initiale à un hôte. Dans de nombreux systèmes (Windows 7 inclus), cette valeur est configurée à l'aide de paramètres distincts des délais d'expiration pour les communications en cours une fois la connexion établie. Cette réponse concerne le scénario de "connexion initiale" pour Windows 7, qui est différent de XP.
Pour Windows 7, deux correctifs sont nécessaires pour prendre en charge l'ajustement des paramètres de délai de connexion. Les nouveaux paramètres peuvent être configurés avec la commande 'netsh'.
À partir de l'article du correctif 2786464:
Remarque Dans Windows 7 et Windows Server 2008 R2, la valeur TCP maximum de retransmission SYN (JH: MaxSynRetransmissions) est définie sur 2 et n'est pas configurable. En raison de la limite de 3 secondes de la valeur initiale délai d'expiration (JH: InitialRTO), la TCP prise de contact à trois voies est limitée à un délai de 21 secondes (3 secondes + 2 * 3 secondes + 4 * 3 secondes = 21 secondes) .
Le premier correctif ajoute un paramètre "MaxSynRetransmissions" qui permet de modifier le paramètre de nouvelle tentative à partir de la valeur par défaut de 2. Le second ajoute le paramètre "InitialRto" qui permet de modifier la valeur RTO initiale par défaut de 3000 ms (oui, millisecondes), mais uniquement pour quelque chose de moins de 3000 ms; il ne peut pas être augmenté. Selon votre situation, il se peut que vous n'ayez besoin que du correctif "MaxSynRetransmissions".
Installez les deux correctifs, redémarrez, puis ouvrez une fenêtre de commande en tant qu'administrateur. Des redémarrages supplémentaires ne sont pas nécessaires pour les appels de commandes netsh ultérieurs.
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
Remarque: Windows Telnet est utilisé comme référence pour le délai de connexion réel. Il doit être installé séparément, mais il est facile à faire.
Liens/félicitations supplémentaires:
TcpInitialRTT et TcpMaxConnectRetransmissions peuvent ne pas être présents dans Vista et Windows 2008. Ce document Microsoft ne les inclut pas. http://download.Microsoft.com/download/c/2/6/c26893a6-46c7-4b5c-b287-830216597340/TCPIP_Reg.doc
Et cela indique qu'au moins TcpInitialRTT a disparu, bien que je ne sache pas à quel point il est fiable. http://pul.se/Blog-Post-TCP-IP-Stack-hardening-in-Operating-Systems-starting-with-Windows-Vista_SharePoint-kHPTTCP0WJ5,7zq00hH0wINE
Si je comprends bien votre question, vous faites référence à:
TcpTimedWaitDelay
Cette clé détermine le temps qui doit s'écouler avant que TCP/IP puisse libérer une connexion fermée et réutiliser ses ressources. Cet intervalle entre la fermeture et la libération est appelé état TIME_WAIT ou deux fois l'état de durée de vie maximale du segment (2MSL). Pendant ce temps, la réouverture de la connexion au client et au serveur coûte moins cher que l'établissement d'une nouvelle connexion. En réduisant la valeur de cette entrée, TCP/IP peut libérer des connexions fermées plus rapidement et fournir plus de ressources pour de nouvelles connexions. Ajustez ce paramètre si l'application en cours d'exécution nécessite une libération rapide, la création de nouvelles connexions ou un ajustement en raison d'un faible débit provoqué par plusieurs connexions dans l'état TIME_WAIT.
La clé exacte est: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Tcpip\Parameters\TcpTimedWaitDelay
Vous ne pouvez pas l'avoir défini si vous utilisez Win2008 ou version ultérieure, mais la valeur par défaut est 240 décimales (240 secondes ou 4 minutes). Vous pouvez ajouter la clé au registre avec une valeur différente et elle prendra effet après un redémarrage (testé sur Windows Server 2008R2 dans un environnement de production). Il s'agit d'une valeur absurdement élevée compte tenu de la qualité des réseaux modernes.
Il y a moins d'un mois, une application fonctionnait sur un serveur qui épuisait le nombre maximal de connexions que Windows peut prendre en charge et tuait régulièrement tous les services réseau sur ce serveur. Plus de 16 000 connexions dans netstat -a lorsque vous parvenez même à RDP vers le serveur. Nous avons défini la valeur à 30 décimales (30 secondes) et le tour est joué, le problème a été résolu - moins de 10 000 connexions simultanées (car l'application les ouvrait et les fermait rapidement) et aucun problème de débit.