使用web服务(web API)已经非常普遍,大多应用都在使用基于web的REST 架构。 Constrained RESTful Environments(CoRE)的工作目标是采用恰当的方式在受限节点(如 8位微控制器、较小RAM和ROM)和受限网络(例如6LoWPAN,[RFC4944])上实现REST 架构。6LoWPAN等受限网络支持把IPv6数据包分片成为小的链路层数据帧。然而,这导致数据发送成功率的下降。CoAP协议的设计目标之一是使数据包开销尽可能小,以减少分片的发生。 CoAP目标是设计一个通用的网络协议,满足受限环境的特殊需求,特别考虑了能源、楼宇自动化和其它M2M应用。CoAP不是对HTTP[RFC2616]协议的压缩,而是实现了REST的一个子集,并为M2M应用程序做了优化。尽管CoAP协议可以被当作一个HTTP压缩之后变得更紧凑的协议来使用,但更重要的是它还提供了M2M的一些特性,例如内置的资源发现、多播支持和异步消息交换。本文档描述了CoAP协议,它可以很容易的与HTTP协议互相转换以集成到现有的web中,同时满足了许多特定的需求,如多播支持、非常小的开销和足够简单以适应受限环境和M2M应用。
CoAP协议的交互模型与HTTP的客户端/服务端模型类似。然而,在M2M的交互场景中,一个使用CoAP协议的设备通常既是客户端又是服务端。CoAP中的请求与HTTP协议中的请求相同,是由客户端发起的,请求一个位于服务端的资源(用URI标识),执行一个动作(用 Method Code标识)。然后服务端发回一个响应,带有一个响应代码(Response Code),这个响应中有可能也包含一个资源的表现(附带响应格式)。与HTTP协议不同的是,CoAP的交互是异步的,构建于面向数据报的传输协议,如UDP。交互是通过一个消息层来实现的,消息层提供了可选的可靠性支持(采用指数回退)。CoAP协议中定义了四种类型的消息: CON, NON, ACK和RST。这四种类型的消息中包含有请求和响应标识码,标识着这些消息是请求还是响应。请求可以包含在CON和NON两种类型中,而响应则除了可以包含在CON和NON之中,还可以包含在附带响应的ACK中。从逻辑上,可以把CoAP协议划分为两层:消息层,用于处理UDP数据包和异步;请求/响应层,使用Method和Response Code,具体见图1。当然,CoAP是一个协议,消息和请求/响应仅仅是其头部特性。
声明:本文内容及配图由入驻作者撰写或者入驻合作网站授权转载。文章观点仅代表作者本人,不代表电子发烧友网立场。文章及其配图仅供工程师学习之用,如有内容侵权或者其他违规问题,请联系本站处理。 举报投诉
全部0条评论
快来发表一下你的评论吧 !