Установка TIME_WAIT TCP
4 ответа
Соединение TCP указано кортежем (исходный IP, исходный порт, целевой IP, целевой порт).
причина, почему существует состояние TIME_WAIT после завершения работы сессии, состоит в том, потому что может все еще быть, переживают пакеты в сети на их пути к Вам (или от Вас, которые могут требовать какого-то ответа). Если бы необходимо было воссоздать тот же самый кортеж, и один из тех пакетов обнаружился, то его рассматривали бы как допустимый пакет для соединения (и вероятно вызвал бы ошибку из-за упорядочивания).
, Таким образом, время TIME_WAIT обычно устанавливается удвоить пакетный возраст максимума. Это значение является максимальным возрастом, который Вашим пакетам позволят получить к тому, прежде чем сеть отбросит их.
, Который гарантирует, что, прежде чем Вам разрешат создать соединение с тем же кортежем, все пакеты, принадлежащие предыдущим воплощениям того кортежа, будут мертвы.
, Который обычно диктует минимальное значение, которое необходимо использовать. Максимальный пакетный возраст диктуют сетевые свойства, при этом пример тот, спутниковое время жизни выше, чем время жизни LAN, так как пакеты должны гораздо дальше пойти.
Обычно, только конечная точка, которая выпускает 'активное завершение', должна войти в состояние 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 во внимание).
Мир корректен о причинах TIME_WAIT, и почему необходимо быть осторожны относительно понижения настройки по умолчанию.
А лучшее решение состоит в том, чтобы варьироваться номера портов, используемые для инициирующего конца Ваших сокетов. После того как Вы делаете это, Вы не будете действительно заботиться во время, ожидают отдельных сокетов.
Для сокетов слушания, можно использовать SO_REUSEADDR, чтобы позволить сокету слушания связывать несмотря на заседание сокетов TIME_WAIT.
TIME_WAIT не мог бы быть преступником.
int listen(int sockfd, int backlog);
Согласно Сетевому программированию Unix Volume1, отставание определяется, чтобы быть суммой завершенной очереди соединений и очереди незавершенного соединения.
Скажем, отставание равняется 5. Если у Вас есть 3 завершенных соединения (УСТАНОВЛЕННОЕ состояние), и 2 незавершенных соединения (состояние SYN_RCVD), и существует другой запрос подключения с SYN. Стек TCP просто игнорирует пакет SYN, зная, что он будет ретранслироваться некоторое другое время. Это могло бы вызывать неисправность.
По крайней мере это - то, что я читал. ;)