CoAP协议中文版PDF电子书免费下载

　　使用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是一个协议，消息和请求/响应仅仅是其头部特性。