Coap协议学习总结

Coap协议学习总结1、Coap协议介绍在2010年3月，CoRE工作组开始制定CoAP协议，到目前为止，该协议还没有定稿。CoAP协议是为物联网中资源受限设备制定的应用层协议。CoAP是受限制的应用协议(ConstrainedApplicationProtocol)的代名词。在最近几年的时间中，专家们预测会有更多的设备相互连接，而这些设备的数量将远超人类的数量。在这种大背景下，物联网和M2M技术应运而生。虽然对人而言，连接入互联网显得方便容易，但是对于那些微型设备而言接入互联网非常困难。在当前由PC机组成的世界，信息交换是通过TCP和应用层协议HTTP实现的。但是对于小型设备而言，实现TCP和HTTP协议显然是一个过分的要求。为了让小设备可以接入互联网，CoAP协议被设计出来。CoAP是一种应用层协议，它运行于UDP协议之上而不是像HTTP那样运行于TCP之上。CoAP协议非常的小巧，最小的数据包仅为4字节。为了克服HTTP对于受限环境的劣势，CoAP既考虑到数据报长度的最优化，又考虑到提供可靠通信。一方面，CoAP提供URI，REST式的方法如GET，POST，PUT和DELETE，以及可以独立定义的头选项提供的可扩展性。另一方面，CoAP基于轻量级的UDP协议，并且允许IP多播。而组通信是物联网最重要的需求之一，比如说用于自动化应用中。为了弥补UDP传输的不可靠性，CoAP定义了带有重传机制的事务处理机制。并且提供资源发现机制，并带有资源描述。CoAP协议不是盲目的压缩了HTTP协议，考虑到资源受限设备的低处理能力和低功耗限制，CoAP重新设计了HTTP的部分功能以适应设备的约束条件。另外，为了使协议适应物联网和M2M应用，CoAP协议改进了一些机制，同时增加了一些功能。下图1显示了HTTP和CoAP的协议栈。CoAP和HTTP在传输层有明显的区别。HTTP协议的传输层采用了TCP协议，而CoAP协议的传输层使用UDP协议，开销明显降低，并支持多播。事务层(Transactionlayer)用于处理节点之间的信息交换，同时提供组播和拥塞控制等功能。请求／响应层(Request／Responselayer)用于传输对资源进行操作的请求和响应信息。CoAP协议的REST构架是基于该层的通信。CoAP的双层处理方式，使得CoAP没有采用TCP协议，也可以提供可靠的传输机制。利用默认的定时器和指数增长的重传间隔时间实现CON(Confirmable)消息的重传，直到接收方发出确认消息。另外，CoAP的双层处理方式支持异步通信，这是物联网和M2M应用的关键需求之一。2、CoAP协议是否可以替换HTTP协议？CoAP并不能替代HTTP协议，但是对于那些小设备（256KBFlash32KBRAM20MHz主频）而言CoAP的确是一个好的解决方案。3、CoAP的交互模型和消息类型CoAP使用类似于HTTP的请求／响应模型：CoAP终端节点作为客户端向服务器发送一个或多个请求，服务器端回复客户端的CoAP请求。不同于HTTP，CoAP的请求和响应在发送之前不需要事先建立连接，而是通过CoAP信息来进行异步信息交换。CoAP协议使用UDP进行传输。这是通过信息层选项的可靠性来实现的。CoAP采用和HTTP协议相同的请求响应工作模式。CoAP协议共有4中不同的消息类型。CON——需要被确认的请求，如果CON请求被发送，那么对方必须做出响应。NON——不需要被确认的请求，如果NON请求被发送，那么对方不必做出回应。ACK——应答消息，如果接受到CON消息的响应。RST——复位消息，当接收者接受到的消息包含一个错误，接受者解析消息或者不再关心发送者发送的内容，那么复位消息将会被发送。虽然CoAP协议目前还在制定当中，但Contiki和TinyOS嵌入式操作系统已经支持CoAP协议。Contiki是一个多任务操作系统，并带有uIPv6协议栈，适用于嵌入式系统和无线传感器网络，它占用系统资源小，适用于资源受限的网络和设备。目前，火狐浏览器已经集成了Copper插件，从而实现了CoAP协议。但是这种方式只能读取传感器节点上的实时数据，而不能查看各种历史数据。为此，在Contiki系统的基础上，基于uIPv6STARTKIT无线网络开发套件，用自己编写的客户端程序实现了和数据库的交互，把历史数据存入数据库中，从而在Web浏览器端不仅可以访问传感器节点上的实时数据，还能查看历史数据，以便于分析问题。4、CoAP消息结构一个CoAP消息最小为4个字节，以下是CoAP协议不同部分的描述。【版本Version】：类似于IPv6和IPv6，仅仅是一个版本号。【消息类型MessageType】：CON，NON，ACK，RST。这些消息类型相当于HTTP协议的PUTGET等【消息IDMessageID】：每个CoAP消息都有一个ID，在一次会话中ID总是保持不变。但是在这个会话之后该ID会被回收利用。【标记Token】：标记是ID的另一种表现、【选项Options】：CoAP选项类似于HTTP请求头，它包括CoAP消息本身，例如CoAP端口号，CoAP主机和CoAP查询字符串等。【负载Payload】：真正有用的被交互的数据。图CoAP消息结构5、CoAP的URL在HTTP的世界中，正式RESTFul协议由于其简单性和适用性，在WEB应用中越来越受欢迎，这样的道理同样适用于CoAP。一个CoAP资源可以被一个URI所描述，例如一个设备可以测量温度，那么这个温度传感器的URI被描述为：CoAP://machine.address:5683/sensors/temperature。请注意，CoAP的默认UDP端口号为5683。6、CoAP观察模式在物联网的世界中，你需要去监控某个传感器例如温度或湿度等。在这种情况下，CoAP客户端并不需要不停的查询CoAP服务器端的数据变化情况。CoAP客户端可以发送一个观察请求到服务器端。从该时间点开始计算，服务器便会记住客户端的连接信息，一旦温度发生变化，服务器将会把新结果发送给客户端。如果客户端不在希望获得温度检测结果，那么客户端将会发送一个RST复位请求，此时服务器便会清除与客户端的连接信息。7、CoAP块传输CoAP协议的特点是传输的内容小巧精简，但是在某些情况下不得不传输较大的数据。在这种情况下可以使用CoAP协议中的某个选项设定分块传输的大小，那么无论是服务器或客户端可完成分片和组装这两个动作。8、CoAP协议的特点：（1）报头压缩：CoAP包含一个紧凑的二进制报头和扩展报头。它只有短短的4B的基本报头，基本报头后面跟扩展选项。一个典型的请求报头为10～20B。报头部分各字段的含义如下：V(Version)表示CoAP协议的版本号；T(Type)表示消息的信息类型；OC(OptionCount)表示头后面的可选的选项数量；Code表示消息的类型：请求消息、响应消息，或者是空消息；MessageID表示消息编号，用于重复消息检测、匹配消息类型等。（2）方法和URIs：为了实现客户端访问服务器上的资源，CoAP支持GET、PUT、POST和DELETE等方法。CoAP还支持URIs，这是Web架构的主要特点。(3)传输层使用UDP协议：CoAP协议是建立在UDP协议之上，以减少开销和支持组播功能。它也支持一个简单的停止和等待的可靠性传输机制。(4)支持异步通信：HTTP对M2M(Machine-to-Machine)通信不适用，这是由于事务总是由客户端发起。而CoAP协议支持异步通信，这对M2M通信应用来说是常见的休眠／唤醒机制。(5)支持资源发现：为了自主的发现和使用资源，它支持内置的资源发现格式，用于发现设备上的资源列表，或者用于设备向服务目录公告自己的资源。它支持RFC5785中的格式，在CoRE中用／．well—known／core的路径表示资源描述。(6)支持缓存：CoAP协议支持资源描述的缓存以优化其性能。(7)订阅机制：CoAP使用异步通信方式，用订阅机制实现从服务器到客户端的消息推送。实现CoAP的发布，订阅机制，它是请求成功后自动注册的一种资源后处理程序。是由默认的EVENT_和PERIODIC_RESOURCEs来进行配置的。它们的事件和轮询处理程序用EST．notify_subscribers()函数来发布。9、CoAP协议的火狐浏览器实现（B/S架构）B/S架构的系统结构如图9所示系统由用户浏览器、Web服务器、IPv6智能网关、MX231CC节点组成。用户浏览器通过HTTP协议访问Web服务器，MX231CC节点通过CoAP协议和IPv6智能网关进行通信，从而实现用户浏览器访问节点上资源的功能。图9中实线表示有线连接，虚线表示无线连接。在当前的Contiki2.5中，集成了CoAP03和CoAP06这两个版本。这两个文件在Contiki2.5的apps目录下，关于CoAP的核心内容都在这两个文件中。程序的主要部分为：AUTOSTART_PROCESSES（PERIODIC_RESOURCE（）为进程的主体部分。然后进行编译，编译成.elf文件，用JTAG下载器下载到节点上。节点地址设置为：2001：2：：11：22ff：：fe33：4499.这时，用火狐浏览器访问节点，因为火狐浏览器自带coap插件，如果用其他浏览器，那么需要进行coap的代理设置。以控制节点上的三色LED灯反转为例，用下面的请求格式：GETcoap://［］：/readings其中mote_ip_address是节点的IPv6地址，port_number是节点的端口号，readings是客户端请求的资源（温度）。所以在浏览器地址栏输入：coap://［2001：2：：11：22ff：fe33：4499］：61616/toggle，作用是让节点上的三色LED灯进行反转。服务器端的响应信息如图10所示。从浏览器端可以看出，CoAP协议支持Discover和Observe功能，具有GET、POST、PUT和DELETE等方法。Type表示信息类型为ACK，Code为200，表示成功完成客户端的请求。事务ID为38264，它用于重复信息检测，options为1表示有一个可选项，内容类型为text表示文本类型。由此可以看出，通过火狐浏览器的CoAP协议，可以访问节点上的传感器资源。10、CoAP协议的客户端实现（C/S架构）通过火狐浏览器可以实现COAP协议，但是只能查看实时数据，不能查看历史数据。为此，这里搭建了一个C/S架构的环境。如图11所示。图11中客户端软件是用基于。NET架构的C#语言编写的，数据库使用SQLServer2008.通过此程序，可以每隔10s读取一次数据，存入到数据库中。并可以通过前台的Web界面查看各种历史数据，包括温度、湿度、亮度等。插入数据库中的数据如图12所示，图中显示的是室内的亮度值。在Web浏览器端可以查看实时和历史数据，页面显示效果如图13所示。由此看出，基于C/S架构的方式，不仅可以显示实时数据，还可以查看历史数据，以便及时发现问题，更加具有实用性。