Настройка TIME_WAIT TCP

Question

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

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

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

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

Answer 1

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

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

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

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

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

Answer 2

Обычно только конечная точка, которая выдает "активное закрытие", должна переходить в состояние 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).

Answer 3

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

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

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

Answer 4

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

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

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TCPIP\Parameters]
"TcpTimedWaitDelay"=dword:0000001E

Answer 5

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

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

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

Answer 6

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

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

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

Answer 7

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

int listen(int sockfd, int backlog);

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

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

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