摘要

  • RFC 869 为监测中心提供共同的轮询、应答匹配、状态与统计数据请求，以及主动告警的消息框架；它没有让所有主机报告相同的事实。
  • 1982 年的 RFC 823 展示了这种差异在网关上的具体样子：接口、邻居、可达网络、流量矩阵和丢弃计数都能被报告，但指标和控制数据的格式仍取决于主机类型。

分析

网关报告的是网络如何运行

主机监测协议（Host Monitoring Protocol，HMP）并非只用来确认一台机器是否在线。1982 年的 DARPA 互联网网关规范描述了 HMP 如何收集网关的测量值和状态：状态消息涵盖接口、相邻网关，以及它能够到达的网络。Host Traffic Matrix 按 IP 源地址、目的地址和协议号统计经过网关的数据报。另一个吞吐量消息记录接收、转发、发送和丢弃的数据报，并按接口和邻居细分。

这些数据让远端监测者得以看到网关内部的一部分运行情况。流量矩阵可以显示哪些源、目的和协议组合经过设备；丢弃计数可以指出故障发生在哪类处理路径上。但这些数值本身并不能证明某个用户应用已端到端连通。RFC 823 描述的是工程设计，不能当作所有网关都实际运行该实现的独立统计。

统一的是消息框架，不是设备词典

Robert Hinden 于 1983 年 12 月发布的 RFC 869取代了早期的 IEN 197。它把 HMP 定义为面向事务、无连接的传输协议。消息头包含系统类型、消息类型、序列号、可在口令与返回序列号之间复用的字段，以及校验和。系统类型和消息类型共同决定数据该如何解释。规范列出 IMP、终端接入控制器（TAC）、网关等系统；HMP 使用的 IP 协议号是 20。

这套公共框架让不同主机能够识别轮询、并把回复对应到请求。但它并没有把网关吞吐量计数变成所有主机通用的状态语言。RFC 869 明确写道，各系统类型按自身需要定义消息类型。附录列出了 IMP、TAC 和网关消息的例子，导言同时说明，这些例子不属于 HMP 协议本身。HMP 规定了如何提问、如何识别回复；回复具体代表什么，仍由设备自己的数据格式决定。

告警、状态和统计值不是同一种证据

RFC 869 把多数监测逻辑放在监测中心。主机负责收集数据，并按需或主动发送；中心负责确保自己请求的数据确实收到。中心轮询状态或统计数据，超时后可以重发。序列号可用于把答复对应到轮询请求，也能识别重复的统计消息。统计数据会在一个采集周期内暂存，因此丢失的答复可以再次请求。

主动告警采用另一种规则。事件发生时，主机发送数据报，但 HMP 没有为它规定确认或重传。因此，告警可以快速到达，却不是完整、可靠的事件历史。状态也有明确边界：监测中心可以根据主机是否回应轮询来判断它“在线”还是“离线”。没有回复时，协议无法区分是主机、路径、请求还是答复出了问题；收到回复也不能证明更高层的服务运行正常。

监测中心也可以改变主机

轮询消息不只用于读取。RFC 869 允许监测中心读取主机参数，或发送控制数据；例子包括设置测量开关或计时器，也包括用重启开关控制主机。主机处理数据后返回控制确认；如果无法处理，则返回错误。参数和控制数据的格式都与主机类型有关。确认代表协议所定义的交换已经发生，RFC 并未把它说成用户服务已恢复的证据。

1990 年的 SNMP 规范 RFC 1157可用于对照，但不能证明 SNMP 直接源于 HMP。RFC 1157 把 Simple Gateway Monitoring Protocol（SGMP）称为 SNMP 的前身，并描述了以读取或修改变量为核心、辅以少量主动告警的体系。HMP 的历史应单独看待：它提供共同的消息外壳，让不同设备报告各自的数据，也接受各自定义的控制内容。

1983 年 4 月的官方协议目录 RFC 840将 HMP 列为“Elective”，并称它用于监测互联网网关和 TAC，也可帮助调试远端小型计算机上的协议实现。RFC 869 同样记载了网关和 TAC 的用途，同时说其他主机的实现仍在设计中。这些记录证明的是特定时期的有限用途，不是互联网范围内的普及。HMP 留下的历史线索在于它划清了一个边界：共同的消息规则让远程观察成为可能，但报告的含义仍取决于发送它的主机。

来源