Jaki jest domyślny limit czasu połączenia TCP w systemie Windows? Istnieje klucz rejestru, aby go skonfigurować, czy jest ustawiany dynamicznie?
Jaki jest domyślny limit czasu połączenia TCP w systemie Windows? Istnieje klucz rejestru, aby go skonfigurować, czy jest ustawiany dynamicznie?
Odpowiedzi:
W systemie Windows wartość jest dynamiczna dla ustanowionych połączeń , jednak domyślna wartość dla początkowych połączeń wynosi 72 sekundy. Ustawienia rejestru są zdefiniowane w tym artykule:
http://technet.microsoft.com/en-us/library/cc739819(WS.10).aspx
HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services: \ Tcpip \ Parameters
TcpInitialRTT : określa początkowe ustawienia limitu czasu dla nowych połączeń. Liczba w sekundach jest podwajana za każdym razem, gdy retransmituje się, a następnie kończy połączenie. Domyślnie 3.
TcpMaxConnectRetransmissions : Definiuje liczbę retransmisji przed przekroczeniem limitu czasu połączenia. Domyślnie 5.
Zazwyczaj „limit czasu połączenia” odnosi się do limitu czasu na utworzenie początkowego połączenia z hostem. W wielu systemach (w tym Windows 7) ta wartość jest konfigurowana przy użyciu oddzielnych ustawień od limitów czasu dla ciągłej komunikacji po ustanowieniu połączenia. Ta odpowiedź dotyczy scenariusza „początkowego połączenia” dla systemu Windows 7, który różni się od XP.
W przypadku systemu Windows 7 do poprawienia ustawień limitu czasu połączenia wymagane są dwie poprawki. Nowe ustawienia można skonfigurować za pomocą polecenia „netsh”.
Z artykułu o poprawce 2786464:
Uwaga W systemach Windows 7 i Windows Server 2008 R2 maksymalna retransmisja TCP SYN (JH: MaxSynRetransmissions) jest ustawiona na 2 i nie można jej konfigurować. Z powodu 3-sekundowego limitu początkowej wartości limitu czasu (JH: InitialRTO), trójdrożny uścisk dłoni TCP jest ograniczony do 21-sekundowego przedziału czasowego (3 sekundy + 2 * 3 sekundy + 4 * 3 sekundy = 21 sekund ).
Pierwsza poprawka dodaje ustawienie „MaxSynRetransmissions”, które umożliwia zmianę ustawienia ponownej próby z wartości domyślnej 2. Drugie dodaje ustawienie „InitialRto”, która umożliwia zmianę początkowej wartości RTO z domyślnej wartości 3000 ms (tak, milisekundy), ale tylko coś krótszego niż 3000 ms; nie można go zwiększyć. W zależności od sytuacji może być potrzebna tylko poprawka „MaxSynRetransmissions”.
Zainstaluj obie poprawki, uruchom ponownie, a następnie otwórz okno poleceń jako Administrator. Dalsze restarty nie są wymagane dla kolejnych wywołań poleceń 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
Uwaga: Telnet systemu Windows służy jako odniesienie dla rzeczywistego limitu czasu połączenia. Musi być zainstalowany osobno, ale jest łatwy do zrobienia.
Dodatkowe linki / wyróżnienia:
TcpInitialRTT i TcpMaxConnectRetransmissions mogą nie być obecne w systemie Vista i Windows 2008. Ten dokument Microsoft ich nie zawiera. http://download.microsoft.com/download/c/2/6/c26893a6-46c7-4b5c-b287-830216597340/TCPIP_Reg.doc
I to mówi, że przynajmniej TcpInitialRTT już nie ma, chociaż nie wiem, jak wiarygodny. http://pul.se/Blog-Post-TCP-IP-Stack-hardening-in-Operating-Systems-starting-with-Windows-Vista_SharePoint-kHPTTCP0WJ5,7zq00hH0wINE
Jeśli dobrze rozumiem twoje pytanie, masz na myśli:
TcpTimedWaitDelay
Ten klucz określa czas, jaki musi upłynąć, zanim TCP / IP może zwolnić zamknięte połączenie i ponownie wykorzystać swoje zasoby. Ten odstęp między zamknięciem a zwolnieniem jest znany jako stan TIME_WAIT lub dwukrotność maksymalnego okresu istnienia segmentu (2MSL). W tym czasie ponowne otwarcie połączenia z klientem i serwerem kosztuje mniej niż ustanowienie nowego połączenia. Zmniejszając wartość tego wpisu, protokół TCP / IP może szybciej zwalniać zamknięte połączenia i zapewniać więcej zasobów dla nowych połączeń. Dostosuj ten parametr, jeśli uruchomiona aplikacja wymaga szybkiego zwolnienia, utworzenia nowych połączeń lub dostosowania z powodu niskiej przepustowości spowodowanej wieloma połączeniami w stanie TIME_WAIT.
Dokładny klucz to: HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Tcpip \ Parameters \ TcpTimedWaitDelay
Możesz go nie ustawić, jeśli używasz Win2008 lub nowszego, ale domyślnie jest to 240 miejsc dziesiętnych (czyli 240 sekund lub 4 minuty). Możesz dodać klucz do rejestru o innej wartości, a wejdzie on w życie po ponownym uruchomieniu (testowane na Windows Server 2008R2 w środowisku produkcyjnym). Jest to absurdalnie wysoka wartość, biorąc pod uwagę jakość nowoczesnych sieci.
Miałem aplikację dosłownie niespełna miesiąc temu działającą na serwerze, która wyczerpała maksymalną liczbę połączeń, które system Windows może obsługiwać i zabijał regularnie każdą usługę sieciową na tym serwerze. Ponad 16 000 połączeń w netstat -a, nawet jeśli zarządzasz protokołem RDP z serwerem. Ustawiliśmy wartość na 30 miejsc po przecinku (30 sekund) i voila, problem został rozwiązany - mniej niż 10.000 równoczesnych połączeń (ponieważ aplikacja szybko je otwierała i zamykała) i brak problemów z przepustowością.
TcpMaxDataRetransmissions
na 16 (domyślnie ma to być 5), ale mój PuTTY nadal bardzo szybko zrywa połączenia w przypadku krótkich awarii, podczas gdy ssh w OS X i ta sama sieć utrzymuje je w porządku. superuser.com/questions/529511/…