Почему SNMP обычно работает через UDP, а не TCP / IP? - PullRequest
Новая
       18

Почему SNMP обычно работает через UDP, а не TCP / IP?

45 голосов
/ 25 августа 2010

Этим утром были большие проблемы на работе, потому что ловушка SNMP не "проходила", потому что SNMP запускается по UDP. Я помню из урока по сетевым технологиям в колледже, что UDP не гарантирует доставку, как TCP / IP. И в Википедии сказано, что SNMP может работать по TCP / IP, но UDP более распространен.

Я понял, что некоторые из преимуществ UDP над TCP / IP - это скорость, широковещание и многоадресная рассылка. Но мне кажется, что гарантированная доставка важнее для мониторинга сети, чем возможность вещания. Особенно, когда есть серьезные требования безопасности. Один из моих коллег сказал мне, что пакеты UDP являются первыми, которые будут отброшены, когда трафик станет интенсивным. Это еще одна причина для предпочтения TCP / IP над UDP для мониторинга сети (IMO).

Так почему же SNMP использует UDP? Я не могу понять это и не могу найти вескую причину в Google.

Ответы [ 5 ]

48 голосов
/ 13 октября 2010

UDP фактически должен работать лучше, чем TCP, в сетях с потерями (или в перегруженных сетях).TCP намного лучше передает большие объемы данных, но когда сеть выходит из строя, более вероятно, что UDP пройдет.(На самом деле, недавно я провёл исследование, тестирующее это, и обнаружил, что SNMP через UDP был успешнее, чем SNMP через TCP в сетях с потерями, когда тайм-аут UDP был установлен правильно).Как правило, TCP начинает работать плохо при потере примерно 5% пакетов и становится абсолютно бесполезным при 33% (ish), а UDP все равно будет успешным (в конце концов).

Так что, как всегда, правильно выбратьправильный инструмент для правильной работы.Если вы делаете рутинный мониторинг большого количества данных, вы можете рассмотреть TCP.Но будьте готовы прибегнуть к UDP для устранения проблем.Большинство стеков в наши дни могут фактически использовать как TCP, так и UDP.

Что касается отправки TRAP, да, TRAP ненадежны, потому что они не подтверждены.Тем не менее, SNMP INFORMs являются подтвержденной версией SNMP TRAP.Таким образом, если вы хотите знать, что получатель уведомлений получил сообщение, пожалуйста, используйте INFORM.Обратите внимание, что TCP не решает эту проблему, поскольку предоставляет только уведомление уровня 3 о том, что сообщение было получено.Нет уверенности в том, что получатель уведомления действительно его получил.SNMP INFORMs делают подтверждение на уровне приложения и гораздо более надежны, чем если предположить, что подтверждение TCP указывает, что они его получили.

12 голосов
/ 09 июня 2012

Если бы системы отправляли ловушки SNMP через TCP, они могли бы заблокировать ожидание пакетов ACK, если возникла проблема с передачей трафика получателю. Если было сгенерировано много ловушек, он мог бы использовать доступные сокеты в системе, и система зависла бы. С UDP это не проблема, потому что он не имеет состояния. Аналогичная проблема возникла с BitBucket в январе, хотя это был протокол системного журнала, а не SNMP - в основном, они непреднамеренно использовали syslog через TCP из-за ошибки конфигурации, сервер syslog вышел из строя, и все серверы заблокированы в ожидании системного журнала сервер для подтверждения своих пакетов. Если SNMP-ловушки были отправлены через TCP, может возникнуть аналогичная проблема.

http://blog.bitbucket.org/2012/01/12/follow-up-on-our-downtime-last-week/

4 голосов
/ 12 июля 2011

Ознакомьтесь с работами О'Рейли по SNMP: https://library.oreilly.com/book/9780596008406/essential-snmp/18.xhtml

Одним из преимуществ использования UDP для прерываний SNMP является то, что вы можете направить UDP на широковещательный адрес, а затем передать их нескольким станциям управления в этой подсети.

4 голосов
/ 25 августа 2010

Использование ловушек с SNMP считается ненадежным. Вы действительно не должны полагаться на ловушки.

SNMP был разработан для использования в качестве протокола запроса / ответа. Детали протокола просты (отсюда и название «простой протокол управления сетью»). А UDP - это очень простой транспорт. Попробуйте реализовать TCP на базовом агенте - он значительно сложнее, чем простой агент, закодированный с использованием UDP.

Операции SNMP get / getnext имеют механизм повтора - если ответ не получен в течение тайм-аута, один и тот же запрос отправляется с максимальным числом попыток.

0 голосов
/ 17 марта 2019

Обычно, когда вы используете SNMP, вы находитесь в сети компании, вы не делаете это в течение длительного времени. UDP может быть более эффективным. Давайте рассмотрим (грубое упрощение) разговор через TCP, а затем через UDP ...

Версия TCP: 

client sends SYN to server
server sends SYN/ACK to client
client sends ACK to server - socket is now established
client sends DATA to server
server sends ACK to client
server sends RESPONSE to client
client sends ACK to server
client sends FIN to server
server sends FIN/ACK to client
client sends ACK to server - socket is torn down

Версия UDP: 

client sends request to server
server sends response to client

Как правило, версия UDP работает успешно, так как она находится в одной подсети или недалеко (то есть в сети компании). Тем не менее, если есть проблема с первоначальным запросом или ответом, решение остается за приложением. A. можем ли мы обойтись пропущенным пакетом? если так, кого это волнует, просто двигайтесь дальше. B. мы должны удостовериться, что сообщение отправлено? просто, просто переделать все это ... клиент отправляет запрос на сервер, сервер отправляет ответ клиенту. Приложение может предоставить номер на тот случай, если получатель сообщения получит оба сообщения, он знает, что это действительно то же самое сообщение, которое отправляется снова.

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

...