Ustawianie czasu oczekiwania TCP
Próbujemy dostroić aplikację, która akceptuje wiadomości przez TCP, a także używa TCP do niektórych wewnętrznych wiadomości. Podczas testowania obciążenia zauważyliśmy, że czas reakcji znacznie się zmniejsza (a następnie zatrzymuje się całkowicie), ponieważ więcej jednoczesnych żądań jest wysyłanych do systemu. W tym czasie widzimy wiele połączeń TCP w statusie TIME_WAIT i ktoś zasugerował obniżenie zmiennej środowiskowej TIME_WAIT z domyślnej 60 sekund na 30.
From what I understand , ustawienie TIME_WAIT zasadniczo określa czas ponownego udostępnienia zasobu TCP systemowi po zamknięciu połączenia.
- myślę, że rozumiem dlaczego
TIME_WAITwartość nie może być ustawiona na 0, ale czy można ją bezpiecznie ustawić na 5? A 10? Co decyduje o" bezpiecznym " ustawieniu dla tej wartości? - Dlaczego jest domyślna dla tego wartość 60? Zgaduję, że ludzie dużo mądrzejsi ode mnie mieli dobry powód, aby wybrać to jako rozsądną domyślność.
- co jeszcze powinienem wiedzieć o potencjalnych zagrożeniach i korzyściach wynikających z przekroczenia tej wartości?
7 answers
Połączenie TCP jest określone przez krotkę (source IP, source port, destination IP, destination port).
Powodem, dla którego istnieje stan TIME_WAIT po zamknięciu sesji, jest to, że nadal mogą istnieć Pakiety aktywne w sieci w drodze do ciebie (lub od Ciebie, które mogą wywołać jakąś odpowiedź). Jeśli ponownie utworzysz tę samą krotkę i pojawi się jeden z tych pakietów, będzie on traktowany jako ważny pakiet dla Twojego połączenia (i prawdopodobnie spowoduje błąd z powodu do sekwencjonowania).
Tak więc czas TIME_WAIT jest zazwyczaj ustawiony na podwojenie maksymalnego wieku pakietów. Wartość ta określa maksymalny wiek, do którego będą mogły dotrzeć pakiety, zanim sieć je odrzuci.
To gwarantuje, że zanim będziesz mógł stworzyć połączenie z tą samą krotką, wszystkie pakiety należące do poprzednich wcieleń tej krotki będą martwe.
To zazwyczaj określa minimalną wartość, której powinieneś użyć. Maksymalny wiek pakietów jest podyktowany przez sieć właściwości, na przykład, że żywotność satelitów jest wyższa niż żywotność sieci LAN, ponieważ pakiety mają znacznie więcej do zrobienia.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2013-06-14 01:43:35
Zazwyczaj tylko punkt końcowy, który wystawia "aktywne zamknięcie", powinien przejść do stanu TIME_WAIT. Tak więc, jeśli to możliwe, niech twoi klienci wydadzą aktywne zamknięcie, które pozostawi TIME_WAIT na kliencie, a nie na serwerze.
Zobacz tutaj: http://www.serverframework.com/asynchronousevents/2011/01/time-wait-and-its-design-implications-for-protocols-and-scalable-servers.html i http://www.isi.edu/touch/pubs/infocomm99/infocomm99-web / dla szczegółów (później także wyjaśnia, dlaczego nie zawsze jest to możliwe ze względu na projekt protokołu, który nie bierze pod uwagę TIME_WAIT).
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2011-06-24 17:36:49
Pax ma rację co do powodów TIME_WAIT i dlaczego powinieneś uważać na obniżenie domyślnego ustawienia.
Lepszym rozwiązaniem jest zmiana numerów portów używanych dla początkowego końca gniazd. Gdy to zrobisz, nie będzie naprawdę dbać o czas oczekiwania na poszczególne gniazda.
Dla gniazd nasłuchowych, możesz użyć SO_REUSEADDR, aby umożliwić Gniazdo nasłuchowe związanie się pomimo gniazd TIME_WAIT.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2008-12-03 14:05:28
W systemie Windows Możesz zmienić to poprzez rejestr :
; Set the TIME_WAIT delay to 30 seconds (0x1E)
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TCPIP\Parameters]
"TcpTimedWaitDelay"=dword:0000001E
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2016-05-10 23:07:59
Ustawienie tcp_reuse jest bardziej przydatne niż zmiana time_wait, o ile masz parametr (jądra 3.2 i wyżej, niestety dyskwalifikuje to wszystkie wersje RHEL i XenServer).
Obniżenie wartości, szczególnie dla użytkowników podłączonych do sieci VPN, może skutkować ciągłym odtwarzaniem tuneli proxy przy połączeniu wychodzącym. Przy domyślnej konfiguracji Netscaler (XenServer), która jest niższa niż domyślna konfiguracja Linuksa, Chrome czasami będzie musiał odtworzyć tunel proxy w górę do kilkunastu razy, aby odzyskać jedną stronę internetową. Aplikacje, które nie próbują ponownie, takie jak Maven i Eclipse P2, po prostu zawodzą.
Oryginalny motyw parametru (unikaj powielania) został nadmiarowy przez RFC TCP, które określa włączenie znacznika czasu we wszystkich żądaniach TCP.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2016-06-02 19:38:10
Testowałem aplikację serwerową (na Linuksa) za pomocą programu testowego z 20 wątkami.
W 959 000 cykli connect / close miałem 44 000 nieudanych połączeń i wiele tysięcy gniazd w TIME_WAIT.
Przed zamknięciem ustawiłem SO_LINGER na 0 i w kolejnych uruchomieniach programu testowego nie było żadnych awarii połączenia i mniej niż 20 gniazd w TIME_WAIT.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2016-04-28 06:54:48
TIME_WAIT może nie być winowajcą.
int listen(int sockfd, int backlog);
Według Unix Network Programming Volume1, backlog jest zdefiniowany jako suma zakończonej kolejki połączeń i niekompletnej kolejki połączeń.
Powiedzmy, że zaległości to 5. Jeśli masz 3 zakończone połączenia (stan ustalony) i 2 niekompletne połączenia (stan SYN_RCVD), a jest jeszcze jedno żądanie połączenia z SYN. Stos TCP ignoruje pakiet SYN, wiedząc, że zostanie on retransmitowany innym razem. To może powoduje degradację.
Przynajmniej to czytałam. ;)Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2008-12-03 18:04:41