snmp与netconf对比
SNMP 缺点
虽然 SNMP 的出现，在一定程度上解决了网络设备的管理问题。但面对现代大规模的网络来说，依然有着很多挑战：
1.性能不足，在下发和读取配置时，采用依次读取，效率低。
2.下发不足，支持写 MIB 的对象相对于读较少。
3.不支持事务机制，在配置下发失败是，无法回滚。
4.拓展性差，提供给外部的接口较少。
5.模型兼容性差，MIB 库混乱，无法适配所有厂商，导致定义各种私有 MIB 库
NETCONF 协议提供了一种更简单的方式来管理（"查询，配置，修改，删除"）设备，就像数据库操作中的 DML. 同时开放了 API 接口，当想要对设备进行操作时，直接通过调用 API 进行。
对于支持 NETCONF 的设备来说，至少能开启一个或多个 session。并且在每个 session 中应用的配置更改，都可以被全局的 session 监听到。这就让一个或多个 Manager(Client) 操作同一个设备（agent）成为了可能。
相比 SNMP 而言，有着如下的优势：
1.基于 RPC，增加了事务支持
2.优化查询功能，增加过滤查询方式
3.拓展性强，在其协议内部分为 4 层，各层之间相互独立
4更好的将配置和状态数据解耦，并区分状态数据（candidate, running, startup）
5易使用，结合提供的 API，实现可编程性的网络操作
6安全性更好，在传输层可选用 SSH，TLS 协议等。
7.NETCONF 采用 C/S 的架构，通过 RPC 在 client 和 server 间交流。client 可以是 Python 脚本或应用。server 一般指的是网络设备，在具体实现上有三个组件：
NETCONF agent：运行在网络设备上，用于接收和处理 RPC 请求。还可主动将一些告警事件通知客户端。
NETCONF 客户端：利用 NETCONF 协议对网络设备进行管理以及接收 agent 发出的告警通知。
datastore：在 NETCONF 中，区分了多个不同类型的 datastore, 这些 datastore 保存着不同状态下的设备信息。
关于 datastore 可以将其理解成一个可以获取和存储信息的概念。在具体实现上，可以是文件，数据库，内存等等。
在 NETCONF 中常用到三类 datastore：
1startup configuration datastore: 保存了设备启动时，加载的配置信息。
2candidate configuration datastore: 保存了想要运行的配置信息，修改该数据库时，并不会影响设备的真实配置。
3running configuration datastore: 保存了当前设备上正在生效的配置，修改时会影响真实的设备。
此外提到 datastore 就必须要提到一种数据模型语言 —— YANG，datestore 中就是以 YANG 的形式来约束配置的数据。
YANG 的出现结合上 NETCONF 和 RESTCONF 这样的协议，为自动化，可编程化的网络提供了强大的支持。YANG 的本质和之前 SNMP 中 MIB ASN 一样，作用都是以一种方式来约束数据，关于 YANG 之后会写一篇文章单独介绍
