今天早上，工作中出现了大问题，因为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，虽然它是系统日志协议而不是SNMP - 基本上，由于配置错误，系统日志服务器停机，并且所有服务器都锁定等待系统日志，它们无意中使用了TCP上的syslog服务器确认其数据包。如果通过TCP发送SNMP陷阱，则可能发生类似的问题。
http://blog.bitbucket.org/2012/01/12/follow-up-on-our-downtime-last-week/
使用带有SNMP的陷阱被认为是不可靠的。你真的不应该依赖陷阱。
SNMP旨在用作请求/响应协议。协议细节很简单（因此称为“简单网络管理协议”）。而UDP是一种非常简单的传输方式。尝试在基本代理上实现TCP - 它比使用UDP编码的简单代理复杂得多。
SNMP get / getnext操作具有重试机制 - 如果在超时内未收到响应，则会发送相同的请求，最多尝试次数。
查看O'Reilly关于SNMP的文章：https://library.oreilly.com/book/9780596008406/essential-snmp/18.xhtml
使用UDP进行SNMP陷阱的一个优点是，您可以将UDP定向到广播地址，然后使用该子网上的多个管理站对其进行定位。
通常，当你在做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.我们是否需要确保邮件已发送？简单，只需重做整个事情......客户端向服务器发送请求，服务器向客户端发送响应。应用程序可以提供一个号码，以防邮件的收件人收到这两个邮件，他知道它实际上是相同的邮件再次发送。
同样的技术是DNS通过UDP完成的原因。它的重量要轻得多，通常它是第一次运行，因为你应该靠近你的DNS解析器。