本小节按照自上向下的方式讲述SNMP的框架组成，我们可以从物理层和协议层将其结构分解。SNMP的框架图，如图1-7所示。
1.物理层
首先从物理层的角度看，使用SNMP对网络进行管理应该包含：至少一台管理工作站或主机（NMS），一个或多个代理设备（Agent），或者还包括代理服务器，代理服务器也可称为委托代理（Proxy Agent）。这些名称或概念，在SNMP v3中都被称为SNMP应用程序实体，文章后续使用“实体”的称呼即源于此。
Agent：该实体能够响应管理节点的请求也能够主动产生通告消息；它位于管理系统的底层。在实际的网络管理中可以存在一个或者多个这样的实体。
NMS：该实体能够产生协议命令，能够接受通告消息；它位于管理系统的顶层。在实际的网络管理中至少包含一个这样的SNMP实体。
Proxy Agent：某些情况下，如不同（子）网络间，不同版本间的通信，还存在一种特殊的代理——委托代理。它用于实现SNMP请求和告警信息的转发，不同协议版本间的转换、翻译等功能。在这些情况下，Agent对NMS是透明的，它位于管理系统的中间层。
从C/S客户端和服务器模式上来看，代理可理解为服务端，管理站可理解为客户端。而当代理发出事件报告时，其相互关系暂时又对调了。
2.协议层
类似的也可以从协议层的角度看，SNMP包含以下几个部分：
SMI：（Structure of Management Information，管理信息结构）是ASN.1（Abstract Syntax Notation One，抽象语法标记）的一个子集，SMI规定了SNMP中可使用ASN.1中的元素、自定义的数据类型和宏等，由这些元素、数据类型、宏及其相关的语法可定义SNMP中的MIB。ASN.1更多的内容请参考第2章，SMI进一步的讲述内容请参考第3章。
MIB：管理信息库是Agent中可被管理对象的抽象描述。在1.2.1小节中有所提及，因为它不是SNMP里面特有的协议内容。在SNMP中，MIB是以树形结构组织进行查看的。树中的每个节点称为OID（Object identifier，对象标识），以类似于网址域名的方式组织，以整数表示各个节点，如1.3.6.4。
MIB中的对象直观地解释如下：
标量：只有单个值的管理对象/OID。假设节点1.3.6.1定义为标量，含义为本书的读者数量。那么每次下发1.3.6.1.0获取该节点信息时，就是单个值，可理解为一维数组。
表格：具有多个值的管理对象/OID。假设节点1.3.6.2定义为表格型类型，含义为本书在湖南、黑龙江、广东读者的数量。那么每次下发（1.3.6.2.1.0、1.3.6.2.2.0、1.3.6.2.3.0）获取时，就不止一个数据了，可理解为多维数组。
协议：协议规定了各个实体间通信必须遵循的规定，是客户端和服务端通信的约定。包括协议栈、报文格式、协议细节。每个SNMP协议报文称为PDU（Protocol Data Unit，协议数据单元），更多的内容可参考第5章。
更多有关MIB中的信息以及如何编写SNMP中的MIB请参考第4章。
我们知道SNMP最初是为基于TCP/IP的网络管理而发展起来的。SNMP是属于TCP/IP协议栈的应用层协议，它类似于HTTP、FTP协议。不过，SNMP下层的传输层使用的是不可靠协议UDP（User Datagram Protocol，用户数据包协议），相比TCP来说UDP更便捷、开销更低，这也是SNMP设计的简单原则之一，因为不需要其事先建立可靠的通信链接。这使得当对方网络出现部分故障时SNMP依然能够发出Trap（术语“陷进”，或理解为告警），很明显，TCP通信方式是不支持这种机制的。当然像往常一样，发出去的Trap不能确保对方能够收到。也正是因为如此，通信双方需要自己维护超时时间，并做出判断。
