为什么SNMP通常通过UDP而不是TCP/IP运行？

今天早上,工作中出现了大问题,因为SNMP陷阱没有"通过",因为SNMP是通过UDP运行的.我记得在大学的网络课上,UDP不能保证像TCP/IP一样传送.维基百科说SNMP可以通过TCP/IP运行,但UDP更常见.

我发现UDP over TCP/IP的一些优点是速度,广播和多播.但在我看来,有保障的传输对于网络监控比对广播能力更重要.特别是当存在严重的高安全性需求时.我的一位同事告诉我,当流量变大时,UDP数据包是第一个被丢弃的数据包.这是通过UDP优先使用TCP/IP进行网络监控(IMO)的另一个原因.

那么为什么SNMP使用UDP呢？我无法弄清楚,也无法在谷歌找到一个好理由.

实际上,UDP在有损网络(或拥塞网络)中的效果要好于TCP.TCP在传输大量数据方面要好得多,但是当网络出现故障时,UDP更有可能通过.(事实上​​,我最近做了一项测试的研究,发现在正确设置UDP超时的情况下,SNMP over UDP在有损网络中的成功远远优于SNMP over TCP).通常,TCP在大约5%的数据包丢失时开始表现不佳,在33%(ish)时变得完全无用,UDP仍然会成功(最终).

因此,一如既往,正确的做法是为正确的工作选择合适的工具.如果您正在对大量数据进行例行监视,则可以考虑使用TCP.但是要准备回归UDP以解决问题.这些天大多数堆栈实际上可以使用TCP和UDP.

至于发送TRAP,是的TRAP是不可靠的,因为它们没有被承认.但是,SNMP INFORM是SNMP TRAP的确认版本.因此,如果您想知道通知接收者收到消息,请使用INFORM.注意,TCP并没有因为它仅提供已接收的消息层3级别通知解决这个问题.无法保证通知接收器实际上已获得它.SNMP INFORM执行应用程序级别确认,并且比假设TCP ack表明他们获得它更可靠.

如果系统通过TCP发送SNMP陷阱,如果在接收器上获得流量时出现问题,则可能阻止等待数据包被确认.如果生成了大量陷阱,它可能会耗尽系统上的可用套接字,系统会锁定.使用UDP不是问题,因为它是无状态的.一个类似的问题在1月份取出了BitBucket,虽然它是syslog协议而不是SNMP - 基本上,由于配置错误,他们无意中使用了syslog over sys,syslog服务器关闭,并且所有服务器都锁定等待syslog服务器确认其数据包.如果通过TCP发送SNMP陷阱,则可能发生类似的问题.

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