netstat time wait что это

question

TIME_WAIT from netstat

We have two 2012 window servers, let’s call them server A and server B. When server A was trying to connect server B, we found there were RPC error and TIME_WAIT from server B. We have tried change TcpTimeWaitDelay to 60 in registry and rebooted server B. But the problem still existed. Please help advise.

Just checking in to see if the information provided was helpful.

If yes, you may accept useful reply as answer, if not, welcome to feedback.

1 Answer

Thanks for posting in Q&A platform.

TCP TIME_WAIT is a normal TCP protocol operation, it means after delivering the last FIN-ACK, client side will wait for double maximum segment life (MSL) Time to pass to be sure the remote TCP received the acknowledgement of its connection termination request. By default, MSL is 2 minutes. For the maximum, it can stay in TIME_WAIT for 4 minutes known as two MSL.

Please refer to the following screenshot.

From Network perspective, TCP TIME_WAIT status is just a normal behavior that after closing the session, TCP stack will hold the high port for little more time to ensure the other side receive the last FIN-ACK packet and no more data will be received in this conversation. TIME_WAIT is not the problem. I would suggest you focus on RPC error for this issue.

For RPC error, common causes of RPC errors include:

Errors resolving a DNS or NetBIOS name.
The RPC service or related services may not be running.
number of connectivity Problems with network connectivity.
File and printer sharing is not enabled.

To narrow down the issue, I would suggest collect network traffic for further troubleshooting.

Please understand, analysis of network traffic is beyond our forum support level. I would suggest you open a case with Microsoft where more in-depth investigation can be done so that you would get a more satisfying explanation to this question.

You may find phone number for your region accordingly from the link below:

If the Answer is helpful, please click «Accept Answer» and upvote it.

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

Источник

Устранение проблем нехватки портов

Протоколы 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 с определенной частотой. Из выходных данных можно увидеть тенденцию использования порта.

Источник

Проблемы с очередью 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 (маркировки пакетов относительными временными метками).

Источник

netstat

Область применения: Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2, Windows Server 2012

Отображаются активные TCP-подключения, порты, на которых компьютер прослушивается, статистика Ethernet, таблица маршрутизации IP-адресов, статистика IPv4 (для протоколов IP, ICMP, TCP и UDP) и Статистика IPv6 (для протоколов IPv6, ICMPv6, TCP по IPv6 и UDP через IPv6). При использовании без параметров эта команда отображает активные TCP-подключения.

Эта команда доступна, только если протокол Internet Protocol (TCP/IP) установлен в качестве компонента в свойствах сетевого адаптера в окне Сетевые подключения.

Синтаксис

Параметры

Показывает соединения для протокола, заданного протоколом. В этом случае протоколом может быть TCP, UDP, TCPv6 или UDPv6. Если этот параметр используется вместе с -s для вывода статистики по протоколу, протокол может принимать значение TCP, UDP, ICMP, IP, tcpv6, udpv6, ICMPv6 или IPv6.-SОтображает статистику по протоколу. По умолчанию для протоколов TCP, UDP, ICMP и IP отображается статистика. Если установлен протокол IPv6, для протоколов TCP через IPv6, UDP через IPv6, ICMPv6 и IPv6 отображаются статистические данные. Параметр -p можно использовать для указания набора протоколов.-rОтображает содержимое таблицы IP-маршрутизации. Это эквивалентно команде Route Print.Повторно отображает выбранную информацию каждый интервал в секундах. Нажмите клавиши CTRL + C, чтобы прерывать повторное отображение. Если этот параметр не указан, эта команда выводит выбранные данные только один раз./?Отображение справки в командной строке.

Комментарии

Команда netstat предоставляет статистические данные по следующим параметрам:

Примеры

Чтобы отобразить статистику Ethernet и статистику для всех протоколов, введите:

Чтобы отобразить статистику только для протоколов TCP и UDP, введите:

Чтобы отобразить активные TCP-подключения и идентификаторы процессов каждые 5 секунд, введите:

Чтобы отобразить активные TCP-подключения и идентификаторы процессов в числовом формате, введите:

Источник

Огромное количество соединений TIME_WAIT говорит netstat

Это число быстро меняется.

У меня довольно плотный конфиг iptables, поэтому я понятия не имею, что может вызвать это. Любые идеи?

РЕДАКТИРОВАТЬ: tcp_fin_timeout не контролирует продолжительность TIME_WAIT, он жестко закодирован в 60 с

Как уже упоминалось, наличие некоторых подключений TIME_WAIT является нормальной частью TCP-соединения. Вы можете увидеть интервал, изучив /proc/sys/net/ipv4/tcp_fin_timeout :

И измените его, изменив это значение:

Или навсегда, добавив его в /etc/sysctl.conf

Кроме того, если вы не используете службу RPC или NFS, вы можете просто отключить ее:

И выключи его полностью

(Если, конечно, вы на самом деле не выполняете ничего, что должно обрабатывать столько операций RCP. Тогда беспокойтесь.)

Что-то в вашей системе выполняет много RPC (удаленных вызовов процедур) в вашей системе (обратите внимание, что источником и получателем является localhost). Это часто наблюдается для lockd для монтирования NFS, но вы также можете увидеть это и для других вызовов RPC, таких как rpc.statd или rpc.spray.

даже если для tcp_fin_timeout установлено значение 3, обратный отсчет для TIME_WAIT по-прежнему начинается с 60. Однако если для net.ipv4.tcp_tw_reuse установлено значение 1 ( echo 1 > /proc/sys/net/ipv4/tcp_tw_reuse ), то ядро ​​может повторно использовать сокеты в TIME_WAIT, если определит, что в TCP не будет никаких возможных конфликтов. нумерация сегментов.

Источник