Почему UDP порты нельзя мониторить так же, как TCP?

Question

[Фролова]

Начала заниматься мониторингом инфраструктуры. До этого занималась только тестированием и понимаю, что сильно не хватает сетевого бэкграунда.
Например, я понимаю, в чем принципиальная разница между TCP и UDP (в первом наличествует установление соединения через хэндшэйк, второе работает без установления соединения).
Но как из этого следует то, что я просто могу взять и проверить, открыт или закрыт TCP-порт на удаленном хосте, но для UDP-порта я этого сделать не могу - не понимаю.
Напишите, пожалуйста, развернуто, а я куплю вам за это кофе (или два) :)

Comments

[shurshur]

Например, nmap по udp-портам может показывать статус open|filtered, потому что реально открытый порт от недоступного ничем не отличается по реакции.

[fdroid]

У меня есть шутка про UDP, но, боюсь, она до вас не дойдёт.

[shurshur]

fdroid, а шутку про TCP я повторю, если не дойдёт. Скажите, кому рассказывать шутки про IGMP?

Answer 1

[ky0]

Зачем вам мониторить открытость UDP-порта? Проверяйте работоспособность сервиса, который слушает этот порт - наличие запущенного процесса, корректный ответ на тестовый запрос и т. д.

Answer 2

[Алексей Черемисин]

Посылая UDP пакет, вы его посылаете в неизвестность. В отличии от TCP, где и для приемника, и для передатчика есть некий алгиритм поддержания и перепосылки пакетов.

Если ввести аналогию с бусинками, то UDP - кидание бусинок в корзину, где корзины может и не быть.
А TCP - спускание бусинок по протянутой веревочке. В этом случае, прежде чем спускать бусинки - нужно протянуть веревочку (handshake).

Веревочки считать легко, в отличии от одиночных бусинок.
Но в случае с UDP мы можем посчитать корзинки на принимающей стороне если ее кто-то поставил (открыл)

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

PS. Кофе мой?

Comments

[Фролова]

Т.е. если мы допускаем, что сеть надежна, UPD доходит всегда или почти всегда (а значит гарантия доставки нам уже не важна), то ничего не мешает чекать порт через тот же nmap?

[Алексей Черемисин]

Фролова, ну,
1) не всегда nmap может прочекать порт
2) сеть априори ненадежна
3) не только сеть определяет доставку, а еще и само наличие приёмника - он выключен например
4) с приемником может тоже твориться всякое, завис, сбоит, теряет пакеты
5) порт приемника может быть тупо перегружен, у передатчика порт 1гб, у приемника 10мб, посылаем на скорости интерфейса передатчика - пакеты уйдут, но по пути 90% просто пропадет!
6) ибо без хандшейка, окон, механизма блокировок, подтверждений доставки и прочей хрени, гарантировать ничего нельльзя!
7) есть еще куча всего, начиная от пересортицы пакетов (один пакет идет по одному маршруту, а лругой - по другому, разная задержка прохождения, посланный позжеипакет может прийти раньше) и заканчивая их переразбивкой на роутерах (MTU)

[Алексей Черемисин]

Как минимум нужно подтверждение доставки.

Answer 3

[Alexey Dmitriev]

Потому что в ответ на TCP пакет всегда приходит подтверждение, что он был доставлен, а в ответ на UDP - не приходит.
TCP - гарантированная доставка, UDP - нет.

Answer 4

[Талян]

ну как минимум вы можете проверить открыт ли порт с помощью хотя бы nmap
sudo nmap -sU 95.128.142.195 -p161

Comments

[Фролова]

Судя по другим ответам, нельзя, т.к. closed не будет однозначно говорить о том, что порт закрыт

Answer 5

[res2001]

Для проверки TCP порта достаточно просто открыть соединение, не посылая реальных данных, после чего сразу закрыть соединение. В этом случае проверяется прошел ли handshake или нет, если прошел - порт открыт.
В UDP стадии handshakе нет, поэтому вам нужно послать какие-то реальные данные, соответствующие протоколу обмена с сервером. Только в этом случае вы можете надеяться на то, что сервер что-то ответит. Если вы пошлете случайные данные, велик шанс, что даже если сервер слушает порт, он просто отбросит эти данные. Поэтому есть сложность с мониторингом UDP портов - вы должны знать какой сервис слушает порт и должны поддерживать протокол обмена с этим сервером.
И это помимо того, что в UDP нет гарантии доставки пакетов как от клиента так и от сервера.

Answer 6

[DDwrt100]

Это связанно с сессионостью TCP. В TCP прежде чем будут передаваться данные приложения протокол производит ряд служебных действий(handshake). Поэтому TCP можно проверить отправив Handshake , не передавая данных. При прохождении handshake мы можем судить с определнной веренностью что какое то приложение висит на этом порту(Кстати это не полноценная проверка приложения).
UDP сессионности нет. Поэтому мы можем его проверить если понимаем что должны послать и что получить в результате сетевого обмена. Служебной фазы в нем нет, как и сетевой сессии, из-за этого его сложнее проверять.

Answer 7

[Александр Карабанов]

Проверить, что доступен TCP порт 22
zend@zbook:~$ nc -zv 192.168.254.254 22
Connection to 192.168.254.254 22 port [tcp/ssh] succeeded!
Доступен.

Проверить, что доступен UDP порт 22
zend@zbook:~$ nc -zvu 192.168.254.254 22
Ничего не венруло - UDP порт 22 недоступен.
Проверим код возврата:
zend@zbook:~$ echo $?
1
Так как код возврата не 0 то UDP порт 22 недоступен (это для использования внутри скрипта например годитса)

Проверим что доступен UDP порт 53
zend@zbook:~$ nc -zvu 192.168.254.254 53
Connection to 192.168.254.254 53 port [udp/domain] succeeded!

Доступен.

Answer 8

[Николай]

На своём хосте вы можете проверить, открыт ли порт по UDP или нет, командой вроде netstat -ulpn.
На другом хосте - зависит от приложения. Если вы пошлёте на него UDP пакет, оно может ответить, а может и нет. Как правило, приложения ждут каких-то данных, и не отвечают на все UDP пакеты подряд, поэтому сканировать лучше с указанием payload'a для конкретного приложения (например, SIP INVITE).
Но если порт точно закрыт, система может прислать вам ICMP Port Unreachable (а может и не прислать - в зависимости от настроек на стороне хоста и его сети).
Команда nmap -sU может выводить 3 варианта состояния порта:
open - порт точно открыт (получен ответ от приложения)
open|filtered - неизвестно, ответ не пришёл (либо приложение не ответило, либо порт закрыт без выдачи Port Unreachable)
closed - порт точно закрыт (пришёл Port Unreachable)

Answer 9

[pfg21]

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