Установка TIME_WAIT TCP - PullRequest
Новая
       18

Установка TIME_WAIT TCP

64 голосов
/ 03 декабря 2008

Мы пытаемся настроить приложение, которое принимает сообщения через TCP, а также использует TCP для некоторых своих внутренних сообщений. Во время нагрузочного тестирования мы заметили, что время отклика значительно снижается (а затем и вовсе прекращается), поскольку в систему поступает больше одновременных запросов. За это время мы видим множество TCP-соединений в состоянии TIME_WAIT, и кто-то предложил понизить переменную окружения TIME_WAIT со значения по умолчанию с 60 секунд до 30.

Начиная с что я понимаю , настройка TIME_WAIT фактически устанавливает время, когда ресурс TCP снова становится доступным для системы после закрытия соединения.

Я не "сетевой парень" и очень мало знаю об этих вещах. Мне нужно многое из того, что есть в этом связанном посте, но немного ошарашено.

  • Мне кажется, я понимаю, почему значение TIME_WAIT не может быть установлено на 0, но может ли оно быть безопасно установлено на 5? Как насчет 10? Что определяет «безопасную» настройку для этого значения?
  • Почему по умолчанию для этого значения 60? Я предполагаю, что люди намного умнее меня имели веские основания для выбора этого в качестве разумного значения по умолчанию.
  • Что еще я должен знать о потенциальных рисках и преимуществах переопределения этого значения?

Ответы [ 7 ]

92 голосов
/ 03 декабря 2008

TCP-соединение определяется кортежем (исходный IP-адрес, исходный порт, IP-адрес назначения, порт назначения).

Причина, по которой возникает состояние TIME_WAIT после завершения сеанса, заключается в том, что по-прежнему могут существовать живые пакеты в сети на пути к вам (или от вас, которые могут запросить какой-либо ответ). Если вы воссоздадите тот же кортеж, и один из этих пакетов появится, он будет считаться действительным пакетом для вашего соединения (и, вероятно, приведет к ошибке из-за последовательности).

Таким образом, время TIME_WAIT обычно устанавливается на удвоение максимального возраста пакетов. Это значение является максимальным возрастом, до которого ваши пакеты будут разрешены до того, как сеть их отбросит.

Это гарантирует, что, прежде чем вам разрешат создать соединение с тем же кортежем, все пакеты, принадлежащие предыдущим воплощениям этого кортежа, будут мертвыми.

Это обычно определяет минимальное значение, которое вы должны использовать. Максимальный срок действия пакета определяется свойствами сети, например, время жизни спутника выше, чем время жизни ЛВС, поскольку пакеты должны пройти гораздо дальше.

19 голосов
/ 03 декабря 2008

Обычно только конечная точка, которая выдает «активное закрытие», должна переходить в состояние TIME_WAIT. Поэтому, если возможно, пусть ваши клиенты выдают активное закрытие, которое оставляет TIME_WAIT на клиенте, а НЕ на сервере.

Подробнее см. Здесь: http://www.serverframework.com/asynchronousevents/2011/01/time-wait-and-its-design-implications-for-protocols-and-scalable-servers.html и http://www.isi.edu/touch/pubs/infocomm99/infocomm99-web/ (в последующем также объясняется, почему это не всегда возможно из-за структуры протокола, в которой не учитывается TIME_WAIT).

9 голосов
/ 03 декабря 2008

Пакс прав в отношении причин TIME_WAIT и почему вы должны быть осторожны при снижении настройки по умолчанию.

Лучшим решением является изменение номеров портов, используемых для исходящего конца ваших сокетов. После того, как вы это сделаете, вам не придется долго ждать отдельных сокетов.

Для сокетов прослушивания вы можете использовать SO_REUSEADDR, чтобы разрешить связывание сокета прослушивания, несмотря на то, что сокеты TIME_WAIT сидят без дела.

3 голосов
/ 24 марта 2013

В Windows вы можете изменить это через реестр : 

; Set the TIME_WAIT delay to 30 seconds (0x1E)

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TCPIP\Parameters]
"TcpTimedWaitDelay"=dword:0000001E
2 голосов
/ 02 июня 2016

установка tcp_reuse более полезна, чем изменение time_wait, если у вас есть параметр (ядра 3.2 и выше, к сожалению, который дисквалифицирует все версии RHEL и XenServer).

Сброс значения, особенно для пользователей, подключенных по VPN, может привести к постоянному воссозданию прокси-туннелей на исходящем соединении. С конфигурацией Netscaler (XenServer) по умолчанию, которая ниже конфигурации Linux по умолчанию, Chrome иногда приходится воссоздавать туннель прокси до десятка раз, чтобы получить одну веб-страницу. Приложения, которые не повторяются, такие как Maven и Eclipse P2, просто не работают.

Первоначальный мотив для параметра (избегать дублирования) был сделан избыточным из-за TCP RFC, который указывает включение метки времени во все запросы TCP.

0 голосов
/ 28 апреля 2016

Я провёл нагрузочное тестирование серверного приложения (на linux) с помощью тестовой программы с 20 потоками.

В 959 000 циклов соединения / закрытия у меня было 44 000 неудачных соединений и много тысяч сокетов в TIME_WAIT.

Я установил SO_LINGER в 0 перед закрывающим вызовом, и в последующих запусках тестовой программы не было ошибок соединения и менее 20 сокетов в TIME_WAIT.

0 голосов
/ 03 декабря 2008

TIME_WAIT не может быть виновником. 

int listen(int sockfd, int backlog);

Согласно Unix Network Programming Volume1, отставание определяется как сумма завершенной очереди подключения и неполной очереди подключения.

Допустим, количество невыполненных заданий равно 5. Если у вас есть 3 завершенных соединения (состояние ESTABLISHED) и 2 незавершенных соединения (состояние SYN_RCVD), и есть еще один запрос на соединение с SYN. Стек TCP просто игнорирует пакет SYN, зная, что он будет передан в другой раз. Это может быть причиной деградации.

По крайней мере, это то, что я читал. ;)

...