Qual è il timeout di connessione TCP predefinito in Windows? Esiste una chiave di registro per configurarla o è impostata in modo dinamico?
Qual è il timeout di connessione TCP predefinito in Windows? Esiste una chiave di registro per configurarla o è impostata in modo dinamico?
Risposte:
In Windows il valore è dinamico per le connessioni stabilite , sebbene il valore predefinito per le connessioni iniziali sia 72 secondi. Le impostazioni del registro sono definite in questo articolo:
http://technet.microsoft.com/en-us/library/cc739819(WS.10).aspx
HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services: \ Tcpip \ Parameters
TcpInitialRTT : definisce le impostazioni di timeout iniziale per le nuove connessioni. Questo numero in secondi viene raddoppiato ogni volta che viene ritrasmesso prima del timeout di una connessione. Il valore predefinito è 3.
TcpMaxConnectRetransmissions : definisce il numero di ritrasmissioni prima del timeout di una connessione. Il valore predefinito è 5.
In genere "timeout di connessione" si riferisce al timeout per la creazione della connessione iniziale a un host. In molti sistemi (incluso Windows 7), questo valore viene configurato utilizzando impostazioni separate dai timeout per le comunicazioni in corso dopo aver stabilito una connessione. Questa risposta risolve lo scenario di "connessione iniziale" per Windows 7, che è diverso da XP.
Per Windows 7, sono necessari due hotfix per supportare la regolazione delle impostazioni di timeout della connessione. Le nuove impostazioni possono essere configurate con il comando 'netsh'.
Dall'articolo di aggiornamento rapido 2786464:
Nota In Windows 7 e Windows Server 2008 R2, il valore di ritrasmissione massima SYN TCP (JH: MaxSynRetransmissions) è impostato su 2 e non è configurabile. A causa del limite di 3 secondi del valore di timeout iniziale (JH: InitialRTO), l'handshake a tre vie TCP è limitato a un intervallo di tempo di 21 secondi (3 secondi + 2 * 3 secondi + 4 * 3 secondi = 21 secondi ).
Il primo aggiornamento rapido aggiunge un'impostazione "MaxSynRetransmissions" che consente di modificare l'impostazione dei tentativi dal valore predefinito di 2. Il secondo aggiunge l'impostazione "InitialRto" che consente di modificare il valore RTO iniziale dal valore predefinito di 3000 ms (sì, millisecondi), ma solo a qualcosa di meno di 3000 ms; non può essere aumentato. A seconda della situazione, potrebbe essere necessario solo l'aggiornamento rapido "MaxSynRetransmissions".
Installa entrambi gli hotfix, riavvia, quindi apri una finestra di comando come amministratore. Non sono necessari ulteriori riavvii per le successive chiamate ai comandi netsh.
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 viene utilizzato come riferimento per il timeout di connessione effettivo. Deve essere installato separatamente, ma è facile da fare.
Link / complimenti aggiuntivi:
TcpInitialRTT e TcpMaxConnectRetransmissions potrebbero non essere presenti in Vista e Windows 2008. Questo documento Microsoft non li include. http://download.microsoft.com/download/c/2/6/c26893a6-46c7-4b5c-b287-830216597340/TCPIP_Reg.doc
E questo dice che almeno TcpInitialRTT è sparito, anche se non so quanto sia affidabile. http://pul.se/Blog-Post-TCP-IP-Stack-hardening-in-Operating-Systems-starting-with-Windows-Vista_SharePoint-kHPTTCP0WJ5,7zq00hH0wINE
Se capisco correttamente la tua domanda, ti riferisci a:
TcpTimedWaitDelay
Questa chiave determina il tempo che deve trascorrere prima che TCP / IP possa rilasciare una connessione chiusa e riutilizzarne le risorse. Questo intervallo tra chiusura e rilascio è noto come stato TIME_WAIT o due volte lo stato di durata massima del segmento (2MSL). Durante questo periodo, riaprire la connessione al client e al server costa meno che stabilire una nuova connessione. Riducendo il valore di questa voce, TCP / IP può rilasciare connessioni chiuse più velocemente e fornire più risorse per nuove connessioni. Regola questo parametro se l'applicazione in esecuzione richiede il rilascio rapido, la creazione di nuove connessioni o una regolazione a causa di una velocità effettiva bassa causata da più connessioni nello stato TIME_WAIT.
La chiave esatta è: HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Tcpip \ Parameters \ TcpTimedWaitDelay
Potrebbe non essere impostato se si utilizza Win2008 o versione successiva, ma l'impostazione predefinita è 240 decimali (240 secondi o 4 minuti). È possibile aggiungere la chiave al Registro di sistema con un valore diverso e avrà effetto dopo un riavvio (testato su Windows Server 2008R2 in un ambiente di produzione). Questo è un valore assurdamente elevato data la qualità delle reti moderne.
Ho avuto un'applicazione letteralmente meno di un mese fa in esecuzione su un server che esauriva il numero massimo di connessioni supportate da Windows e uccideva regolarmente ogni servizio di rete su quel server. Oltre 16.000 connessioni in netstat -a quando riesci persino a eseguire RDP sul server. Impostiamo il valore su 30 decimali (30 secondi) e voilà, il problema è stato risolto: meno di 10.000 connessioni simultanee (poiché l'app le stava rapidamente aprendo e chiudendo) e nessun problema di throughput.
TcpMaxDataRetransmissions
a 16 (il valore predefinito dovrebbe essere 5), ma il mio PuTTY interrompe ancora le connessioni molto velocemente in caso di brevi interruzioni, mentre ssh su OS X e la stessa rete le mantengono bene. superuser.com/questions/529511/…