• REST&RESTful
• RESTCONF
• SNMP&Telemetry

REST&RESTful

REST 指的是一组架构约束条件和原则，并不是一种协议或应用。满足这些约束条件和原则的应用程序或设计就是 RESTful，REST也可以做为一种设计或约束条件，但更多的看起来像是形容词，有点类似于OSPF当中的FULL状态。

REST 这种设计方法旨在让降低开发的复杂性，提高系统的可伸缩性，基于REST方法设计开发的协议或软件就可以称做是类REST风格的协议或软件，RESTCONF就是这样一种协议，RESETCONF是一种标准化地协议。

RESTCONF

RESETCONF与NETCONF功能类似，为什么RESETCONF更受欢迎呢？

更正规：RESTCONF是一种标准的协议，而NETCONF只是一种方法论或协议集而已。

表现形式更灵活：RESTCONF的建模语言有XML和JSON两种选择，而NETCONF就只有XML一种选择，JSON比XML更简单明了。

复杂性更低：NETCONF在传输层调用ssh这种协议，而RESETCONF在传输层调用的是https，两者都能实现传输且加密的能力，但HTTPS更容易被技术人员接受，因为HTTPS的应用场景也比ssh更广，运维人员和程序员接受起来都更容易。

学习门槛更底：NETCONF在操作层里面有所谓的能力集，里面有各种各样的RPC方法，这些方法都是NETCONF自定义的，比如说get、get-conf、edit等一大堆，而RESETCON就直接使用了HTTP的那几种方法，比如put、get，post大家都很熟悉了，常用的方法也就五六种，而且还有返回的状态码，对问题的排查也很方便，而且资源的定位也使用使用了HTTP的URL。

总之，RESTCONF调用HTTP是明智的选择，用一个http替代了原来的ssh和rpc，化繁为简的同时能力性还没有减弱。

• 至于在私有化上，两都都是公开标准，大家都可以使用，可问题是YANG的类型有很多种，而且有很多是私有化的。
• NETCONF与RESETCONF在内容层都是使用YANG这种建模语言，因此我们从NETCONF过渡到RESTCONF还是比较容易的。

值得一提的是http当中的PUT的方法，它可以完全的覆盖，比如我们将一个二层接口转换成三层，并且在三层上进行了IP地址的配置，但现在我们需要直接将接口再转换成二层，其实你不能直接进行转换的，因为设备的系统会报错，你必须得先删除掉IP地址，才能转换接口的类型，而通过RESTCONF的PUT方法我们就可以直接覆盖接口的配置，不需要提前删除。也就说你如果使用RESTFUL的话，那你完全可以仅仅使用get和put两种方法，其它的方法完全都不用管。

SNMP&Telemetry

RESTCONF是NETCONF的升级，而Telemetry则是SNMP的升级。SNMP的全称是简单的网络管理协议，确实如此，面对现在的海量设备SNMP已经不足以应对了，Telemetry做为新一代监控和数据采集技术登场；

SNMP的问题：

• 响应慢，当网络发生问题时，我们却在SNMP的监控当中并没有发现问题，这是因为SNMP是分钟级的协议，实时性非常差劲。
• 性能消耗严重，如果我们把采集的时间必小，无疑又会加重IO、CPU的负担，让设备的负载过高，SNMP通常是客户端周期性的主动请求，然后服务端响应，负载容易突发变高。
• 基于UDP，可靠性差；
• 复杂性高，使用MIB数据结构，使用复杂。

Telemetry的优势：

• 响应速度快，Telemetry采用了更优秀的开发设计，响应快，可达到秒级。

• 变被动为主动，Telemetry不再是等着客户端询问，而是主动的将消息发送给采集器，这样设备掌握主动权，对性能的损耗能灵活调整，而且产生和发送的数据都带有时间戳，查询起来比较方便。

• 可以将请求或响应打包进行传送，这样可以减少报文交互次数，这就类似TCP可以四次挥手，也可以三次。

• 采用YANG这种建模语言，数据结构兼容性更好，更方便处理。

华为的解决方案：

campusinsight做为采集器，与设备之间就是采用Telemetry技术，所有的设备都将数据上报到它上面进行统一的分析。由于是YANG这种数据模型，数据更加结构化，而且能承载的信息更多，这个地方有点类似于NETCONF，Telemetry也是使用YANG来承载GRPC（这种RPC是谷歌特殊优化过的RPC），RPC里面包裹GPB编码格式的数据进行传输。