3

Когда я использую следующую команду

netstat -ant | grep :9111 | awk '{print $6}' | sort | uniq -c | sort -n

Я получаю следующее

   1 LAST_ACK
   1 LISTEN
   2 SYN_RECV
   7 FIN_WAIT1
  51 ESTABLISHED
  71 FIN_WAIT2
8779 TIME_WAIT

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

Мой вопрос заключается в том, чтобы поддерживать запросы. Подавляющее большинство трафика, который я ожидаю увидеть, должно быть поддержано.

  1. Когда соединение поддержания активности войдет в период TIME_WAIT?
  2. Возможно ли для соединения kep live перейти от TIME_WAIT к ESTABLISHED? Если да, каковы условия?

1 ответ1

4

Независимо от того, включен ли механизм поддержания активности с обеих сторон: соединение никогда не перейдет из TIME_WAIT в ESTABLISHED. TIME_WAIT - это состояние пары сокетов из недавно закрытого соединения, которое временно не используется.

Соединение входит в состояние TIME_WAIT после того, как локальный конец успешно инициировал разрыв соединения ("активный ЗАКРЫТЬ") и получил сигнал от удаленного конца, что он тоже хочет закрыть соединение. Затем ОС удерживает пару сокетов, ожидая двух MSL, прежде чем освободит ее для другого свежего соединения. Это гарантирует, что ни один сегмент из старого соединения не будет мешать любому вновь созданному соединению, которое просто использует пару сокетов старого соединения.

Это действительно работает? Почему достаточно, чтобы только пара сокетов активно закрывающегося конца входила в TIME_WAIT? Поскольку повторное использование пары сокетов на одном конце подразумевает повторное использование пары сокетов на другом конце. Что, если активно закрывающийся конец произойдет сбой и перезагрузка в течение двух MSL? Затем он войдет в тихое время, в течение которого он вообще не создает никакой связи.

Конечный автомат TCP

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .