tcp time wait что значит
Печенюшка
Протокол 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 по поводу подробностей деактивации
3 необычных кейса о сетевой подсистеме Linux
В этой статье представлены три небольшие истории, которые произошли в нашей практике: в разное время и в разных проектах. Объединяет их то, что они связаны с сетевой подсистемой Linux (Reverse Path Filter, TIME_WAIT, multicast) и иллюстрируют, как глубоко зачастую приходится анализировать инцидент, с которым сталкиваешься впервые, чтобы решить возникшую проблему… и, конечно, какую радость можно испытать в результате полученного решения.
История первая: о Reverse Path Filter
Клиент с большой корпоративной сетью решил пропускать часть своего интернет-трафика через единый корпоративный файрвол, расположенный за маршрутизатором центрального подразделения. С помощью iproute2 трафик, уходящий в интернет, был направлен в центральное подразделение, где уже было настроено несколько таблиц маршрутизации. Добавив дополнительную таблицу маршрутизации и настроив в ней маршруты перенаправления на файрвол, мы включили перенаправление трафика из других филиалов и… трафик не пошел.
Схема прохождения трафика через таблицы и цепочки Netfilter
Начали выяснять, почему не работает настроенная маршрутизация. На входящем туннельном интерфейсе маршрутизатора трафик обнаруживался:
Однако на исходящем интерфейсе пакетов не было. Стало ясно, что фильтруются они на маршрутизаторе, однако явно установленных правил отбрасывания пакетов в iptables не было. Поэтому мы начали последовательно, по мере прохождения трафика, устанавливать правила, отбрасывающие наши пакеты и после установки смотреть счетчики:
Проверили последовательно nat PREROUTING, mangle PREROUTING. В mangle FORWARD счетчик не увеличивался, а значит — пакеты теряются на этапе маршрутизации. Проверив снова маршруты и правила, начали изучать, что именно происходит на этом этапе.
В ядре Linux для каждого интерфейса по умолчанию включен параметр Reverse Path Filtering ( rp_filter ). В случае, когда вы используете сложную, асимметричную маршрутизацию и пакет с ответом будет возвращаться в источник не тем маршрутом, которым пришел пакет-запрос, Linux будет отфильтровывать такой трафик. Для решения этой задачи необходимо отключить Reverse Path Filtering для всех ваших сетевых устройств, принимающих участие в маршрутизации. Чуть ниже простой и быстрый способ сделать это для всех имеющихся у вас сетевых устройств:
Возвращаясь к кейсу, мы решили проблему, отключив Reverse Path Filter для интерфейса tap0 и теперь хорошим тоном на маршрутизаторах считаем отключение rp_filter для всех устройств, принимающих участие в асимметричном роутинге.
История вторая: о TIME_WAIT
В обслуживаемом нами высоконагруженном веб-проекте возникла необычная проблема: от 1 до 3 процентов пользователей не могли получить доступ к сайту. При изучении проблемы мы выяснили, что недоступность никак не коррелировала с загрузкой любых системных ресурсов (диск, память, сеть и т.д.), не зависела от местоположения пользователя или его оператора связи. Единственное, что объединяло всех пользователей, которые испытывали проблемы, — они выходили в интернет через NAT.
Механизм закрытия TCP-соединения
И выполните команду:
История третья: об OSPF и мультикастовом трафике
Обслуживаемая корпоративная сеть была построена на базе tinc VPN и прилегающими к ней лучами IPSec и OVPN-соединений. Для маршрутизации всего этого адресного пространства L3 мы использовали OSPF. На одном из узлов, куда агрегировалось большое количество каналов, мы обнаружили, что небольшая часть сетей, несмотря на верную конфигурацию OSPF, периодически пропадает из таблицы маршрутов на этом узле.
Упрощенное устройство VPN-сети, используемой в описываемом проекте
В первую очередь проверили связь с маршрутизаторами проблемных сетей. Связь была стабильной:
Продиагностировав OSPF, мы удивились еще больше. На узле, где наблюдались проблемы, маршрутизаторы проблемных сетей отсутствовали в списке соседей. На другой стороне проблемный маршрутизатор в списке соседей присутствовал:
Следующим этапом исключили возможные проблемы с доставкой ospf hello от 172.24.0.1. Запросы от него приходили, а вот ответы — не уходили:
Заключение
Какой бы сложной ни была проблема, она всегда решаема и зачастую — с помощью изучения документации. Буду рад увидеть в комментариях описание вашего опыта поиска решения сложных и необычных проблем.
Русские Блоги
Анализ статуса TCP TIME_WAIT и решение проблем
1. ПТС четыре раза махнул
TCP требует рукопожатия при установлении соединения, и аналогично ему также требуется рукопожатие при закрытии соединения.
Поскольку TCP-соединение является двунаправленным, при закрытии соединения необходимо закрыть оба направления. Сторона, отправляющая пакет FIN, сначала выполняет активное завершение работы, а сторона, отправляющая пакет FIN, позже выполняет пассивное завершение работы. Сторона, которая активно закрывается, перейдет в состояние TIME_WAIT и останется в этом состоянии в течение 2MSL.
Для MSL это означает максимальное время жизни сегмента сообщения. Если сегмент сообщения был активен в сети в течение времени MSL и не был получен, он будет отброшен. Что касается размера MSL, то в протоколе RFC 793 рекомендация составляет 2 минуты, но в Linux это обычно полминуты.
Для состояния TIME_WAIT есть следующая картина:
Мы ориентируемся на несколько концепций:
Условия генерации TIME_WAIT: Активная закрывающая сторона перейдет в состояние TIME_WAIT после четырехкратной отправки последнего ACK с продолжительностью 2MSL (MSL в Linux составляет 30 секунд и не настраивается).
TIME_WAIT продолжает роль двух MSL: Во-первых, надежно и безопасно закройте TCP-соединение. Например, если сеть перегружена, если последний ACK активной закрывающей стороны не получен пассивной закрывающей стороной, то пассивная закрывающая сторона будет повторно передавать FIN с течением времени. В это время незакрытый TIME_WAIT будет иметь дело с этими хвостовыми проблемами. Влияние на новые подключения и другие услуги. Во-вторых, для предотвращения установления нового TCP-соединения из-за отсутствия непрерывного времени TIME_WAIT задержанный пакет повторной передачи FIN будет мешать новому соединению.
Ресурсы, занятые TIME_WAIT: Небольшой объем памяти (около 4К) и файловый дескриптор fd.
Вред от закрытия TIME_WAIT: Во-первых, когда состояние сети плохое, если у активной стороны нет ожидания TIME_WAIT, после закрытия предыдущего соединения активная сторона и пассивная сторона устанавливают новое TCP-соединение, а затем пассивная сторона повторно передает или прибывает задержанный пакет FIN Затем это напрямую повлияет на новое TCP-соединение; во-вторых, когда состояние сети плохое и в то же время нет ожидающего TIME_WAIT, нового соединения после закрытия соединения нет, тогда, когда пассивная сторона повторно передает или получен задержанный пакет FIN, он будет отправлен пассивной стороне. Отправка пакета RST может повлиять на другие сервисные соединения на пассивной стороне.
TCP: time wait bucket table overflow Причины и последствия: Причина в том, что количество TIME_WAIT превышает порог количества TW в системе Linux. Вред состоит в том, что после превышения порога система удалит избыточный сокет TIME_WAIT и отобразит предупреждающее сообщение. Если это сеть NAT и имеется большое количество доступов, различные соединения будут нестабильными и отключаться.
2. Оптимизация и настройка соответствующих параметров.
1. tcp_tw_recycle
Как следует из названияВосстановить соединение TIME_WAIT, Можно сказать, что этот параметр ядра стал панацеей для обработки TIME_WAIT. Если вы ищете решение TIME_WAIT в Интернете, вы порекомендуете установить его во всех случаях, но есть ловушка, которую нелегко обнаружить: когда несколько клиентов проходят Когда режим NAT подключен к сети и взаимодействует с сервером, сервер видит тот же IP-адрес, что означает, что эти клиенты фактически эквивалентны одному для сервера. Поскольку временные метки этих клиентов могут быть разными, сервер С конечной точки зрения, отметка времени может быть неупорядоченной, что напрямую приводит к тому, что пакет с маленькой отметкой времени отбрасывается. Ссылка: tcp_tw_recycle и tcp_timestamps вызывают сбой подключения.
Примечания:Рекомендуется не включать эту опцию. В настоящее время часто используется Internet NAT, что может привести к невозможности проведения трехстороннего рукопожатия.。
После открытия TIME_WAIT восстанавливается в пределах 3,5 * RTO (время RTO рассчитывается на основе времени RTT), а временная метка в запросе подключения к сокету того же исходного IP-хоста в течение 60 секунд должна быть увеличена. Для сервера тот же исходный IP-адрес может быть За NAT находится много машин. Приращение отметки времени на этих машинах не может быть гарантировано. Сервер отклоняет неинкрементные запросы на соединение, что напрямую приводит к сбою трехстороннего рукопожатия.
2. tcp_tw_reuse
Как следует из названияПовторно использовать соединение TIME_WAIT, При создании нового соединения, если возможно, рассмотрите возможность повторного использования соответствующего соединения TIME_WAIT. обычно думаю tcp_tw_reuse соотношение tcp_tw_recycle Это безопаснее, потому что, во-первых, время создания TIME_WAIT должно превышать одну секунду, прежде чем его можно будет повторно использовать; во-вторых, оно будет повторно использоваться только при увеличении метки времени соединения. В официальном документе сказано: если это безопасно с точки зрения протокола, его можно использовать. Это просто дипломатическая риторика! На мой взгляд, если сеть относительно стабильна, например, она подключена к интранету, то вы можете попробовать ее использовать.
Но что требует внимания, так это то, где его использовать. Поскольку мы хотим повторно использовать соединение, его, конечно же, следует использовать на инициаторе соединения, а не на подключенной стороне. Например: клиент инициирует HTTP-запрос к серверу, и сервер активно закрывает соединение после ответа, поэтому TIME_WAIT остается на сервере. Используйте в этом случае tcp_tw_reuse Недопустимый, потому что сервер является подключенной стороной, поэтому повторное использование подключения отсутствует. Давайте немного расширим его. Например, если сервером является PHP, он запрашивает другой сервер MySQL, а затем активно отключается, поэтому TIME_WAIT приходится на сторону PHP. Используйте в таких случаях tcp_tw_reuse Эффективен, поскольку PHP в настоящее время является клиентом по отношению к MySQL, он является инициатором соединения, поэтому соединение можно использовать повторно.
Описание:Если вы используете tcp_tw_reuse, активируйте tcp_timestamps, иначе он будет недействительным.。
3. tcp_max_tw_buckets
Как следует из названияКонтролировать общее количество TIME_WAIT, В официальном документе веб-сайта говорится, что эта опция предназначена только для предотвращения некоторых простых DoS-атак и обычно не снижает ее искусственно. Если он будет уменьшен, система удалит избыточный TIME_WAIT, и журнал покажет: TCP: time wait bucket table overflow 。
Я должен напомнить всем, что все должно быть поменяно местами. Я видел, как кто-то установил «tcp_max_tw_buckets» на 0, то есть полностью отказался от TIME_WAIT. Это немного рискованно. Чтобы использовать пословицу Go, лучше переходить границу медленно.
Когда это появляется TCP: time wait bucket table overflow Когда, попробуйте увеличить следующие параметры:
Три, резюме
Иногда, если мы посмотрим на проблему с другой стороны, мы часто можем получить эффект двух или двух. Вышеупомянутый пример: клиент инициирует HTTP-запрос к серверу, и сервер активно закрывает соединение после ответа, поэтому TIME_WAIT остается на сервере. Ключевым моментом здесь является то, что именно сервер активно закрывает соединение!При закрытии TCP-соединения первая сторона обречена избежать участи TIME_WAIT., Перефразируя лирику: оставь мою печаль себе, твоя красота пусть заберет. Если клиент управляемый, то включите KeepAlive на сервере и постарайтесь не позволять серверу активно закрывать соединение, и позвольте клиенту активно закрывать соединение, так что проблема будет решена.
Четыре, дополнение
Введение в RST：
В протоколе TCP RST означает сброс и используется для закрытия ненормальных соединений.При отправке пакета RST для закрытия соединения вам не нужно ждать, пока все пакеты данных в буфере будут отправлены, а пакеты данных в буфере будут напрямую отброшены и будет отправлен пакет RST. После получения пакета RST принимающей стороне не нужно отправлять пакет ACK для подтверждения.。
Несколько ситуаций, когда появляется RST:
Порт не открыт: Порт, не открытый клиентом, подключающимся к серверной программе. Когда клиент отправляет SYN-запрос на порт сервера, но порт не открыт на сервере, он отправляет RST клиенту. Однако не все операционные системы будут отправлять RST клиенту, и win7 просто проигнорирует сообщение SYN.
Получать данные о закрытом сокете: Если сокет был закрыт, но все еще получает данные, то также будет сгенерирован RST.
Когда в приемном буфере есть данные, закройте соединение: Когда запрашивающая сторона запрашивает данные и запрашивает закрытие соединения без обработки всех данных в буфере, запрашивающая сторона не отправляет пакет FIN, как ожидалось, и вводит 4-стороннюю логику закрытия, но может напрямую отправить пакет RST для принудительного Связь закрыта.
Устранение проблем нехватки портов
Протоколы 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 с определенной частотой. Из выходных данных можно увидеть тенденцию использования порта.