SNMP的历史
SNMP（Simple Network Management Protocol）即简单网络管理协议，它为网络和系统管理提供了底层的框架，使得网络和系统管理员能够远程监测和配置管理他们的网络设备、操作系统、应用系统等。
1987年11月发布的SGMP（Simple Gateway Monitoring Protocol）即简单网关监控协议，成为提供专用网络管理工具的起点，自从SGMP出现后，网络管理摆脱了原始的利用ICMP来探测主机是否在线等简单监控手段的时代。
随着网络管理需求的增长和变化，出现了很多网络管理的标准和方法，其中比较有影响力的有两个：
1) SNMP（Simple Network Management Protocol）即简单网络管理协议(SNMP)，SNMP协议是SGMP的升级版；
2) CMIP（Common Management Information Protocol）即通用管理信息协议，建立在开放系统互连通信模式上的网络管理协议。
在当时，IETF推荐采用基于OSI的CMIP协议作为网络管理协议，并对它作了修改，修改后的协议被称作CMOT(Common Management Over TCP/IP)。但是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的Systems Management Server（SMS）、Novell的ManageWise和开源的OpenNMS都是基于SNMP标准设计的。
SNMPv1协议的模型如下图所示（注1）：
在被监控端，嵌入到网络设备中或主机设备的SNMP Agent收集设备的各种信息和统计数据并不断的把这些数据记录到MIB库中，在管理端，通过SNMP协议向SNMP Agent发出SNMP报文，SNMP Agent收到报文后向SNMP管理端响应应答包。
SNMP报文中的GetRequest、GetNextRequest用来向SNMP Agent查询MIB库数据，比如可以查询被监控设备的CPU利用率等；SetRequest报文用来向SNMP Agent设置一些变量，比如可以利用SetRequest来重启某台设备；另外，SNMP Agent会收集一些系统的事件，并以SNMP Trap的方式向SNMP管理端通告事件。
本文不打算讨论SNMP协议的细节，有关SNMP协议的具体细节和实现，可以查看相关的RFC文档。(RFC 1157 等)
SNMP v2
为了弥补SNMPv1在安全性和其它方面的欠缺，IETF为SNMP v2做了大量的工作，其中大多数是为了寻找加强SNMP安全性的方法，1992年7月，出现了一个称为SMP的SNMP新版本，SMP在功能和安全性两方面提高了SNMP，最终SMP被接受为定义SNMPv2的基础，并于1993年发布了SNMPv2。但是SNMP在安全方面的改进并没有得到个方面的支持，1996年，IETF发布了一组新的RFC，取消了SNMPv2的安全特性的修改，主要通讯方式也重新采用 SNMPv1的基于Community（通讯字）的方式。
SNMP v2改进了SNMP v1的Trap通告方式，一种不同的事件格式被设计来替代SNMP v1的Trap事件格式。
同时，SNMP v2定义了两种新的SNMP报文：GetBulk和Inform。GetBulk用来更有效率的查询和接收批量的数据，而Inform可以被NMS（网络管理系统）发送Trap信息到另一个NMS。
SNMP v3
1999年，SNMPv3的草案发布，在2002年3月，SNMPv3的标准正式出台，SNMPv3针对SNMPv2的最大改进主要在安全性和管理能力两个方面。
SNMPv3采用User-based安全模型和View-based访问控制模型提供SNMP网络管理的安全性，并利用加密的方式来避免信息的泄漏。
SNMPv3在安全性方面的改进主要有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来管理最方便最有效、而
