НЕКОТОРЫЕ ТЕОРИИ
Я читал по tcp TIME-WAIT
(Вот и там) и я прочитал, что это значение установлено на 2 x MSL
(максимальный срок службы сегмента), который сохраняет соединение в «таблице соединений» некоторое время, чтобы гарантировать, что, "до того, как вам будет разрешено создать соединение с тем же кортежом, все пакеты, принадлежащие предыдущим воплощениям этого кортежа, будут мертвы".
Поскольку сегменты получены (кроме SYN при определенных обстоятельствах), когда соединение находится в TIME-WAIT
или уже не существующий будет отброшен, почему бы не закрыть соединение сразу?
В1: Это связано с тем, что при работе с сегментами из старых соединений требуется меньше обработки и меньше обработки для создания нового соединения в том же кортеже, когда TIME-WAIT
(т.е. есть ли преимущества в производительности)?
Если приведенное выше объяснение не работает, единственная причина, по которой я вижу TIME-WAIT
было бы полезно, если бы клиент отправил SYN
для соединения до того, как он отправит оставшиеся сегменты для старого соединения в том же кортеже, и в этом случае получатель повторно откроет соединение, но затем получит плохие сегменты и должен будет его завершить.
Q2: Правильный ли этот анализ?
Q3: Есть ли другие преимущества использования TIME-WAIT?
НЕКОТОРЫЕ ПРАКТИКИ
Я смотрел графики munin на производственном сервере, которым я управляю. Вот один из них:
Как видите, в TIME-WAIT
чем ESTABLISHED
, в большинстве случаев примерно в два раза больше, а в некоторых случаях в четыре раза больше.
Q4: Влияет ли это на производительность?
Q5: Если да, то разумно / рекомендуется ли уменьшить TIME-WAIT
значение (а что)?
Q6: Это соотношение TIME-WAIT
/ ESTABLISHED
подключения нормальные? Может ли это быть связано с попытками злонамеренного подключения?
Короче, не беспокойтесь о TIME_WAIT
. Накладные расходы практически отсутствуют и обычно не вызывают проблем.
На загруженном сервере возможно исчерпание портов, и в этом случае есть опция sysctl для net.ipv4.tcp_tw_reuse = 1
, что позволяет ядру повторно использовать старые порты, которые все еще находятся в TIME_WAIT
по мере необходимости.
TIME_WAIT является частью спецификации TCP и предназначен для перехвата пакетов, которые все еще могут быть в пути (помните, что не все соединения надежны, и это то, что TCP стремится решить). Значение тайм-аута может быть очень большим для большинства современных применений, но обычно оно не влияет ни на что, кроме вывода netstat.
Если вы сами контролируете сокет и уверены, что не ждете данных (например, вы конечный отправитель или вам не нужен ответ), вы можете закрыть сокет после установки SO_NOLINGER
опция, которая завершит соединение с RST
, и немедленно выбросить сокет.
Итак, ваши вопросы:
Q1, Q2, Q3: он предназначен для сбора поздних пакетов «на всякий случай», потому что ссылки могут быть ненадежными. Это часть спецификации, она предотвращает потерю пакетов, и ее настройка не дает реальной пользы.
Q4: Нет
Q5: Не беспокойтесь об этом, и у вас есть возможность принудительно повторно использовать эти сокеты, если это необходимо.
Q5: TIME_WAIT
и ESTABLISHED
не коррелированы, за исключением того, что чем больше у вас кратковременных связей, тем больше будет это соотношение. Это могло быть вызвано чем-то вредоносным, но это не более чем показатель «чрезмерной сетевой активности».
Некоторые ответы из моего ограниченного опыта с TIME_WAIT:
1/2/3) Смотрите это ТАК вопрос и эта страница для хорошего объяснения TIME_WAIT. Это не столько проблема производительности, сколько качество обслуживания, чтобы гарантировать правильное получение всех TCP-пакетов в соединении.
4/5) Одна проблема производительности, связанная с TIME_WAIT, заключается в том, что на очень загруженном сервере у вас могут в конечном итоге закончиться доступные подключения, если у вас их слишком много в состоянии TIME_WAIT. Если вы столкнулись с этой проблемой, вы можете попробовать уменьшить значение TIME_WAIT, но это может попасть в категорию настроек «Я знаю, что делаю». Видеть этот ТАК вопрос для получения более подробной информации.
6) Значение TIME_WAIT по умолчанию «должно» быть около 240 с (или вдвое больше MSL пакета 120 с). Таким образом, соотношение установленных / ожидающих соединений будет зависеть от скорости входящих соединений и от того, как долго они остаются открытыми. Например, я проверил несколько загруженных серверов, и соотношение варьировалось от 1,3 до 400, и все это я считаю нормальным в зависимости от сервера и трафика, который он получает.