今天早上,工作中出现了大问题,因为SNMP陷阱没有“通过”,因为SNMP是通过UDP运行的。我记得在大学的网络课上,UDP不能保证像TCP / IP一样传送。维基百科说SNMP可以通过TCP / IP运行,但UDP更常见。
我知道UDP over TCP / IP的一些优点是速度,广播和多播。但在我看来,有保障的传输对于网络监控比对广播能力更重要。特别是当存在严重的高安全性需求时。我的一位同事告诉我,当流量变大时,UDP数据包是第一个被丢弃的数据包。这是优先使用UDP / TCP进行网络监控(IMO)的另一个原因。
那么为什么SNMP使用UDP?我无法弄清楚,也无法在谷歌找到一个好理由。
答案 0 :(得分:47)
因此,正确的做法是为正确的工作挑选合适的工具。如果您正在对大量数据进行例行监视,则可以考虑使用TCP。但是要准备回归UDP以解决问题。这些天大多数堆栈实际上可以使用TCP和UDP。
至于发送TRAP,是的TRAP是不可靠的,因为它们没有得到承认。但是,SNMP INFORM是SNMP TRAP的确认版本。因此,如果您想知道通知接收者收到消息,请使用INFORM。请注意,TCP确实不解决此问题,因为它仅提供收到消息的第3层级通知。无法保证通知接收器实际上已获得它。 SNMP INFORM执行应用程序级别确认,并且比假设TCP ack表明他们得到它更可靠。
答案 1 :(得分:11)
如果系统通过TCP发送SNMP陷阱,如果将流量发送到接收方时出现问题,它们可能会阻止等待数据包被确认。如果生成了大量陷阱,它可能会耗尽系统上的可用套接字,系统会锁定。使用UDP不是问题,因为它是无状态的。一个类似的问题在1月份取出了BitBucket,虽然它是系统日志协议而不是SNMP - 基本上,由于配置错误,系统日志服务器停机,并且所有服务器都锁定等待系统日志,它们无意中使用了TCP上的syslog服务器确认其数据包。如果通过TCP发送SNMP陷阱,则可能会出现类似问题。
http://blog.bitbucket.org/2012/01/12/follow-up-on-our-downtime-last-week/
答案 2 :(得分:4)
使用带有SNMP的陷阱被认为是不可靠的。你真的不应该依赖陷阱。
SNMP旨在用作请求/响应协议。协议细节很简单(因此称为“简单网络管理协议”)。而UDP是一种非常简单的传输方式。尝试在基本代理上实现TCP - 它比使用UDP编码的简单代理复杂得多。
SNMP get / getnext操作具有重试机制 - 如果在超时内未收到响应,则会发送相同的请求以达到最大尝试次数。
答案 3 :(得分:4)
查看O'Reilly关于SNMP的着作:https://library.oreilly.com/book/9780596008406/essential-snmp/18.xhtml
使用UDP进行SNMP陷阱的一个优点是,您可以将UDP定向到广播地址,然后使用该子网上的多个管理站对其进行定位。
答案 4 :(得分:0)
通常,当您使用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版本会成功,因为它位于同一子网中,或者位于不远处(即在公司网络上)。 但是,如果初始请求或响应有问题,则由应用程序决定。答:我们可以通过丢失数据包来度过吗?如果是这样,谁在乎,就继续前进。 B.我们是否需要确保已发送消息?简单,只需重做一遍...客户端将请求发送到服务器,服务器将响应发送到客户端。该应用程序可以提供一个号码,以防万一邮件的收件人同时收到了两条邮件,他知道这确实是同一封邮件再次发送。
这是为什么通过UDP完成DNS的相同技术。它的重量轻得多,并且通常可以第一次使用,因为您应该在DNS解析器附近。