close wait что это

Close wait что это

Утилита netstat или как определить какие порты слушает ваш компьютер. Сетевые утилиты 4 часть-01

Всем привет ранее я начал рассказ про сетевые утилиты системного администратора в статье «Утилита pathping или как диагностировать проблему на маршруте до сайта. Сетевые утилиты 3 часть», движемся дальше и разбираем еще одну утилиту netstat или, как определить какие порты слушает ваш компьютер. Данная программка, будет не заменимым инструментом в багаже софта, любого системного инженера, поможет ему провести быструю диагностику ситуации и обнаружить ряд всевозможных проблем с сервисами и их доступностью.

Команды netstat

Представим ситуацию вы установили например MSM LSI утилиту для просмотра параметров RAID контроллера, запускаете утилиту, но ничего она не находит, потому что закрыт порт а какой вы не в курсе, и не всегда в инете можно быстро найти информацию об этом, для этого вы и может запустить netstat и посмотреть какой порт слушает ваш сервер с MSM процессом.

Утилита netstat или как определить какие порты слушает ваш компьютер. Сетевые утилиты 4 часть-02

Отображение статистики протокола и текущих сетевых подключений TCP/IP.

NETSTAT [-a] [-b] [-e] [-f] [-n] [-o] [-p протокол] [-r] [-s] [-x] [-t]
[интервал]

Давайте посмотрим интересные ключи утилиты netstat. Первое что вводим

и у нас на экране появится статистика сетевых пакетов ethernet.

Утилита netstat или как определить какие порты слушает ваш компьютер. Сетевые утилиты 4 часть-03

Утилита netstat или как определить какие порты слушает ваш компьютер. Сетевые утилиты 4 часть-04

Утилита netstat или как определить какие порты слушает ваш компьютер. Сетевые утилиты 4 часть-05

Очень полезно посмотреть все что слушает ваш хост для этого пишем

Вывод команды содержит Тип протокола либо TCP либо UDP, локальный адрес с портом который слушается и внешний адрес с портом и состояние действия.

Для полного понимания информации, предоставляемой этой командой, необходимо понять принципы установки соединения в протоколе TCP/IP. Вот основные этапы процесса установки соединения TCP/IP:

1. При попытке установить соединение клиент отправляет сообщение SYN серверу.

2. Сервер отвечает собственным сообщением SYN и подтверждением (ACK).

Процесс разрыва соединения состоит из следующих этапов:

1. Клиент сообщает «Я закончил», отправляя сообщение FIN серверу. На этом этапе клиент только принимает данные от сервера, но сам ничего не отправляет.

2. После этого сервер отправляет сообщение ACK и отправляет собственное сообщение FIN клиенту.

3. После этого клиент отправляет сообщение ACK серверу, подтверждая запрос сервера FIN.

4. При получении сообщения ACK от клиента сервер закрывает соединение.

Понимание этапов процесса установки и разрыва соединения позволяет более прозрачно интерпретировать состояния соединений в выводе команды netstat. Соединения в списке могут находиться в следующих состояниях.

Утилита netstat или как определить какие порты слушает ваш компьютер. Сетевые утилиты 4 часть-06

Утилита netstat или как определить какие порты слушает ваш компьютер. Сетевые утилиты 4 часть-07

также можно вывести только TCP порты

Утилита netstat или как определить какие порты слушает ваш компьютер. Сетевые утилиты 4 часть-08

Утилита netstat или как определить какие порты слушает ваш компьютер. Сетевые утилиты 4 часть-09

Вот такая вот полезная утилиты с которой вы всегда будите знать по каким портам общаются службы на хосте. Читайте далее Утилита TCPView. Как определить какие порты слушает ваш компьютер. Сетевые утилиты 5 часть

6 Responses to Утилита netstat или как определить какие порты слушает ваш компьютер. Сетевые утилиты 4 часть

thank you very much, would you weird area for any designers to hide this setting up. i had been possessing a number of difficulties with a new Dreamhost machine and i had not been guaranteed the reason why works out which they modify demonstrating invisible documents automagically, whereas different hosting space we connect to together with Filezilla appear to indicate invisible documents automagically. your own personal article allowed me to figure it available, i really appreciate it.

Уважаемый Иван, большое спасибо, это отличная получилась статья! У меня все получилось.

Очень рад, что смог вам помочь!

Добрый день. А как узнать какая программа занимает 80 порт?

Очень просто вы через netstat или tcpView смотрите PID процесса, который висит на порту, далее по PID вычисляете исполняемый файл.

>Добрый день. А как узнать какая программа занимает 80 порт?

Источник

Не понял, кого убиваем по ctrl-c? Если сервер, то не должно быть так, net/ipv4/tcp.c:tcp_close() переведет в TCP_LAST_ACK если были в TCP_CLOSE_WAIT. Если убит клиент, то это нормально, и ошибка в сервере. Он должен закрыть socket. Полезно посмотреть на сессию tcpdump’ом, посылает ли сервер FIN+ACK?

Это не на сервере. Это фишка tcp\ip. Он будет ожидать еще некоторое время пакеты, которые могли еще не дойти серверу посли того как ты его отключил. Это сделано для устойчивости клиентов, и чтоб rst лишний раз не слать, прочитай RFC или книжку по TCP_IP. И еще ты уверен что там не TIME_WAIT?

Нет, SO_REUSEADDR совсем не для того придумано. Это для борьбы с EADDRINUSE в случае, если делается bind() на локальный порт, а на этом порту уже есть connected socket. Например, в состоянии TIME_WAIT. После bind() флаг никак не меняет поведение socket’а.

Пардон пардон, не заметил, что hvv написал «-1 или 0».

hvv: ну нет такого файла (и каталога) в 2.20, я даже grep’ом искал в исходниках. Может, патчи какие стоят? А что еще в этом каталоге у тебя?

Источник

&nbsp &nbsp Команда NETSTAT предназначена для получения сведений о состоянии сетевых соединений и слушаемых на данном компьютере портах TCP и UDP, а также, для отображения статистических данных по сетевым интерфейсам и протоколам.

Формат командной строки:

NETSTAT [-a] [-b] [-e] [-f] [-n] [-o] [-p протокол] [-r] [-s] [-t] [интервал]

Параметры командной строки:

На практике, утилиту netstat.exe удобно использовать в цепочке с командами постраничного вывода ( more ), перенаправления стандартного вывода в файл ( > ) и поиска текста в результатах вывода ( find ).

Пример отображаемой информации:

Состояние
LISTENING
LISTENING
ESTABLISHED
ESTABLISHED

Внешний адрес Внешний IP-адрес, участвующий в создании соединения.

TCP 192.168.0.3:3389 89.22.52.11:5779 ESTABLISHED
CryptSvc
[svchost.exe]

Байт
Одноадресные пакеты
Многоадресные пакеты
Отброшено
Ошибки
Неизвестный протокол Получено

3572722456
73723923
15666
0
0
0 Отправлено

516793893
75953549
1091239
0
0
0

Байт
Одноадресные пакеты
Многоадресные пакеты
Отброшено
Ошибки
Неизвестный протокол Получено

3748575434
76249208
15694
0
0
0 Отправлено

1576644689
79843939
1094958
0
0
0

Получено пакетов
Получено ошибок в заголовках
Получено ошибок в адресах
Направлено датаграмм
Получено неизвестных протоколов
Отброшено полученных пакетов
Доставлено полученных пакетов
Запросов на вывод
Отброшено маршрутов
Отброшено выходных пакетов
Выходных пакетов без маршрута
Требуется сборка
Успешная сборка
Сбоев при сборке
Успешно фрагментировано датаграмм
Сбоев при фрагментации датаграмм
Создано фрагментов

= 10877781
= 0
= 27307
= 0
= 0
= 448
= 11384479
= 11919871
= 0
= 1517
= 6
= 0
= 0
= 0
= 5918
= 0
= 11836

= 0
= 0
= 0
= 0
= 0
= 0
= 391
= 921
= 0
= 0
= 14
= 0
= 0
= 0
= 0
= 0
= 0

Сообщений
Ошибок
‘Назначение недостижимо’
Превышений времени
Ошибок в параметрах
Просьб «снизить скорость»
Переадресовано
Ответных пакетов
Эхо-сообщений
Отметок времени
Ответы на отметки времени
Масок адресов
Ответов на маски адресов
Маршрутизатор
Маршрутизатор

Получено
11892
0
10461
613
0
0
0
818
0
0
0
0
0
0
0

Отправлено
1374
0
528
0
0
0
0
0
846
0
0
0
0
0
0

Статистика TCP для IPv4

Сообщений
Ошибок
‘Назначение недостижимо’
Пакет слишком велик
Превышений времени
Ошибок в параметрах
Эхо-сообщений
Ответных пакетов
MLD-запросы
MLD-отчеты
MLD выполнено
Маршрутизатор
Маршрутизатор
Окружение
Окружение
Переадресовано
Перенумер. маршрутизатора

Получено
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0

Отправлено
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0

Активных открыто
Пассивных открыто
Сбоев при подключении
Сброшено подключений
Текущих подключений
Получено сегментов
Отправлено сегментов
Повторно отправлено сегментов

= 225128
= 12675
= 108237
= 1871
= 42
= 8606912
= 8138192
= 403595

Статистика TCP для IPv6

= 64
= 64
= 10164
= 4
= 4
= 3341
= 3341
= 0

Статистика UDP для IPv4

Получено датаграмм
Отсутствие портов
Ошибки при получении
Отправлено датаграмм

= 4714809
= 448
= 0
= 5332065

Статистика UDP для IPv6

Получено датаграмм
Отсутствие портов
Ошибки при получении
Отправлено датаграмм

= 419
= 0
= 0
= 391

Пример отображаемых статистических данных:

Получено
12092
0
10654
619
0
0
0
819
0
0
0
0
0
0
0

Отправлено
1375
0
528
0
0
0
0
0
847
0
0
0
0
0
0

Для циклического опроса состояния сетевых соединений используется запуск программы с указанием интервала вывода статистических данных в секундах.

Источник

Устранение неполадок соединений, застрявших в состоянии ожидания CLOSE

У меня есть приложение Java, работающее в WebLogic 11g на Windows, которое через несколько дней перестает отвечать. Один подозрительный симптом, который я заметил, заключается в том, что большое количество соединений (около 3000) появляется в netstat со статусом CLOSE_WAIT, даже когда сервер простаивает. Поскольку сервер приложений управляет клиентскими подключениями, я не уверен, что это вызывает. Мы также делаем несколько вызовов веб-служб, которые возвращаются на тот же сервер, но я считаю, что эти соединения получают правильно закрыт. Что еще может вызвать это и как можно устранить такую проблему?

6 ответов

у меня была такая же проблема, и я изучал сокеты, чтобы избавиться от этой проблемы.

позвольте мне сказать несколько слов, но прежде я должен сказать, что я не программист Java.

Я не буду объяснять, что такое close_wait, так как Брайан Уайт уже сказал Все, что нужно сказать.

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

вы должны избежать этого, сделав несколько вещей.

1-Если ваше клиентское приложение не использует протокол http 1.1, вы должны установить его для использования из-за ‘keep-alive опция заголовка http.

2-Если клиент работает с http 1.1 и это не работает, или, если вы должны использовать http 1.0, вы должны установить соединение свойство заголовка запроса:

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

и да, у вас могут возникнуть проблемы, когда у вас много close_waits или time_waits на стороне сервера.

Я надеюсь, это было полезно. С этими вещами мне удалось решить свою проблему.

когда удаленный хост закрывается( отправляет FIN), ваше локальное приложение получит какое-то событие (это событие» чтения » на сокет в базовой библиотеке C), но чтение из этого соединения вернет ошибку, чтобы указать, что соединение закрыто. На этом этапе локальное приложение должно закрыть соединение.

Я мало знаю о Java и ничего о WebLogic, но я полагаю, что возможно, что приложение не обрабатывает ошибку чтения должным образом и, таким образом, никогда не закрывает соединение.

на CLOSE_WAIT статус означает, что другая сторона инициировала закрытие соединения, но приложение на локальной стороне еще не закрыло сокет.

похоже, у вас есть ошибка в вашем локальном приложении.

проблема заключалась в ошибке, вызванной установкой» Use JSSE SSL » в true в webLogic. Использование собственной реализации SSL WebLogic вместо JSSE не является проблемой для нашего приложения, поэтому я просто снял эту настройку, и проблема исчезла.

Я нашел эту цитату о close_wait pileups: «что-то либо мешает прогрессу происходят в сеансе HTTP (мы застряли, поэтому никогда не заканчиваем вызов close), или была введена ошибка, которая предотвращает закрытие сокета. Есть несколько способов это может произойти.»

подумайте: есть ли способ, которым ваше приложение может застрять при обработке запроса? Или сама WebLogic?

Examine: можете ли вы сделать Java-дампы потоков (kill-SIGQUIT может быть используется для этого в Oracle JVM для Linux), чтобы попытаться увидеть, действительно ли какой-либо из ваших потоков застревает?

Проверьте клиентскую сторону: Во-первых, узнайте IP-адрес или имя хоста клиентов, которые подключены к сокетам CLOSE_WAIT. Затем посмотрите, не происходит ли что-нибудь подозрительное с этими клиентами.

Источник

Русские Блоги

Анализ статуса 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 для принудительного Связь закрыта.

Источник

close wait что это