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来治理最方便最有效、而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：除去这个原因，还有个主要原因是各个厂商都有自己的一些私有协议，而厂商自己的网管软件在很大程度上都依靠这些私有协议。
