SNMP的歷史
SNMP（Simple Network Management PRotocol）即簡單網(wǎng)絡(luò)治理協(xié)議，它為網(wǎng)絡(luò)和系統(tǒng)治理提供了底層的框架，使得網(wǎng)絡(luò)和系統(tǒng)治理員能夠遠程監(jiān)測和配置治理他們的網(wǎng)絡(luò)設(shè)備、操作系統(tǒng)、應用系統(tǒng)等。
1987年11月發(fā)布的SGMP（Simple Gateway Monitoring Protocol）即簡單網(wǎng)關(guān)監(jiān)控協(xié)議，成為提供專用網(wǎng)絡(luò)治理工具的起點，自從SGMP出現(xiàn)后，網(wǎng)絡(luò)治理擺脫了原始的利用ICMP來探測主機是否在線等簡單監(jiān)控手段的時代。
隨著網(wǎng)絡(luò)治理需求的增長和變化，出現(xiàn)了很多網(wǎng)絡(luò)治理的標準和方法，其中比較有影響力的有兩個：
1) SNMP（Simple Network Management Protocol）即簡單網(wǎng)絡(luò)治理協(xié)議(SNMP)，SNMP協(xié)議是SGMP的升級版；
2) CMip（Common Management Information Protocol）即通用治理信息協(xié)議，建立在開放系統(tǒng)互連通信模式上的網(wǎng)絡(luò)治理協(xié)議。
在當時，IETF推薦采用基于OSI的CMIP協(xié)議作為網(wǎng)絡(luò)治理協(xié)議，并對它作了修改，修改后的協(xié)議被稱作CMOT(Common Management Over TCP/IP)。但是CMOT的各項標準遲遲未能出臺，在這種情況下，IETF決定把已有的SGMP進一步修改后，作為臨時的解決方案，而這個在SGMP基礎(chǔ)上開發(fā)的解決方案就是聞名的SNMP。
雖然推出了SNMP作為臨時解決方案，但是IETF并沒有放棄CMOT，并計劃將SNMP作為近期解決方案進一步開發(fā)，而把CMOT作為遠期解決方案，并且設(shè)計SNMP和CMOT使用相同的被管對象數(shù)據(jù)庫，因此，兩個協(xié)議共享一個一個公共的SMI（治理信息結(jié)構(gòu)）和一個MIB（治理信息庫）。
但是因為SNMP的簡單性，SNMP與CMOT這兩個協(xié)議在被治理對象的兼容是不現(xiàn)實的，SNMP只關(guān)注于一些簡單的數(shù)據(jù)、特性和變量，因此最后放棄了兩者之間的兼容，SNMP開始獨立發(fā)展。

SNMP v1
1988年，SNMP的最初的標準就已經(jīng)確定，現(xiàn)在我們把當時那個標準稱之為SNMPv1，從與OSI兼容的束縛中解脫后，SNMP取得了迅速的發(fā)展，很快被眾多的廠商設(shè)備所支持，許多聞名的網(wǎng)絡(luò)治理系統(tǒng)，如HP的OpenView、IBM的 NetView、Cabletron的 Spectrum、Microsoft的Systems Management Server（SMS）、Novell的ManageWise和開源的OpenNMS都是基于SNMP標準設(shè)計的。
SNMPv1協(xié)議的模型如下圖所示（注1）：

在被監(jiān)控端，嵌入到網(wǎng)絡(luò)設(shè)備中或主機設(shè)備的SNMP Agent收集設(shè)備的各種信息和統(tǒng)計數(shù)據(jù)并不斷的把這些數(shù)據(jù)記錄到MIB庫中，在治理端，通過SNMP協(xié)議向SNMP Agent發(fā)出SNMP報文，SNMP Agent收到報文后向SNMP治理端響應應答包。
SNMP報文中的GetRequest、GetNextRequest用來向SNMP Agent查詢MIB庫數(shù)據(jù)，比如可以查詢被監(jiān)控設(shè)備的CPU利用率等；SetRequest報文用來向SNMP Agent設(shè)置一些變量，比如可以利用SetRequest來重啟某臺設(shè)備；另外，SNMP Agent會收集一些系統(tǒng)的事件，并以SNMP Trap的方式向SNMP治理端通告事件。
本文不打算討論SNMP協(xié)議的細節(jié)，有關(guān)SNMP協(xié)議的具體細節(jié)和實現(xiàn)，可以查看相關(guān)的RFC文檔。(RFC 1157 等)

SNMP v2
為了彌補SNMPv1在安全性和其它方面的欠缺，IETF為SNMP v2做了大量的工作，其中大多數(shù)是為了尋找加強SNMP安全性的方法，1992年7月，出現(xiàn)了一個稱為SMP的SNMP新版本，SMP在功能和安全性兩方面提高了SNMP，最終SMP被接受為定義SNMPv2的基礎(chǔ)，并于1993年發(fā)布了SNMPv2。但是SNMP在安全方面的改進并沒有得到個方面的支持，1996年，IETF發(fā)布了一組新的RFC，取消了SNMPv2的安全特性的修改，主要通訊方式也重新采用 SNMPv1的基于Community（通訊字）的方式。
SNMP v2改進了SNMP v1的Trap通告方式，一種不同的事件格式被設(shè)計來替代SNMP v1的Trap事件格式。
同時，SNMP v2定義了兩種新的SNMP報文：GetBulk和Inform。GetBulk用來更有效率的查詢和接收批量的數(shù)據(jù)，而Inform可以被NMS（網(wǎng)絡(luò)治理系統(tǒng)）發(fā)送Trap信息到另一個NMS。

SNMP v3
1999年，SNMPv3的草案發(fā)布，在2002年3月，SNMPv3的標準正式出臺，SNMPv3針對SNMPv2的最大改進主要在安全性和治理能力兩個方面。
SNMPv3采用User-based安全模型和View-based訪問控制模型提供SNMP網(wǎng)絡(luò)治理的安全性，并利用加密的方式來避免信息的泄漏。

SNMPv3在安全性方面的改進主要有3點：
1）SNMP的數(shù)據(jù)報文將被使用DES加密來避免信息的非法泄漏；
2）SNMP治理端與SNMP Agent通訊時必須要通過認證（authenticated）來保證身份的正確性、信息的完整性合信息的合時性（timeliness）；
3）SNMP Agent實現(xiàn)了User-base和View-base訪問控制模型，訪問控制可以精確到數(shù)據(jù)級別，并且更加靈活利于控制。
現(xiàn)在一些設(shè)備和操作系統(tǒng)已經(jīng)開始支持SNMPv3，比如在UNIX世界比較有名的開源的SNMP實現(xiàn)——NET-SNMP( http://net-snmp.sourceforge.net/)，SNMP v3與SNMP v1/SNMPv2相比，基礎(chǔ)架構(gòu)和設(shè)計思路沒有本質(zhì)的改變，隨著一些新的網(wǎng)路治理協(xié)議和標準的提出，SNMP的發(fā)展可能已經(jīng)走到了盡頭，但是無論將來怎么發(fā)展，在5年之內(nèi)，SNMP絕對是業(yè)界事實上的網(wǎng)絡(luò)治理協(xié)議標準。


SNMP的缺點
即使SNMP協(xié)議已經(jīng)發(fā)展到第三版，但是因為SNMP出現(xiàn)時人們對網(wǎng)絡(luò)治理熟悉的局限性以及SNMP協(xié)議不得不向上兼容的做法使得SNMP擁有很多缺點，在這里，將討論SNMP協(xié)議的幾個主要的缺點：
1）SNMP協(xié)議輪詢的方式在一個大型網(wǎng)絡(luò)中可能會導致網(wǎng)絡(luò)通信擁塞情況的發(fā)生，并且SNMP協(xié)議把采集數(shù)據(jù)的負擔完全壓在了治理端之上；（注2）
在現(xiàn)在流行的千兆為主干的企業(yè)網(wǎng)中使用SNMP協(xié)議來監(jiān)控設(shè)備會導致網(wǎng)絡(luò)通信擁塞的說法可能有所危言聳聽，但是在一個大型網(wǎng)絡(luò)中，SNMP協(xié)議的確有浪費帶寬的嫌疑；而且在一個大型網(wǎng)絡(luò)中，面對近千臺設(shè)備上萬個OID采集點的數(shù)據(jù)采集量，治理端的負擔太重，治理端甚至不能在設(shè)定的時間間隔內(nèi)做一次完整的輪詢。
要解決上面的問題，現(xiàn)在流行的做法是在網(wǎng)絡(luò)的不同位置放置一些采集設(shè)備（或者稱之為探針），由這些采集設(shè)備利用SNMP協(xié)議向不同的SNMP Agent采集數(shù)據(jù)，并在某個時候把這些采集好的數(shù)據(jù)提交到主控端上，或是主控端需要某些數(shù)據(jù)的時候從采集設(shè)備提取。

2）SNMP Agent無法提供某個數(shù)據(jù)的歷史記錄；（注3）
SNMP Agent只能提供被監(jiān)控設(shè)備的當前狀態(tài)，某些時候，SNMP Agent也能提供設(shè)備在15分鐘或者更短時間內(nèi)的某些統(tǒng)計數(shù)據(jù)，但是一個設(shè)備的性能和狀態(tài)的歷史記錄對網(wǎng)絡(luò)優(yōu)化和性能調(diào)優(yōu)有著莫大的幫助，整個網(wǎng)絡(luò)的設(shè)備的歷史記錄還可以幫助決策者進行更有效、更合理的決策。
針對SNMP協(xié)議的這個說不上是缺點的缺點，治理端必須要在一定的間隔時間內(nèi)不斷的進行SNMP輪詢，并把輪詢得到的結(jié)果存儲在本地以便將來能夠?qū)@些數(shù)據(jù)進行查詢和分析。
比較有名的MRTG就是采用這種方式來統(tǒng)計網(wǎng)絡(luò)設(shè)備的流量的信息的，并可以生成各種統(tǒng)計數(shù)據(jù)的趨勢圖。但是不幸的是，很多網(wǎng)絡(luò)治理軟件就根本無法提供這些歷史數(shù)據(jù)。

3）SNMP協(xié)議不能以一種統(tǒng)一通用的數(shù)據(jù)描述格式保存所有被治理設(shè)備的標識、狀態(tài)和配置等信息。
假如說SNMP協(xié)議的前兩個缺點是可以用某些方式彌補的話，這里提到的第三個缺點是SNMP協(xié)議最致命的缺點。
SNMP這個缺點，在某種程度上來說主要是因為MIB庫的混亂所導致的，在SNMP協(xié)議被提出來的最初，定義了一些公用（public）的MIB庫，在SNMPv2版本，也定義了MIB-II，但是這些MIB庫并無法包容所有廠商的被監(jiān)控的信息，比如說Windows NT/2000的一些性能參數(shù)在這些公用的MIB庫中根本無法得到體現(xiàn)，因此Microsoft就不得不定義一系列自己的MIB庫來提供這些信息，由于這個原因，每個廠商都有大量的自己私有（private）的MIB庫，正因為這些私有MIB庫的存在，導致SNMP協(xié)議不能以一種統(tǒng)一通用的數(shù)據(jù)描述格式來保存所有被治理設(shè)備的各種信息。
下面我將舉兩個例子來具體說明這個問題：
假設(shè)我們需要通過SNMP協(xié)議來采集某些設(shè)備的CPU利用率的話，我們會發(fā)現(xiàn)，很多廠商提供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系列的操作系統(tǒng)上是.1.3.6.1.2.1.25.3.3.1.2、在Cisco路由器上卻又變成.1.3.6.1.4.1.9.2.1.58，研究下去，你會發(fā)現(xiàn)，MIB簡直就是個泥塘！
上面提到了MIB和OID的混亂，而第3個缺點的另外一層含義是：SNMP沒有定義一套數(shù)據(jù)表達規(guī)范來描述不同廠商的相同類別的數(shù)據(jù)。比如操作系統(tǒng)的用戶，在治理員看來無論什么操作系統(tǒng)，用戶就是用戶，雖然每個操作系統(tǒng)對用戶的描述的字段不同（比如Windows系列操作系統(tǒng)中的用戶的某些描述字段是UNIX操作系統(tǒng)中所沒有的），但是用戶就是用戶，用戶的描述再怎么變化，它也不會變成一個CPU，對于治理員來說，非凡是一個治理不同平臺、不同廠商設(shè)備的治理員來說，希望網(wǎng)管協(xié)議能夠把各種相同類別的信息歸納成一個統(tǒng)一的、通用的數(shù)據(jù)表達方式，比如我們剛才所提到的不同操作系統(tǒng)的用戶信息就可以歸納成一個通用的表達方式，某個平臺無法提供的字段即使為空也是無所謂的，最要害的是——統(tǒng)一、通用。
為什么說這個問題是SNMP的致命的缺點？簡單的來說這個缺點使得一個網(wǎng)絡(luò)中采用一套基于SNMP的網(wǎng)管平臺來治理不同廠商和平臺的設(shè)備的美夢成為了一個幻想，從現(xiàn)在的情況來看，我們不可能僅僅只利用一套網(wǎng)絡(luò)治理系統(tǒng)來有效的治理一個擁有AIX、HP-UX、Solaris、Linux、IBM Switch、Cisco Router、Cisco Switch、Foundry Switch、NetScreen、APC UPS、Windows NT/2000、Netware等等各種廠商和平臺的網(wǎng)絡(luò)中的所有設(shè)備（注4），這也是為什么Cisco的網(wǎng)絡(luò)環(huán)境用Ciscoworks來治理最方便最有效、而HP的OpenView雖然可以治理更多廠商的設(shè)備但是在Cisco網(wǎng)絡(luò)環(huán)境下不如Ciscoworks的主要原因之一（注5）。這也是當今主流的網(wǎng)絡(luò)和系統(tǒng)治理軟件無法有效的共享信息和協(xié)作的最主要的原因。

SNMP相關(guān)鏈接
http://www.faqs.org/faqs/snmp-faq/
SNMP FAQ

http://www.ietf.org/rfc.Html
IETF RFC Page
你可以在這里瀏覽SNMP相關(guān)的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的互聯(lián)網(wǎng)設(shè)計的，現(xiàn)在已經(jīng)被其它協(xié)議實現(xiàn)，如IPX/SPX，DECNET以及Appletalk等。

注2：這里列舉的缺點是制傳統(tǒng)意義上的SNMP的缺點，而這個缺點已經(jīng)被RMON有效的解決了，但是通常我們都習慣把SNMP與RMON分開來提，并且相當數(shù)量的支持SNMP的設(shè)備并不支持RMON，因此才會有這么一個提法。

注3：同注2

注4：這里所說的有效的治理是指能達到廠商自帶的或者廠商能提供的治理軟件的治理水平。

注5：除去這個原因，還有個主要原因是各個廠商都有自己的一些私有協(xié)議，而廠商自己的網(wǎng)管軟件在很大程度上都依靠這些私有協(xié)議。