为啥 SNMP 通常运行在 UDP 而不是 TCP/IP 上？

Posted 2023-02-16

【中文标题】为啥 SNMP 通常运行在 UDP 而不是 TCP/IP 上？

【英文标题】：Why is SNMP usually run over UDP and not TCP/IP?为什么 SNMP 通常运行在 UDP 而不是 TCP/IP 上？

【发布时间】：2011-04-03 17:14:40

【问题描述】：

今天早上，工作中出现了大问题，因为 SNMP 陷阱没有“通过”，因为 SNMP 在 UDP 上运行。我记得在大学的网络课上，UDP 不能像 TCP/IP 那样保证交付。***说 SNMP 可以在 TCP/IP 上运行，但 UDP 更常见。

我知道 UDP 优于 TCP/IP 的一些优势是速度、广播和多播。但在我看来，保证交付对于网络监控来说比广播能力更重要。特别是当有严重的高安全需求时。我的一位同事告诉我，当流量变大时，UDP 数据包最先被丢弃。这是网络监控 (IMO) 首选 TCP/IP 而不是 UDP 的另一个原因。

那么为什么 SNMP 使用 UDP？我想不通，也无法在 Google 上找到充分的理由。

【问题讨论】：

“***说 SNMP 可以在 TCP/IP 上运行”，如果你仔细阅读 RFC3430，faqs.org/rfcs/rfc3430.html 你会发现它是实验性的，所以你不能指望所有供应商的产品都支持它。

针对上述实际问题+1

@PP，你很难，他需要挖掘 RFC1155、1157、1212、1215、1901、1908、2578、2579、2580、3416 和 3417（v1 和 v2c），如以及 RFC1213、2863、3418、4001、4001、4022、4113、4292、4293 和 4898 (MIB) :)

@LexLi 1) 感谢 RFC 链接 2) 来自未来的消息：问题不是“它正在运行什么协议”，而是“为什么使用它 UDP” 3) 抱歉迟到的反应

【参考方案1】：

在有损网络（或拥塞的网络）中，实际上预计 UDP 比 TCP 工作得更好。 TCP 在传输大量数据方面要好得多，但是当网络出现故障时，UDP 更有可能通过。 （事实上​​，我最近做了一项研究测试，发现当正确设置 UDP 超时时，在有损网络中，基于 UDP 的 SNMP 比基于 TCP 的 SNMP 成功得多）。通常，TCP 在大约 5% 的数据包丢失时开始表现不佳，在 33%（ish）时变得完全无用，而 UDP 仍然会成功（最终）。

因此，一如既往，正确的做法是为正确的工作选择正确的工具。如果您正在对大量数据进行例行监控，您可能会考虑使用 TCP。但要准备好回退到 UDP 来解决问题。现在的大多数堆栈实际上都可以使用 TCP 和 UDP。

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

【讨论】：

“大约 33% [数据包丢失] UDP 仍然会成功（最终）” - 那是什么魔法？ UDP 不是基本上只是盲目地向虚空喊叫并希望最好的吗？

@TomislavNakic-Alfirevic 如果你不断喊叫，你最终会被听到就是这个想法

【参考方案2】：

如果系统通过 TCP 发送 SNMP 陷阱，如果在将流量传送到接收器时出现问题，它们可能会阻止等待数据包被确认。如果生成了很多陷阱，它可能会用完系统上的可用套接字，系统会锁定。对于 UDP，这不是问题，因为它是无状态的。 BitBucket 在 1 月份出现了一个类似的问题，尽管它是 syslog 协议而不是 SNMP——基本上，由于配置错误，他们无意中通过 TCP 使用 syslog，syslog 服务器宕机，所有服务器都锁定等待 syslog服务器确认他们的数据包。如果通过 TCP 发送 SNMP 陷阱，可能会出现类似的问题。

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

【参考方案3】：

查看 O'Reilly 关于 SNMP 的文章：https://library.oreilly.com/book/9780596008406/essential-snmp/18.xhtml

将 UDP 用于 SNMP 陷阱的一个优点是，您可以将 UDP 定向到广播地址，然后将它们与该子网上的多个管理站一起使用。

【参考方案4】：

在 SNMP 中使用陷阱被认为是不可靠的。你真的不应该依赖陷阱。

SNMP 旨在用作请求/响应协议。协议细节很简单（因此得名“简单网络管理协议”）。 UDP 是一种非常简单的传输方式。尝试在您的基本代理上实现 TCP - 它比使用 UDP 编码的简单代理复杂得多。

SNMP get/getnext 操作具有重试机制 - 如果在超时内未收到响应，则发送相同的请求，最多尝试次数。

【讨论】：

很明显，您的组织还没有考虑到他们的网络管理策略。是时候让一些员工参加一些教育课程了！

我想简单是 UDP 相对于 TCP/IP 的优势，我无法弄清楚。谢谢你。然而，我很惊讶，列出我在努力理解该决定时提出的赞成和反对论点被视为贬低。

SNMP 确实是一个很棒的协议；然而，仅仅因为协议的实现简单并不意味着它易于使用和理解。对于一家公司来说，因为依赖陷阱而陷入困境，这简直就是不专业，而且根本上缺乏对最基本网络概念的理解。我只能说我很高兴土木工程师在建造人们依赖的基础设施之前必须获得认证。

【参考方案5】：

通常，当您使用 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 解析器。