摘要

  • RFC 1283 以实验性规范把 SNMP 映射到 OSI 的无连接 CLTS 与面向连接 COTS。COTS 需要建立连接、发送一条或多条消息，再释放连接。
  • 发起方不能要求回复沿原连接返回，也不能把连接当成 SNMP 操作可靠性的证明。超时、重传或放弃仍由 SNMP 应用负责。
  • RFC 1418 后来删去 COTS，只为 UDP 不可用的环境保留无连接映射。规范被替代，不等于所有实现同时消失。

一次修订保存的是经验，不是胜利宣告

1990 年 6 月的 RFC 1161 给出在 OSI 传输服务上运行 SNMP 的实验方案，明确不是 Internet 标准，只说实验和充分共识可能产生后续版本。

1991 年 12 月，RFC 1283 取代前者，地位仍是 Experimental。编辑说明内容根据原版发布后的运行经验作过修改。这能证明文档学习过，不能证明某个现场部署已经成功。

当时的实际愿望是复用投资。SNMP 已在 TCP/IP 网络中广泛采用，一些站点又取得 OSI 能力。RFC 1283 没有把它重建成 OSI 应用，而是直接接到 OSI 传输服务。

CLTS 保留了数据包式交付

CLTS 的过程近似 UDP，两者都发送带完整寻址信息的数据包。此处的传输地址由网络地址与传输选择符组成。

OSI 不用 Internet 的知名端口完成这一步，而由对目的端本地有意义的不透明字节选择服务。RFC 1283 为 CLNP 方式规定 snmp 与 snmp-trap 两个选择符。

它们只协调“把传输单元交给哪个本地服务”。选择符不认证管理方，不授权 Set，也不证明变量值为真。投递标签不能替代管理授权。

COTS 建立的是关联，不是应用结论

SNMP 本来不要求已有连接。COTS 映射因此规定一个顺序：先建立传输连接，在其中发送一条或多条 SNMP 消息，再释放连接。

这个顺序产生多种可分离状态。连接可能建立失败；也可能已建立但没有完整请求；传输可能收下字节，应用却来不及回复便发生关闭。“连接已建立”最多证明传输关联达到自己的状态，不能证明 SNMP 解码、访问判断、对象读取、Set 执行或业务结果。

回复不必从同一扇门回来

RFC 1283 明说，连接发起方不应要求回复在同一连接上返回。不过，若响应方确实在连接中发送 SNMP 消息，那些消息必须是对该连接所收请求的回答。

连接由此提供了一条有条件的关联规则，而非唯一回复通道。同一连接沉默，不证明别处没有回复；连接本身也不是持久的操作标识。

连接寿命同样没有单一所有者。原则上由发起方释放，响应方却可因资源限制关闭。保持多久取决于实现和动态算法。因此，关闭可能来自策略、资源压力、空闲或故障，不能独自说明 SNMP 结果。

传输确认停在应用完成之前

RFC 1283 最关键的限制是：发起方不应把任何可靠性特征归给这条连接。SNMP 消息重传始终属于 SNMP 应用，而非传输服务。

两个月前的 RFC 1270 解释了原因。面向连接传输的确认不一定代表数据已经交到目的应用进程。SNMP 仍需自己的超时与重试，才能判断 SNMP 软件是否真正收到数据包。

这不是说传输可靠性无用。它保护字节在自己的契约内移动。但字节被传输与管理操作完成，是两份证据。后者还需要应用回复和关联。即使回复存在，也只是代理报告的信息，并不会自动证明现实网络状态。

三种连接策略各有账本

RFC 1270 比较三种做法：为每个受管对象常开一条连接；每次操作重建连接；只保留固定数量并按 LRU 等算法替换。第一种占用成百上千的连接记录，还可能产生无益 keepalive；第二种反复承担建立、关闭与 TIME-WAIT；第三种必须维护使用记录，受管对象多于连接池时又会退化为频繁重建。

谁决定关闭、依据哪次观察、迟到回复如何处理，都成了新的控制问题。增加状态并没有消灭账本，而是新建了一本。

1993 年的规范只留下无连接路径

1993 年 3 月，RFC 1418 同时取代 RFC 1161 和 RFC 1283。它仅保留 OSI 无连接映射，定位于 UDP 不可用的环境，也不要求异构环境中的代理支持多种映射。

CLTS 又可由无连接或面向连接的网络服务实现，两种情况使用不同选择符。也就是说，即便更下层网络带连接，SNMP 所见的传输契约仍可无连接。“连接”必须连同所在层级一起理解。

来源与边界

本文只使用官方 RFC 1161、RFC 1270、RFC 1283 与 RFC 1418。它们证明历史规则、设计理由与规范更替，不证明当前实现、身份、授权、实际连接、请求、回复、重试、故障或运行结果。四份文档均未讨论安全问题。