无线物联网中CoAP协议的研究与实现(一)

能。请求/响应层（Request/Responselayer）用于传输对资源进行操作的请求和响应信息。CoAP协议的REST构架是基于该层的通信。CoAP的双层处理方式，使得CoAP没有采用TCP协议，也可以提供可靠的传输机制。利用默认的定时器和指数增长的重传间隔时间实现CON（Confirmable）消息的重传，直到接收方发出确认消息。另外，CoAP的双层处理方式支持异步通信，这是物联网和M2M应用的关键需求之一。

　　2.2 CoAP的订阅机制HTTP的请求/响应机制是假设事务都是由客户端发起的，通常叫做拉模型。这导致客户端不能高效的知统中，设备都是无线低功耗的，这些设备大部分时间是休眠状态，因此不能响应轮询请求。而CoRE认为支持本地的推送模型是一个重要的需求，也就是由服务器初始化事务到客户端。推送模型需要一个订阅接口，用来请求响应关于特定资源的改变。而由于UDP的传输是异步的，所以不需要特殊的通知消息。订阅机制如图4所示。

　　2.3 CoAP的交互模型CoAP使用类似于HTTP的请求/响应模型：CoAP终端节点作为客户端向服务器发送一个或多个请求，服务器端回复客户端的CoAP 请求。不同于HTTP，CoAP的请求和响应在发送之前不需要事先建立连接，而是通过CoAP信息来进行异步信息交换。CoAP协议使用UDP进行传输。这是通过信息层选项的可靠性来实现的。CoAP定义了四种类型的信息：可证实的CON（Confirmable）信息，不可证实的NON（Non- Confirmable）信息，可确认的ACK（Acknowledgement）信息和重置信息RST（Reset）。方法代码和响应代码包含在这些信息中，实现请求和响应功能。这四种类型信息对于请求/响应的交互来说是透明的。

　　CoAP的请求/响应语义包含在CoAP信息中，其中分别包含方法代码和响应代码。CoAP选项中包含可选的（或默认的）请求和响应信息，例如URI和负载内容类型。令牌选项用于独立匹配底层的请求到响应信息。

　　请求/响应模型：请求包含在可证实的或不可证实的信息中，如果服务器端是立即可用的，它对请求的应答包含在可证实的确认信息中来进行应答。图5是基本的 GET请求和响应模式，其中图5（a）表示成功发送请求和收到ACK确认信息，图5（b）表示重传了请求信息，然后才收到ACK确认信息。

　　虽然CoAP协议目前还在制定当中，但Contiki和TinyOS嵌入式操作系统已经支持CoAP协议。Contiki是一个多任务操作系统，并带有 uIPv6协议栈，适用于嵌入式系统和无线传感器网络，它占用系统资源小，适用于资源受限的网络和设备。目前，火狐浏览器已经集成了Copper插件，从而实现了CoAP协议。但是这种方式只能读取传感器节点上的实时数据，而不能查看各种历史数据。为此，在Contiki系统的基础上，基于 uIPv6START KIT无线网络开发套件，用自己编写的客户端程序实现了和数据库的交互，把历史数据 存入数据库中，从而在Web浏览器端不仅可以访问传感器节点上的实时数据，还能查看历史数据，以便于分析问题。