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

 Начала заниматься мониторингом инфраструктуры. До этого занималась только тестированием и понимаю, что сильно не хватает сетевого бэкграунда.   

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

Но как из этого следует то, что я просто могу взять и проверить, открыт или закрыт TCP-порт на удаленном хосте, но для UDP-порта я этого сделать не могу - не понимаю.  

Напишите, пожалуйста, развернуто, а я куплю вам за это кофе (или два) :) 

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

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

  

Если ввести аналогию с бусинками, то UDP - кидание бусинок в корзину, где корзины может и не быть.   

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

  

Веревочки считать легко, в отличии от одиночных бусинок.  

Но в случае с UDP мы можем посчитать корзинки на принимающей стороне если ее кто-то поставил (открыл)  

  

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

  

PS. Кофе мой? 

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

TCP - гарантированная доставка, UDP - нет. 

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

`sudo nmap -sU 95.128.142.195 -p161` 

 Для проверки TCP порта достаточно просто открыть соединение, не посылая реальных данных, после чего сразу закрыть соединение. В этом случае проверяется прошел ли handshake или нет, если прошел - порт открыт.  

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

И это помимо того, что в UDP нет гарантии доставки пакетов как от клиента так и от сервера. 

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

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

 Проверить, что доступен 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!*  

  

Доступен. 

 На своём хосте вы можете проверить, открыт ли порт по UDP или нет, командой вроде netstat -ulpn.  

На другом хосте - зависит от приложения. Если вы пошлёте на него UDP пакет, оно может ответить, а может и нет. Как правило, приложения ждут каких-то данных, и не отвечают на все UDP пакеты подряд, поэтому сканировать лучше с указанием payload'a для конкретного приложения (например, SIP INVITE).  

Но если порт точно закрыт, система может прислать вам ICMP Port Unreachable (а может и не прислать - в зависимости от настроек на стороне хоста и его сети).  

Команда nmap -sU может выводить 3 варианта состояния порта:  

open - порт точно открыт (получен ответ от приложения)  

open|filtered - неизвестно, ответ не пришёл (либо приложение не ответило, либо порт закрыт без выдачи Port Unreachable)  

closed - порт точно закрыт (пришёл Port Unreachable) 

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

Т.е. возможен вариант когда порт открыт и данные принимаются, но отыета от этого порта нет