SNMP的历史
简单网络管理协议(SNMP )是一个简单的网络管理协议，它提供了网络管理和系统管理的基础框架。 这样，网络管理员和系统管理员就可以远程监视、配置和管理网络设备、操作系统、APP应用程序系统等。
1987年11月发布的简单网关监控协议(sgmp )是一个提供专用网络管理工具的起点，自sgmp问世以来，网络管理本来就是ICMP
随着网络管理需求的增加和变化，出现了许多网络管理的标准和方法，其中有影响力的有两个。
1 )简单网络管理协议(SNMP )，即简单网络管理协议(SNMP )，SNMP协议是SGMP的升级版；
2 )公共管理信息协议(cmip )，即公共管理信息协议，是在开放系统互连通信模式下建立的网络管理协议。
当时，IETF建议采用基于OSI的CMIP协议作为网络管理协议，并对其进行了修改。 修改后的协议称为公共管理工具(cmot )。 但是，在CMOT各项标准迟迟没有出台的情况下，IETF决定进一步修改现有的SGMP，作为暂定的解决方案。 基于该SGMP开发的解决方案是有名的SNMP。
SNMP已宣布为临时解决方案，但IETF没有放弃CMOT。 它还计划将SNMP作为最近的解决方案进行进一步开发，将CMOT作为长期解决方案，并将SNMP和CMOT设计为使用同一托管数据库。 因此，这两个协议分别共享一个公共管理信息库(SMI )和一个管理信息库(MIB )。
但是，由于SNMP的简单性，SNMP和CMOT这两个协议在被管理对象上的兼容性是不现实的，SNMP关注一些简单的数据、特性和变量，所以最终放弃了两者的兼容性，SNMP开始独立发展。SNMP v1
1988年，SNMP的最初标准已经确定。 现在我们把当时的那个规格称为SNMPv1。 摆脱与OSI兼容性的束缚后，SNMP发展迅速，很快得到许多制造商和设备的支持。 许多著名的网络管理系统HP的OpenView、IBM的NetView、Cabletron的Spectrum、Microsoft的系统管理服务器(SMS )、Novell的管理wise
SNMPv1协议的型号如下图所示(
在监视端，网络设备或主机设备中嵌入的SNMP代理收集设备的各种信息和统计数据，并不断将这些数据记录在MIB库中，管理端通过SNMP协议将这些数据发送到SNMP代理
SNMP消息中的GetRequest和GetNextRequest用于向SNMP代理查询MIB库数据，包括被监视设备的CPU利用率。 SetRequest消息用于在SNMP代理中设置一些变量。 例如，可以使用SetRequest重新启动设备。 SNMP代理还收集几个系统上的事件，并以SNMP捕获身份将这些事件通知SNMP管理方。
本文不打算讨论SNMP协议的细节。 有关SNMP协议的具体详细信息和实现，请参阅相关的RFC文档。 (如RFC 1157 )SNMP v2
为了弥补SNMPv1的安全性和其他方面的不足，IETF为SNMP v2做了很多工作。 其中大部分是为了寻找加强SNMP安全性的方法。 1992年7月，出现了SNMP的新版本，称为SMP，SMP在功能和安全性方面都有所提高，最终SMP被接受为定义SNMP v2的基础，1993年发表，但SNMP在安全方面的改进得到很大支持1996年，IETF发布了一套新的RFC，取消了对SNMPv2安全特性的修改，主要通信方式也重新采用了SNMPv1的基于通信字(Community )的方式。
SNMP v2改进了SNMP v1的捕获通知方法，设计了不同的事件格式来代替SNMP v1的捕获事件格式。
SNMP v2还定义了两种新的SNMP消息： GetBulk和Inform。 GetBulk用于更有效地查询和接收大量数据，并且信息可以由网络管理系统(NMS )向另一NMS发送捕获信息。SNMP v3
1999年，SNMPv3草案发布，2002年3月，SNMPv3标准正式发布。 SNMPv3对SNMPv2的最大改进主要在于安全性和管理能力两方面。
SNMPv3使用基于用户的安全模型和基于视图的访问控制模型提供SNMP网络管理的安全性，并利用加密方法避免信息泄露。
SNM
Pv3在安全性方面的改进主要有3点：1）SNMP的数据报文将被使用DES加密来避免信息的非法泄漏；
2）SNMP管理端与SNMP Agent通讯时必须要通过认证（authenticated）来保证身份的正确性、信息的完整性合信息的合时性（timeliness）；
3）SNMP Agent实现了User-base和View-base访问控制模型，访问控制可以精确到数据级别，并且更加灵活利于控制。
现在一些设备和操作系统已经开始支持SNMPv3，比如在UNIX世界比较有名的开源的SNMP实现——NET-SNMP( http://net-snmp.sourceforge.net/)，SNMP v3与SNMP v1/SNMPv2相比，基础架构和设计思路没有本质的改变，随着一些新的网路管理协议和标准的提出，SNMP的发展可能已经走到了尽头，但是无论将来怎么发展，在5年之内，SNMP绝对是业界事实上的网络管理协议标准。
SNMP的缺点
即使SNMP协议已经发展到第三版，但是因为SNMP出现时人们对网络管理认识的局限性以及SNMP协议不得不向上兼容的做法使得SNMP拥有很多缺点，在这里，将讨论SNMP协议的几个主要的缺点：
1）SNMP协议轮询的方式在一个大型网络中可能会导致网络通信拥塞情况的发生，并且SNMP协议把采集数据的负担完全压在了管理端之上；（注2）
在现在流行的千兆为主干的企业网中使用SNMP协议来监控设备会导致网络通信拥塞的说法可能有所危言耸听，但是在一个大型网络中，SNMP协议的确有浪费带宽的嫌疑；而且在一个大型网络中，面对近千台设备上万个OID采集点的数据采集量，管理端的负担太重，管理端甚至不能在设定的时间间隔内做一次完整的轮询。
要解决上面的问题，现在流行的做法是在网络的不同位置放置一些采集设备（或者称之为探针），由这些采集设备利用SNMP协议向不同的SNMP Agent采集数据，并在某个时候把这些采集好的数据提交到主控端上，或是主控端需要某些数据的时候从采集设备提取。
2）SNMP Agent无法提供某个数据的历史记录；（注3）
SNMP Agent只能提供被监控设备的当前状态，某些时候，SNMP Agent也能提供设备在15分钟或者更短时间内的某些统计数据，但是一个设备的性能和状态的历史记录对网络优化和性能调优有着莫大的帮助，整个网络的设备的历史记录还可以帮助决策者进行更有效、更合理的决策。
针对SNMP协议的这个说不上是缺点的缺点，管理端必须要在一定的间隔时间内不断的进行SNMP轮询，并把轮询得到的结果存储在本地以便将来能够对这些数据进行查询和分析。
比较有名的MRTG就是采用这种方式来统计网络设备的流量的信息的，并可以生成各种统计数据的趋势图。但是不幸的是，很多网络管理软件就根本无法提供这些历史数据。
3）SNMP协议不能以一种统一通用的数据描述格式保存所有被管理设备的标识、状态和配置等信息。
如果说SNMP协议的前两个缺点是可以用某些方式弥补的话，这里提到的第三个缺点是SNMP协议最致命的缺点。
SNMP这个缺点，在某种程度上来说主要是因为MIB库的混乱所导致的，在SNMP协议被提出来的最初，定义了一些公用（public）的MIB库，在SNMPv2版本，也定义了MIB-II，但是这些MIB库并无法包容所有厂商的被监控的信息，比如说Windows NT/2000的一些性能参数在这些公用的MIB库中根本无法得到体现，因此Microsoft就不得不定义一系列自己的MIB库来提供这些信息，由于这个原因，每个厂商都有大量的自己私有（private）的MIB库，正因为这些私有MIB库的存在，导致SNMP协议不能以一种统一通用的数据描述格式来保存所有被管理设备的各种信息。
下面我将举两个例子来详细说明这个问题：
假设我们需要通过SNMP协议来采集某些设备的CPU利用率的话，我们会发现，很多厂商提供CPU利用率的OID都不一样，比如在Netware上是.1.3.6.1.2.1.25.3.3.1.2、在使用NET-SNMP来提供Agent的Linux和BSD机器上是.1.3.6.1.4.1.2021.10.1.5、在Windows系列的操作系统上是.1.3.6.1.2.1.25.3.3.1.2、在Cisco路由器上却又变成.1.3.6.1.4.1.9.2.1.58，研究下去，你会发现，MIB简直就是个泥塘！
上面提到了MIB和OID的混乱，而第3个缺点的另外一层含义是：SNMP没有定义一套数据表达规范来描述不同厂商的相同类别的数据。比如操作系统的用户，在管理员看来无论什么操作系统，用户就是用户，虽然每个操作系统对用户的描述的字段不同（比如Windows系列操作系统中的用户的某些描述字段是UNIX操作系统中所没有的），但是用户就是用户，用户的描述再怎么变化，它也不会变成一个CPU，对于管理员来说，特别是一个管理不同平台、不同厂商设备的管理员来说，希望网管协议能够把各种相同类别的信息归纳成一个统一的、通用的数据表达方式，比如我们刚才所提到的不同操作系统的用户信息就可以归纳成一个通用的表达方式，某个平台无法提供的字段即使为空也是无所谓的，最关键的是——统一、通用。
为什么说这个问题是SNMP的致命的缺点？简单的来说这个缺点使得一个网络中采用一套基于SNMP的网管平台来管理不同厂商和平台的设备的美梦成为了一个幻想，从现在的情况来看，我们不可能仅仅只利用一套网络管理系统来有效的管理一个拥有AIX、HP-UX、Solaris、Linux、IBM Switch、Cisco Router、Cisco Switch、Foundry Switch、NetScreen、APC UPS、Windows NT/2000、Netware等等各种厂商和平台的网络中的所有设备（注4），这也是为什么Cisco的网络环境用Ciscoworks来管理最方便最有效、而HP的OpenView虽然可以管理更多厂商的设备但是在Cisco网络环境下不如Ciscoworks的主要原因之一（注5）。这也是当今主流的网络和系统管理软件无法有效的共享信息和协作的最主要的原因。
SNMP相关链接
http://www.faqs.org/faqs/snmp-faq/
SNMP FAQ
http://www.ietf.org/rfc.html
IETF RFC Page
你可以在这里浏览SNMP相关的RFC文档
http://www.ibr.cs.tu-bs.de/projects/snmpv3/
SNMP Version 3 (SNMPv3)
This web page provides information about the Simple Network Management Protocol Version 3 (SNMPv3).
http://people.ee.ethz.ch/~oetiker/webtools/mrtg/
MRTG: The Multi Router Traffic Grapher
The Multi Router Traffic Grapher (MRTG) is a tool to monitor the traffic load on network links. MRTG generates HTML pages containing PNG images which provide a LIVE visual representation of this traffic.
http://www.net-snmp.org/
The NET-SNMP Project Home Page
net-snmp provides tools and libraries relating to the Simple Network Management Protocol including: An extensible agent, An SNMP library, tools to request or set information from SNMP agents, tools to generate and handle SNMP traps, etc.
http://www.opennms.org/
OpenNMS Home
OpenNMS is an open-source project dedicated to the creation of an enterprise grade network management platform.
注释：
注1：SNMP刚出台时，它主要是为基于TCP/IP的互联网设计的，现在已经被其它协议实现，如IPX/SPX，DECNET以及Appletalk等。
注2：这里列举的缺点是制传统意义上的SNMP的缺点，而这个缺点已经被RMON有效的解决了，但是通常我们都习惯把SNMP与RMON分开来提，并且相当数量的支持SNMP的设备并不支持RMON，因此才会有这么一个提法。
注3：同注2
注4：这里所说的有效的管理是指能达到厂商自带的或者厂商能提供的管理软件的管理水平。
注5：除去这个原因，还有个主要原因是各个厂商都有自己的一些私有协议，而厂商自己的网管软件在很大程度上都依靠这些私有协议。