1.2 SNMP概述
作为一种标准的网络管理协议，从功能上，SNMP的组成可以分为两大部分：管理信息的定义与标识和SNMP实体之间的通信协议。
管理信息的定义与标识的核心内容是管理信息结构与标识（Structure and Identification of Management Information，SMI）和许多的管理信息库（Management Information Base，MIB）。SMI目前有SMIv1和SMIv2两个版本，它规定如何定义、标识管理信息。MIB遵循SMI规范，定义具体的管理信息。
通信协议主要内容分别在SNMPv1、SNMPv2和SNMPv3等标准中定义，不同版本中的通信协议操作和通信协议安全机制不同。
1.2.1 管理工作站和代理
智能化的网络管理中，网络管理程序代替网络管理员，按照预先设置自动进行网络设备信息的收集、分析和处理。另外，支持SNMP功能的网络设备，必须有相应的支撑软件。
运行网络管理程序的计算机称为网络管理工作站（Network Management Station，NMS），代理（Agent）是运行在被管理的网络设备上完成SNMP功能的进程。管理工作站通过向代理发起查询操作，获得网络设备的工作状态信息；而代理则负责响应和处理来自管理工作站的服务请求，并向管理工作站报告本地发生的重大网络事件。运行代理的网络设备可以是路由器、交换机、集线器、主机、网络打印机，甚至是一台不间断电源（UPS），这些设备称为被管理设备，有时候也称这些设备是“可网管的”。图1-2所示为部署在一个网络中的网络管理工作站和网络设备示意图。
https://yqfile.alicdn.com/252422bc7bc68ea74bbf5569e4067b73bbcde679.png" >
在SNMPv3中，没有管理工作站与代理的概念，它们被统一称为SNMP应用程序实体。
委托代理（Proxy Agent）是一种特殊的SNMP代理。RFC 3413给出了委托代理的三种用途：
（1）转发SNMP请求。委托代理可以透明转发一个SNMP请求到另外一个SNMP应用程序实体。通常情况下，不同的网络传输域或不同的SNMP版本之间，需要委托代理进行请求消息转发。
（2）SNMP请求翻译。委托代理可以将SNMP请求翻译成不支持SNMP的另外一种管理协议的操作。
（3）特殊代理结构支持。当代理A中的某个管理信息取决于另外一些远程的代理中管理信息的状态时，代理A可以称为远程代理的委托代理。这种情况和代理的结构有关，实际情况中较少遇到。
1.2.2 SNMP的组成
SNMP是应用层协议，通信的参与者不仅仅是不同操作系统的主机，还有各种网络设备。因此，SNMP定义了一套自己的“抽象语法”，就是通信双方交换数据的标准格式定义。
任何通信协议都具有语义、语法和时序三要素，SNMP也不例外。语义表示如何解释得到的数据，语法规定了数据的组成格式，而时序则规定了双方交互数据时的先后顺序。协议的语意和语法一般通过PDU（协议数据单元，Protocol Data Unit）实现。SNMP中定义了5种PDU。
SNMP使用抽象语法标记（Abstract Syntax Notation One，ASN.1）定义抽象语法和PDU。以SNMPv1为例，RFC 1155（基于TCP/IP的网络管理信息结构结构与标识，SMI）规定了如何定义SNMP使用的抽象语法，通俗地说也就是SNMP代理和工作站通信时使用的数据类型；RFC 1213（基于TCP/IP的网络管理信息库，MIB-II）依据SMI定义了一组标准的数据类型，这些数据类型的取值，表示一些对网络管理活动有意义的网络资源，定义这些数据类型的文本，称为MIB；RFC 1157（简单网络管理协议，SNMP）定义了管理工作站和代理之间的通信协议和PDU格式。
SMI、MIB和SNMP构成了SNMP协议簇的基石，堪称组成SNMP协议簇的“三驾马车”。
遵循SMI，可以根据实际需要，定义出更多的数据类型（MIB）。一句话，SMI和MIB的作用就是定义SNMP应用程序交互数据时使用的数据类型，而SNMP则规定了这些数据如何在应用程序之间交互，包括交互数据时使用的PDU格式、意义和消息顺序。
SMI、MIB和SNMP三者之间的关系如图1-3所示。
需要注意的是，MIB和SMI关系紧密，依据不同的SMI版本定义的MIB，格式也不尽相同；SNMP与MIB之间的关系相对松散，SNMP只负责应用之间的数据传递方式，功能是保证SNMP应用之间正确、有效地传递数据，至于传递的是什么数据，意思是什么，则由应用程序负责解释。
可以看出，SNMP中数据类型的定义和通信协议的定义，各自相互独立，互不影响。这一点很重要，当新的需求出现需要升级时，可以单独更改其中之一个而不影响另外一个。之所以如此是因为，IAB的原意是在CMOT替换SNMP时，不至于重新定义MIB，但这实际上却为SNMP以后的版本升级带来了极大的便利。
1.2.3 SNMP与TCP/IP
最初的SNMPv1标准是为满足基于TCP/IP的网络管理而开发的。及至SNMPv2，RFC 1906定义了SNMP消息在多种网络层协议上传输的规则，使得SNMP演变为一个可以运行在多种网络协议上的网络管理协议。
从TCP/IP协议栈的角度看，SNMP属于应用层协议，与Telnet、FTP和HTTP等应用层协议层次相同，如图1-4所示。
任何应用层协议，都是为某种特定的网络应用而设计的。例如，HTTP是为了满足浏览器和Web服务器站点之间的通信需要而设计的，FTP、TFTP是为了满足网络文件传输应用而设计的。同样的，SNMP是为了满足网络管理活动中的通信需要而制订的。
和本地应用程序不同，网络应用层协议面临的一个问题是，网络中参与通信的双方，很有可能存在系统差异。例如，网络中的服务器可能是一台IBM小型机，也可能是一台联想服务器，而客户端可能是一台个人电脑；通信双方的操作系统可能是UNIX、Linux或Windows。不同的平台和系统，存储和处理数据的方式也各不相同。
https://yqfile.alicdn.com/3c80921cdfd8b3f988f4ff866d65ab206aae4d42.png" >
网络通信活动的实质是通信双方的数据交互。在TCP/IP中，传输层以下各层通力协作，负责将数据无差错地递交给应用层。OSI参考模型中，会话层以下各层完成此任务。应用层得到数据后，关键是要能够正确解读，即这个数据是什么类型？它代表什么意义？如果不能做到这一点，那么即使数据传输过程再完美，也是毫无意义的。
为此，应用层协议首先要定义一套通信双方都能理解的数据类型。为了使数据交互不受具体的硬件平台和系统平台限制，定义的数据类型还必须是和这些平台无关的。
在OSI参考模型中，第六层“表示层”专门完成这项工作。在TCP/IP中，虽然没有单独完成相应功能的协议层，但它们都在应用层中实现了。在OSI术语中，某一特定应用层协议使用的，专门用来和其他系统交换，并且和具体的系统软、硬平台无关的数据类型，称为“抽象语法”。
1.2.4 SNMP操作
SNMP是管理工作站与代理之间进行数据交互的通信协议。一般来说，工作站获取代理的管理信息有两种模式：查询和事件报告。查询操作是由工作站主动发起，代理接到请求后响应；事件报告机制则是当事件发生时，代理主动向工作站报告情况。
通信协议为完成不同的协议功能操作，通常是定义不同的PDU来实现。为简单起见，SNMPv1仅规定了5种操作，因此只定义了5种PDU，分别是get、getnext、set、response和Trap。其中get、getnext和set三种PDU用于工作站发起的主动操作，通常也是查询操作；response PDU用于代理应答上述三种消息；Trap PDU则用于代理主动向工作站报告本地发生的网络事件。
从服务器/客户机计算模式的角度看，在SNMP操作中工作站和代理都扮演着双重角色，既是服务器也是客户机。查询操作中，工作站是客户端，代理是服务器，监听UDP端口161；在事件报告操作中，代理是客户端，工作站是服务器，监听UDP端口162。SNMP操作如图1-5所示。
注意：
UDP端口161、162是SNMP使用的缺省端口。实际环境中，SNMP代理和工作站使用的UDP端口是可配置的。
1.2.5 远程监控
远程监控（Remote Monitoring，RMON）最初用于监视局域网的网络数据流量，提供本地局域网的故障诊断、性能优化等数据信息。
RMON可以看做SNMP的一个特殊应用，它不是一个单独的网络管理协议，只是一组特殊的MIB，外加一个特殊的代理，这个代理也被称为探针（Probe）或监视器（Monitor）。
网络管理工作站与RMON代理使用SNMP交互信息，如图1-6所示。
从结构上看，RMON代理类似一个次级管理工作站：它在管理工作站的控制下，对RMON MIB中定义的信息进行本地处理（例如采集、存储）。管理工作站可以查询这些数据，也可以进行分析判断，然后根据配置，决定是否向管理工作站发送事件通告。与普通的SNMP代理比较，RMON代理具有更强的数据处理功能，分担了管理工作站的一部分工作。
RMON的实施目的有以下几点。
（1）离线监视。
远程监视中，被管理设备往往与管理工作站位于不同的网络，由于通信线路带宽资源限制，大批量地传输管理信息是不适宜的。另外，广域网线路（或拨号线路）也经常会发生中断故障。RMON允许代理在与管理工作站失去通信的情况下，继续不间断地采集和保存本地管理信息和监视本地网络事件。
（2）更有效地监控。
RMON代理与被管理设备处于同一局域网，而局域网资源相对宽松，因此，只要RMON代理资源足够，可以根据需要，尽可能多地保存本地数据信息。这些信息对于网络管理员来说是很有价值的。
（3）检测、报告故障。
可以通过配置RMON代理，监视更多的网络资源。例如，可以设置阈值，监控某一网络资源的使用情况。在这个过程中，RMON代理在本地不断检测，只有网络资源使用率超过阈值，才会向管理工作站报告。
（4）数据处理。
RMON代理可以在本地对收集的信息数据进行简单的初步处理，向管理工作站提供更有价值的数据。例如，它可以根据本地采集的数据信息，列出本地网络中产生流量最多的前10台主机，提供给管理工作站。
（5）多工作站统一接口。
出于不同的管理目的或备份的需要，网络中可能存在多台管理工作站。这些工作站管理远程局域网时，可以使用同一个RMON代理，以节省资源。
RMON MIB最早在1991年通过RFC 1271发布，之后被RFC 1757取代。遵循SMIv2的MIB在RFC 2819中定义。这些标准被称为RMON 1。RMON 1 MIB定义的被管理对象表示的管理信息大多与网络硬件有关，位于OSI参考模型中数据链路层以下。
1997年，RFC 2021推出了RMON 2。RMON 2定义的MIB定义了网络层以上的信息数据。RMON 2与RMON 1之间的区别如图1-7所示。
【阅读材料】
Request for Comments（RFC）
在计算机网络工程中，RFC是IETF发布的关于Internet或与其相关的研究成果、解决某一问题的方法、描述新的观点或建议等一系列的正式文档。
RFC这种文档格式最早是ARPANET工程的一个关键部分。当时，人们将自己的工作打印成文，分发给ARPANET研究人员。这种文档以一种非正式的形式出现，描述一些关于某些问题的想法和某些未能解决的问题。并就这些问题集思广益，征求大家的意见和建议。这类文档，现在被称为Internet 草案（Internet Draf）。
1969年12月，RFC开始通过ARPANET发布。第一份RFC文档RFC1于1969年4月由洛杉矶加利福尼亚大学的Steve Crocker完成，题目为“Host Software”。
RFC编辑负责为每份发布的RFC分配一个唯一的序号。一旦RFC正式发布，便不能再修改。确需修改的，另外发布新的RFC文档以取代原来发布的RFC。
并不是所有RFC文档都是网络标准。每份RFC文档根据不同的情况，被赋予状态：通告（Informational）、实验（Experimental）、最佳经验（Best Current Practice）、标准跟踪（Standards Track）、历史（Historic）和废除（Obsolete）。其中，标准跟踪状态又进一步细分为：建议（Proposed）、草案（Draft）和标准（Standard）。
“通告”状态的RFC可以是描述任意信息的文档，例如一些私有协议，甚至是“愚人节”笑话。再如，庆祝RFC 30周年纪念的RFC 2555，也属于通告状态。
“实验”状态的RFC为IETF的实验性的文档和个人建议。
“标准跟踪”的第一个状态是“建议”，下一步状态为“草案”，最终状态为“标准”。当发布一个新的RFC取代已经存在的RFC时，被取代的RFC状态成为“废除”。不再使用的RFC，状态会转为“历史”。
为减少歧义，RFC 2119专门就RFC文档中使用的关键词汇进行了解释，正确理解这些关键词的意义有助于更好地理解RFC。经常遇到的一些关键词（文档中以大写形式出现）如表1-1所示。
https://yqfile.alicdn.com/f38cd25f835d0cf317fed76a417a417d735e42e8.png" >