Quel est le délai de connexion TCP par défaut dans Windows?


28

Quel est le délai de connexion TCP par défaut dans Windows? Il existe une clé de registre pour la configurer ou elle est définie dynamiquement?

Réponses:


23

Sous Windows, la valeur est dynamique pour les connexions établies , bien que la valeur par défaut pour les connexions initiales soit de 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.


Il suffit de rétablir une connexion donnée après les avoir modifiés, pas besoin de redémarrer, non? Savez-vous éventuellement lequel doit être modifié pour empêcher Windows 7 de supprimer proactivement les connexions existantes lors de courtes pannes? J'ai essayé de passer TcpMaxDataRetransmissionsà 16 (la valeur par défaut est censée être 5), mais mon PuTTY abandonne toujours les connexions très rapidement lors de brèves pannes, tandis que ssh sur OS X et le même réseau les maintient très bien. superuser.com/questions/529511/…
cnst

3
En fait, cela a fonctionné après avoir redémarré! Rien ne change jamais sous Windows! Il semble que vous deviez redémarrer, et le paramètre n'a aucun effet sur les anciennes ou les nouvelles connexions si vous modifiez simplement le registre sans redémarrer!
FCÉN

9

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 de retransmission SYN maximale TCP (JH: MaxSynRetransmissions) est définie sur 2 et n'est pas configurable. En raison de la limite de 3 secondes de la valeur du délai d'attente initial (JH: InitialRTO), la négociation à trois voies TCP 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:


2

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


1

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 supprimait 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.


Dans Windows Server 2012 et 2016, la clé exacte semble être HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ Tcpip \ Parameters \ TcpTimedWaitDelay
Vincent

Est-il sûr de supposer que cette modification du registre nécessite un redémarrage?
Vincent
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.