tcp time wait что значит
Tcp time wait что значит
В этом разделе рассказывается о том, что такое состояние TIME-WAIT в протоколе TCP, для чего оно служит и почему не следует пытаться обойти его.
Поскольку состояние TIME-WAIT запрятано глубоко в недрах конечного автомата, управляющего работой TCP, многие программисты только подозреваю о его существовании и смутно представляют себе назначение и важность этого с стояния. Писать приложения TCP/IP можно, ничего не зная о состоянии ТIME-WAIT, но необходимо разобраться в странном, на первый взгляд, поведении приложения (указание 23). Это позволит избежать непредвиденных последствий.
Рассмотрим состояние TIME-WAIT и определим, каково его место в работе TCP-соединения. Затем будет рассказано о назначении этого состояния и его важности, а также, почему и каким образом некоторые программисты пытаются обойти это состояние. В конце дано правильное решение этой задачи.
Что это такое
Состояние TIME-WAIT наступает в ходе разрыва соединения. Помните (указание 7), что для разрыва TCP-соединения нужно обычно обменяться четырьмя сегментами, как показано на рис. 3.8.
Рис. 3.8. Разрыв соединения
В этот момент хост 2 окончательно закрывает соединение и освобождает ресурсы. С точки зрения хоста 2, соединения больше не существует. Однако хост 1 закрывает соединение, а переходит в состояние TIME-WAIT и остается в нем в течение двух максимальных продолжительностей существования сегмента (2MSL maximum segment lifetime).
Прождав время 2MSL, хост 1 также закрывает соединение и освобождает ресурсы.
Относительно состояния TIME-WAIT следует помнить следующее:
Примечание: Под активным закрытием понимается отправка первого FIN. Считается, что вторая сторона при этом выполняет пассивное закрытие. Возможно также одновременное закрытие, когда обе стороны закрывают соединение примерно в одно время, поэтому посланные ими FIN одновременно находятся в сети. В этом случае активное закрытие выполняют обе стороны, так что обе переходят в состояние TIME- WAIT.
Зачем нужно состояние TIME- WAIT
Состояние TIME-WAIT служит двум целям:
Рассмотрим каждую из этих причин. В момент, когда сторона, выполняющая активное закрытие, готова подтвердить посланный другой стороной FIN, все данные, отправленные другой стороной, уже получены. Однако последний АСК может потеряться. Если это произойдет, то сторона, выполняющая пассивное закрытие, обнаружит тайм-аут и пошлет свой FIN повторно (так как не получила АСК на последний порядковый номер).
А теперь посмотрим, что случится, если активная сторона не перейдет в состояние TIME-WAIT, а просто закроет соединение. Когда прибывает повторно переданный FIN, у TCP уже нет информации о соединении, поэтому он посылает в ответ RST (сброс), что для другой стороны служит признаком ошибки, а не нормального закрытия соединения. Но, так как сторона, пославшая последний АСК, все-таки перешла в состояние TIME-WAIT, информация о соединении еще хранится, так что она может корректно ответить на повторно отправленный FIN.
Этим объясняется и то, почему 2МSL-таймер перезапускается, если в состоянии TIME-WAIT приходит новый сегмент. Если последний АСК потерян, и другая сторона повторно послала FIN, то сторона, находящаяся в состоянии TIME-WAIT, еще раз подтвердит его и перезапустит таймер на случай, если и этот АСК будет потерян.
Второе назначение состояния TIME-WAIT более важно. Поскольку IР-дата-граммы могут теряться или задерживаться в глобальной сети, TCP использует механизм подтверждений для своевременной повторной передачи неподтвержденных сегментов (указание 1). Если датаграмма просто задержалась в пути, но не потеряна, или потерян подтверждающий ее сегмент АСК, то после прибытия исходных данных могут поступить также и повторно переданные. TCP в этом случае определяет, что порядковые номера поступивших данных находятся вне текущего окна приема, и отбрасывает их.
Состояние TIME-WAIT предотвращает такую ситуацию, гарантируя, что два прежних сокета (два IP-адреса и соответствующие им номера портов) повторно не используются, пока все сегменты, оставшиеся от старого соединения, не будут уничтожены. Таким образом, вы видите, что состояние TIME-WAIT играет важную роль в обеспечении надежности протокола TCP. Без него TCP не мог бы гарантировать доставку данных по порядку и без искажений (указание 9).
Принудительная отмена состояния TIME-WAIT
К сожалению, иногда можно досрочно выйти из состояния TIM Е-WAIT. Это называется принудительной отменой (TIME-WAIT assassination) и бывает случай но или намеренно.
Эта ситуация описана в RFC 1337 [Braden 1992b], где также рассматриваются трудности, сопряженные с принудительной отменой состояния TIME-WAIT. Опасность состоит в возможности «воскрешения» старого соединения (то есть появления соединения с теми же двумя сокетами), что может привести к подтверждению старых данных, десинхронизации соединения с входом в бесконечный цикл и к ошибочному завершению нового соединения.
Это легко предотвратить, изменив протокол TCP так, чтобы в состоянии TIME-WAIT было разрешено игнорировать RST Хотя такое изменение, рекомендованное в RFC 1337, официально не одобрено, тем не менее в некоторых стеках оно реализовано.
Принудительно отменить состояние TIME-WAIT можно и намеренно. С помощью опции сокета SO_LINGER программист требует немедленного закрытия соединения даже в том случае, когда приложение выполняет «активное закрытие. Этот сомнительный прием иногда рекомендуют применять, чтобы вывести «упавший» сервер из состояния TIME-WAIT и запустить его заново. Подробнее об этой проблеме и более правильном способе ее решения будет рассказано в указании 23. Корректно написанное приложение никогда не должно манипулировать состоянием TIME-WAIT, поскольку это неотъемлемая часть механизма обеспечения надежности TCP.
Обычно, когда приложение закрывает соединение, вызов close или closesocket возвращается немедленно, даже если в буфере передачи еще есть данные. Разумеется, TCP будет пытаться доставить эти данные, но приложение не имеет информации, удалось ли это. Чтобы решить эту проблему, можно установить опцию сокета SO_LINGER. Для этого следует заполнить структуру linger и вызывать setsockopt с параметром SO_LINGER.
В большинстве UNIX-систем структура linger определена в заголовочном файле /usr/include/sys/socket.h. В системе Windows она находится в файле winsock2.h. В любом случае она выглядит так:
int l_onoff; /*Включить/выключить опцию.*/
int l_linger; /*Время задержки.*/
Если к моменту завершения ожидания данные еще не доставлены, то close или closesocket возвращает код EWOULDBLOCK, и недоставленные данные могут быть потеряны. Если все данные уже доставлены, то оба вызова возвращают нуль.
Примечание: К сожалению, семантика поля l_linger зависит от реализации. В Windows и некоторых реализациях UNIX это число секунд, на которое следует задержать закрытие сокета. В системах, производных от BSD, это число тактов таймера (хотя в документации сказано, что это число секунд).
Если поле l_linger равно нулю, то соединение разрывается. Это означает, что хосту на другом конце посылается RST, и соединение закрывается немедленно, не переходя в состояние TIME-WAIT. Это преднамеренная принудительная отмена состояния TIME-WAIT, о которой упоминалось выше. Как было сказано, это опасный прием, который в обычном приложении применять не следует.
Резюме
Проблемы с очередью TIME_WAIT
Те кто разрабатывает активно работающие с сетью сервисы может наступить на особенности работы протокола TCP: переходу многих (или всех свободных) портов в состояние TIME_WAIT. В интернете много поверхностной информации и много не совсем корректной. Рассмотрим что это за ситуации, и определим возможные пути выхода из них.
Протокол TCP: закрытие соединения
Ниже типичная схема жизненного цикла TCP-соединения:
Не будем рассматривать её целиком, а сосредоточимся на наиболее важной для нас части — закрытии соединения.
Сторона, инициировавшая закрытие соединения называется «активной», вторая — «пассивной». Причем не важно кто из них был инициатором установки соединения.
Со стороны «пассивной» стороны всё просто. Получив пакет FIN, система должна ответить на него соответствующим ACK-пакетом, но имеет право продолжить отправку данных. С момента получения FIN пакета соединение у пассивной стороны находится в состоянии CLOSE_WAIT. По готовности, отправляется ответный FIN-пакет, после чего сторона дожидается ACK-пакета на него. По получении ACK на ответный FIN — соединение для пассивной стороны закрыто.
С точки зрения «активной» стороны всё несколько сложнее. После отправки FIN-пакета активная сторона переходит в состояние FIN_WAIT_1. Далее возможны три ситуации:
Как видно из диаграммы и описания активная сторона отправляет последний пакет в сессии (ACK на пассивный FIN). Поскольку она не может узнать получен ли этот пакет, для неё предусмотрен статус TIME_WAIT. В данном состоянии соединение должно находиться время 2 * MSL (максимальное время жизни пакета): время доставки пакета пассивной стороне + время доставки возможного ответного пакета назад. На практике, в настоящее время, таймер TIME_WAIT устанавливается в 1 — 2 минуты. По истечению этого таймера соединение считается закрытым.
Проблема TIME_WAIT для исходящих соединений
Соединение в операционной системы идентифицируется четырьмя параметрами: локальный IP, локальный порт, удалённый IP, удаленный порт. Допустим, у нас есть клиент, который активно подключается/отключается к удаленной службе. Поскольку оба IP и удаленный порт остаются неизменными, то на каждое новое соединение выделяется новый локальный порт. Если клиент был активной стороной завершения TCP-сессии, то это соединение будет заблокировано какое-то время в состоянии TIME_WAIT. Если соединения в устанавливаются быстрее чем порты выходят из карантина, то при очередной попытке соединения клиент получит ошибку EADDRNOTAVAIL (errno=99).
Что можно предпринять:
TIME_WAIT на серверах
Главная опасность которою несет разрастание очереди TIME_WAIT на сервере — это исчерпание ресурсов.
Тем не менее могут быть неприятные инциденты и при работе с NAT-клиентами (когда за одним IP находятся большое количество клиентов сервера). В случае малого значения времени карантина порта на Firewall велика вероятность что к серверу придёт запрос соединения с того же порта, соединение с которым ещё не закрыто (находится в TIME_WAIT). В этом случае возможны два три сценария:
Что можно предпринять на сервере.
Параметры ядра net.ipv4.tcp_tw_reuse и net.ipv4.tcp_tw_recycle
В ядре Linux есть два параметра, позволяющие нарушать требования TCP-протокола, высвобождая соединения из TIME_WAIT раньше положенного срока. Обе эти опции базируются на расширении TCP-timestamps (маркировки пакетов относительными временными метками).
Печенюшка
Протокол TCP: состояние TIME-WAIT
При использовании утилиты TCP View от Sysinternals или консольной команды netstat мы часто видим несколько непонятных состояний TCP-соединений. Если слова ESTABLISHED и LISTENING в состоянии соединения не вызывают вопросов, то что такое TIME_WAIT? Ожидание? Ожидание чего?…
Ответ на этот вопрос в полной мере дал мне сегодня Яндекс.
Состояние TIME-WAIT наступает в ходе разрыва соединения. Для разрыва TCP-соединения нужно обычно обменяться четырьмя сегментами, как показано на рисунке.
На рисунке показано соединение между двумя приложениями, работающими на хостах 1 и 2. Приложение на хосте 1 закрывает свою сторону соединения, при этом TCP посылает сегмент FIN хосту 2. Хост 2 подтверждает FIN сегментом АСК и доставляет FIN приложению в виде признака конца файла EOF (предполагается, что у приложения есть незавершенная операция чтения). Позже приложение на хосте 2 закрывает свою сторону соединения, посылая FIN хосту 1, который отвечает сегментом АСК.
В этот момент хост 2 окончательно закрывает соединение и освобождает ресурсы. С точки зрения хоста 2, соединения больше не существует. Однако хост 1 закрывает соединение, а переходит в состояние TIME-WAIT и остается в нем в течение двух максимальных продолжительностей существования сегмента (2MSL maximum segment lifetime).
Состояние TIME-WAIT служит двум целям:
— не дать соединению пропасть при потере последнего АСК, посланного активной стороной, в результате чего другая сторона повторно посылает FIN;
— дать время исчезнуть «заблудившимся сегментам», принадлежащим этому соединению.
2.7. Состояние TIME_WAIT
2.7. Состояние TIME_WAIT
Без сомнений, самым сложным для понимания аспектом TCP в отношении сетевого программирования является состояние TIME_WAIT (время ожидания). На рис. 2.4 мы видим, что узел, выполняющий активное закрытие, проходит это состояние. Продолжительность этого состояния равна двум MSL (maximum segment lifetime — максимальное время жизни сегмента), иногда этот период называется 2MSL.
В каждой реализации TCP выбирается какое-то значение MSL. Рекомендуемое значение, приведенное в документе RFC 1122 [10], равно 2 мин, хотя Беркли-реализации традиционно использовали значение 30 с. Это означает, что продолжительность состояния TIME_WAIT — от 1 до 4 мин. MSL — это максимальное количество времени, в течение которого дейтаграмма IP может оставаться в сети. Это время ограничено, поскольку каждая дейтаграмма содержит 8-разрядное поле предельного количества прыжков (hop limit) (поле TTL IPv4 на рис. А.1 и поле «Предельное количество транзитных узлов» IPv6 на рис. А.2), максимальное значение которого равно 255. Хотя этот предел ограничивает количество транзитных узлов, а не время пребывания пакета в сети, считается, что пакет с максимальным значением этого предела (которое равно 255) не может существовать в сети более MSL секунд.
Пакеты в объединенных сетях обычно теряются в результате различных аномалий. Маршрутизатор отключается, или нарушается связь между двумя маршрутизаторами, и им требуются секунды или минуты для стабилизации и нахождения альтернативного пути. В течение этого периода времени могут возникать петли маршрутизации (маршрутизатор А отправляет пакеты маршрутизатору В, а маршрутизатор В отправляет их обратно маршрутизатору А), и пакеты теряются в этих петлях. В этот момент, если потерянный пакет — это сегмент TCP, истекает установленное время ожидания отправляющего узла, и он снова передает пакет, и этот заново переданный пакет доходит до конечного места назначения по некоему альтернативному пути. Но если спустя некоторое время (не превосходящее количества секунд MSL после начала передачи потерянного пакета) петля маршрутизации исправляется, пакет, потерянный в петле, отправляется к конечному месту назначения. Начальный пакет называется потерянной копией или дубликатом (lost duplicate), а также блуждающей копией или дубликатом (wandering duplicate). TCP должен обрабатывать эти дублированные пакеты.
Есть две причины существования состояния TIME_WAIT:
? необходимо обеспечить надежность разрыва двустороннего соединения TCP;
? необходимо подождать, когда истечет время жизни в сети старых дублированных сегментов.
Первую причину можно объяснить, рассматривая рис. 2.5 в предположении, что последний сегмент ACK потерян. Сервер еще раз отправит свой последний сегмент FIN, поэтому клиент должен сохранять информацию о своем состоянии, чтобы отправить завершающее подтверждение ACK повторно. Если бы клиент не сохранял информацию о состоянии, он ответил бы серверу сегментом RST (еще один вид сегмента TCP), что сервер интерпретировал бы как ошибку. Если ответственность за корректное завершение двустороннего соединения в обоих направлениях ложится на TCP, он должен правильно обрабатывать потерю любого из четырех сегментов. Этот пример объясняет, почему в состоянии TIME_WAIT остается узел, выполняющий активное закрытие: именно этому узлу может потребоваться повторно передать подтверждение.
Чтобы понять вторую причину, по которой необходимо состояние TIME_WAIT, давайте считать, что у нас имеется соединение между IP-адресом 12.106.32.254, порт 1500 и IP-адресом 206.168.112.219, порт 21. Это соединение закрывается, и спустя некоторое время мы устанавливаем другое соединение между теми же IP-адресами и портами: 12.106.32.254, порт 1500 и 206.168.112.219, порт 21. Последнее соединение называется новым воплощением (incarnation) предыдущего соединения, поскольку IP-адреса и порты те же. TCP должен предотвратить появление старых дубликатов, относящихся к данному соединению, в новом воплощении этого соединения. Чтобы гарантировать это, TCP запрещает установление нового воплощения соединения, которое в данный момент находится в состоянии TIME_WAIT. Поскольку продолжительность состояния TIME_WAIT равна двум MSL, это позволяет удостовериться, что истечет и время жизни пакетов, посланных в одном направлении, и время жизни пакетов, посланных в ответ. Используя это правило, мы гарантируем, что в момент успешного установления соединения TCP время жизни в сети всех старых дубликатов от предыдущих воплощений этого соединения уже истекло.
Из этого правила существует исключение. Реализации, происходящие от Беркли, инициируют новое воплощение соединения, которое в настоящий момент находится в состоянии TIME WAIT, если приходящий сегмент SYN имеет порядковый номер «больше» конечного номера из предыдущего воплощения. На с. 958-959 [128] об этом рассказано более подробно. Для этого требуется, чтобы сервер выполнил активное закрытие, поскольку состояние TIME_WAIT должно существовать на узле, получающем следующий сегмент SYN. Эта возможность используется командой rsh. В документе RFC 1185 [54] рассказывается о некоторых ловушках, которые могут вас подстерегать при этом.
Данный текст является ознакомительным фрагментом.
Продолжение на ЛитРес
Читайте также
Состояние процесса
Состояние процесса Поле state дескриптора процесса описывает текущее состояние процесса (рис. 3.3). Каждый процесс в системе гарантированно находится в одном из пяти различных состояний. Рис. 3.3. Диаграмма состояний процессаЭти состояния представляются значением одного из
6.2. Состояние
6.2. Состояние Понятие состояния (state) является фундаментальным не только в метамоде-ли языка UML, но и в прикладном системном анализе. Ранее в главе 1 кратко были рассмотрены особенности представления динамических характеристик сложных систем, традиционно используемых для
Начальное состояние
Начальное состояние Начальное состояние представляет собой частный случай состояния, которое не содержит никаких внутренних действий (псевдосостояния). В этом состоянии находится объект по умолчанию в начальный момент времени. Оно служит для указания на диаграмме
Конечное состояние
Конечное состояние Конечное (финальное) состояние представляет собой частный случай состояния, которое также не содержит никаких внутренних действий (псевдосостояния). В этом состоянии будет находиться объект по умолчанию после завершения работы автомата в конечный
6.5. Историческое состояние
6.5. Историческое состояние Как было отмечено выше, формализм обычного автомата не позволяет учитывать предысторию в процессе моделирования поведения объектов. Однако функционирование целого ряда систем основано на возможности выхода из отдельных состояний с
7.1. Состояние действия
7.1. Состояние действия Состояние действия (action state) является специальным случаем состояния с некоторым входным действием и по крайней мере одним выходящим из состояния переходом. Этот переход неявно предполагает, что входное действие уже завершилось. Состояние действия
Физическое и эмоциональное состояние
Физическое и эмоциональное состояние Казалось бы, очевидная вещь, хорошее физическое и эмоциональное состояние позволяет работать на порядок лучше, меньше уставать, быть более сконцентрированным. Это вроде бы все понимают, и, в то же время, только единицы уделяют этим
Состояние и версия записи
Состояние и версия записи Каждый объект DataRow имеет свойство RowState, которое обозначает текущее состояние или статус записи. Кроме того, каждая запись хранит информацию о четырех разных версиях своего значения. По мере редактирования записи изменяется ее состояние и версия
Статическое состояние
Предыдущее состояние дел
Состояние готовности
Состояние готовности Наконец, нужно гарантировать, что при снятии указателя мыши с пункта меню пользователем в первой текстовой панели не останется «старая» подсказка, а будет отображено некоторое «типовое» сообщение (например: «Ожидание действий пользователя»). В текущем
8.4. Состояние планировщика событий
4.4.1. Состояние гонки
4.4.1. Состояние гонки Предположим, что в программу поступает группа запросов, которые обрабатываются несколькими одновременными потоками. Очередь запросов представлена связанным списком объектов типа struct job.Когда каждый поток завершает свою операцию, он обращается к
Состояние
Состояние Триггер может быть активным (active) или неактивным (inactive). Запускаются только активные триггеры. См. замечания к ALTER TRIGGER по поводу подробностей деактивации
Устранение проблем нехватки портов
Протоколы TCP и UDP работают на основе номеров портов, используемых для установления подключения. Любому приложению или службе, необходимой для установления подключения TCP/UDP, потребуется порт на его стороне.
Существует два типа портов:
Клиенты при подключении к приложению или службе будут использовать эфемерный порт из его машины для подключения к известному порту, определенному для этого приложения или службы. Браузер на клиентской машине будет использовать эфемерный порт для подключения к https://www.microsoft.com порту 443.
В сценарии, в котором один и тот же браузер создает много подключений к нескольким веб-сайтам, для любого нового подключения, которое пытается использовать браузер, используется эфемерный порт. Через некоторое время вы заметите, что подключения начнут сбой и одна высокая возможность для этого будет потому, что браузер использовал все доступные порты для подключения за пределами и любые новые попытки установить подключение не удастся, так как нет более доступных портов. Когда все порты на компьютере используются, мы используем его как истощение порта.
Динамический диапазон порта по умолчанию для TCP/IP
Чтобы соответствовать рекомендациям управления номерами, заданными в Интернете, Корпорация Майкрософт увеличила динамический диапазон клиентских портов для исходяющих подключений. Новый порт запуска по умолчанию — 49152, а конечный порт по умолчанию — 65535. Это изменение конфигурации более ранних версий Windows, которые использовали диапазон портов по умолчанию от 1025 до 5000.
Динамический диапазон порта можно просмотреть на компьютере с помощью следующих команд сетки:
Диапазон устанавливается отдельно для каждого транспорта (TCP или UDP). Диапазон порта теперь — это диапазон, который имеет отправную точку и конечную точку. Клиенты Корпорации Майкрософт, развертывавшие серверы, работающие Windows Server, могут иметь проблемы, влияющие на связь RPC между серверами, если брандмауэры используются во внутренней сети. В этих ситуациях рекомендуется перенастроить брандмауэры, чтобы разрешить трафик между серверами в динамическом диапазоне портов от 49152 до 65535. Этот диапазон помимо известных портов, используемых службами и приложениями. Или диапазон портов, используемый серверами, может быть изменен на каждом сервере. Этот диапазон можно настроить с помощью команды netsh следующим образом. Вышеуказанная команда задает динамический диапазон порта для TCP.
Порт запуска — это число, а общее число портов — диапазон. Ниже приводится пример команд:
Эти примерные команды устанавливают динамический диапазон портов для запуска в порте 10000 и окончания в порте 10999 (1000 портов). Минимальный диапазон портов, который можно установить, — 255. Минимальный порт запуска, который можно установить, — 1025. Максимальный конечный порт (в зависимости от настраиваемого диапазона) не может превышать 65535. Чтобы повторить поведение Windows Server 2003, используйте 1025 в качестве порта запуска, а затем используйте 3976 в качестве диапазона для TCP и UDP. Это приводит к запуску порта 1025 и конечного порта 5000.
В частности, для исходящие подключения в качестве входящих подключений не потребуется эфемерный порт для приемки подключений.
Так как исходящие подключения начинают сбой, вы увидите много ниже поведения:
Не удается войти в машину с учетными данными домена, однако вход с локальной учетной записью работает. Для регистрации домена потребуется связаться с dc для проверки подлинности, которая снова является исходящие подключения. Если у вас есть набор учетных данных кэша, вход в домен может по-прежнему работать.
Сбои обновления групповой политики:
Недоступными являются файлы:
RDP с пострадавшего сервера не удается:
Любое другое приложение, запущенное на компьютере, начнет выдать ошибки
Перезагрузка сервера позволит решить проблему временно, но все симптомы будут возвращаться через некоторое время.
Если вы подозреваете, что машина находится в состоянии истощения порта:
Попробуйте сделать исходящие подключения. На сервере/компьютере можно получить доступ к удаленной совместной информации или попробовать RDP на другом сервере или telnet на сервере в порту. Если исходящие подключения не удается для всех этих, перейдите к следующему шагу.
Откройте для просмотра событий и в системных журналах и посмотрите события, которые четко указывают текущее состояние:
Event ID 4227
ID события 4231
После изящного закрытия сеанса или внезапного закрытия сеанса через 4 минуты (по умолчанию) порт, используемый для этого процесса или приложения, будет выпущен обратно в доступный пул. В течение 4 минут состояние подключения TCP будет TIME_WAIT состояние. В ситуации, когда вы подозреваете истощение порта, приложение или процесс не смогут освободить все потребляемые порты и останутся в TIME_WAIT состоянии.
Вы также можете CLOSE_WAIT подключений состояния в одном и том же выходе, однако CLOSE_WAIT состояние — это состояние, когда одна сторона одноранговой сети TCP не имеет больше данных для отправки (fin sent), но может получать данные с другого конца. Это состояние не обязательно указывает на исчерпание порта.
Наличие огромных подключений в TIME_WAIT состоянии не всегда указывает на то, что сервер в настоящее время находится вне портов, если первые две точки не будут проверены. Наличие многких подключений TIME_WAIT указывает на то, что процесс создает большое количество подключений TCP и в конечном итоге может привести к исчерпанию порта.
До 10/2016 netstat был неточным. Исправления для netstat, от порта до 2012 R2, позволили Netstat.exe и Get-NetTcpConnection правильно сообщать об использовании порта TCP или UDP в Windows Server 2012 R2. Дополнительные Windows Server 2012 см. в Windows Server 2012 R2: hotfixes ephemeral ports.
Откройте командную подсказку в режиме администрирования и запустите приведенную ниже команду
Откройте файл server.etl с помощью сетевого монитора и в разделе фильтра применяйте фильтр Wscore_MicrosoftWindowsWinsockAFD.AFD_EVENT_BIND. Status.LENTStatus.Code == 0x209. Вы должны увидеть записи, которые говорят STATUS_TOO_MANY_ADDRESSES. Если вы не найдете записей, сервер по-прежнему не выходит из портов. Если их найти, можно подтвердить, что сервер находится под истощением порта.
Устранение неполадок в истощении порта
Главное — определить, какой процесс или приложение использует все порты. Ниже приведены некоторые средства, которые можно использовать для изоляции одного процесса
Метод 1
Большинство утечек портов вызваны процессами пользовательского режима, которые неправильно закрывают порты, когда произошла ошибка. В портах уровня пользователя (на самом деле розетки) обрабатываются. И TaskManager, и ProcessExplorer могут отображать подсчеты обработки, что позволяет определить, какой процесс потребляет все порты.
Для Windows 7 и Windows Server 2008 R2 можно обновить версию PowerShell, чтобы включить вышеуказанный список.
Метод 2
Если метод 1 не помогает определить процесс (до Windows 10 и Windows Server 2012 R2), то посмотрите на диспетчер задач:
Добавьте столбец под названием «ручки» под сведениями и процессами.
Сортировать ручки столбца, чтобы определить процесс с самым большим числом рули. Обычно виновником может быть процесс с ручками более 3000, за исключением таких процессов, как System, lsass.exe, store.exe, sqlsvr.exe.
Если какой-либо другой процесс имеет более высокое число, остановите этот процесс, а затем попробуйте войти с помощью учетных данных домена и узнайте, удастся ли ему это сделать.
Метод 3
Если диспетчер задач не помог вам определить процесс, используйте Обозреватель процессов для изучения проблемы.
Действия по использованию проводника процесса:
Скачайте Explorer процесса и запустите его с повышенными уровнями.
Alt + щелкните заглавную колонку, выберите Выберите столбцыи на вкладке Производительность процесса добавьте количество обработок.
Выберите Представление \ Показать нижнюю области.
Выберите Представление \ Представление нижней области \ Ручки.
Щелкните столбец Ручки для сортировки по этому значению.
Изучите процессы с более высоким количеством обрабатываемой обработки, чем остальные (если вы не можете сделать исходящие подключения более 10 000).
Щелкните, чтобы выделить один из процессов с высоким количеством обработки.
В нижней области окантовки, указанные ниже, являются розетками. (Sockets — это технически обработки файлов).
Некоторые из них являются нормальными, но большое число из них не являются (от сотен до тысяч). Закрой процесс, о чем идет речь. Если это восстанавливает исходящие подключения, то вы еще раз доказали, что это приложение является причиной. Свяжитесь с поставщиком этого приложения.
Наконец, если вышеперечисленные методы не помогли изолировать процесс, предлагаем собрать полную свалку памяти машины в состоянии проблемы. При сбросе будет посвеяно, какой процесс имеет максимальные ручки.
В качестве обходного решения перезагрузка компьютера возвращает его в нормальное состояние и поможет вам решить проблему в настоящее время. Однако при нецелесообразной перезагрузке можно также рассмотреть возможность увеличения количества портов на машине с помощью нижеупомяг.
В этом случае динамический диапазон портов будет начинаться в порту 10000 и заканчивается в порте 10999 (1000 портов). Минимальный диапазон портов, который можно установить, — 255. Минимальный порт запуска, который можно установить, — 1025. Максимальный конечный порт (в зависимости от настраиваемого диапазона) не может превышать 65535.
Обратите внимание, что увеличение динамического диапазона портов является не постоянным решением, а временным. Вам потребуется отслеживать, какие процессы и процессоры потребляют максимальное количество портов и устраняют неполадки с точки зрения этого процесса, чтобы понять, почему он потребляет такое большое количество портов.
Для Windows 7 и Windows Server 2008 R2 можно использовать ниже скрипт для сбора вывода netstat с определенной частотой. Из выходных данных можно увидеть тенденцию использования порта.