基于受限网络应用层协议的物联网应用研究与实现

摘要：

针对物联网（IoT）三层结构的研发独立性带来的应用研发高技术瓶颈问题，提出了基于受限网络应用层协议（CoAP）的解决方案。该方案在实现CoAP的基础上开发了CoAPHTTP网络，允许用户通过浏览器直接访问物联网节点，进行资源发现、数据查询和资源订阅等。经测试，模式未影响系统的响应速率，运行稳定，可支持多用户同时对物联网节点数据访问。CoAP模式能够有效帮助应用开发人员规避底层开发与数据交换开发复杂性，辅助其独立生成新的应用，为物联网应用开发提供了新的思路。

关键词：

物联网；6LoWPAN；受限网络应用层协议；网络；WebSocket

0引言

自2005年国际电信联盟（International Telecommunications Union，ITU）提出物联网（Internet of Things， IoT）的概念以来，已经经历了8年科研与市场领域的不断探索与尝试。虽然目前物联网设计与实现的标准化建设还在进行中，但通过多年的实践与发展，物联网逐渐形成了相对稳定的体系结构。从功能角度来看，目前物联网体系结构大多可分为3层：感知层、网络层和应用层[1]。感知层由多种物联网节点设备组成，负责信息的采集；网络层由多种网络协议与网关组成，负责信息的接收、解析与转发；应用层则是最终呈现在用户面前，与实际行业需求相结合的物联网智能应用。

目前，针对物联网应用的开发也是围绕这3个层次进行，需要对底层节点、通信协议以及上层界面分别开发实现。这样的开发模式大大增加了开发的成本，提升了物联网应用开发的技术瓶颈[2]；但同时也不利于物联网应用的拓展与创新，即用户实际接触的主要是应用层的界面与功能，而大部分的上层应用设计与开发人员无法直接获取物联网节点数据，实现独立开发，这也断绝了很多物联网业务拓展与创新的源头。

基于受限网络应用层协议（Constrained Application Protocol，CoAP）是一个专门面向低功耗的物联网，支持IPv6的，轻量级的网络传输协议。CoAP采用了与HTTP类似的特征，两种协议可以实现相互的映射。网络应用开发是大部分上层应用开发人员所擅长的，如果能够提供一种网络，让用户能够通过浏览器，直接访问到对应的物联网节点，获取或订阅该节点所感知的数据，这将大幅度降低物联网应用的开发难度，进一步实现物联网数据共享，提升物联网应用创新的可能性。

1现有研究

针对物联网应用开发的复杂性与高成本问题，目前的解决方案多是开发一套网关中间件，通过网关中间件实现与底层节点的通信。中间件在完成数据的接收、解析后，可以将数据存储入数据库，让应用层通过Web Service或直接访问获取数据；当然亦可以通过XMLRPC（XML Remote Procedure Call）或其他端口转发，将数据直接传输给上层应用，从而实现应用开发与底层开发分离[3-4]。中间件技术在一定程度上解决了该问题，但是由于中间件没有统一的标准，需自定义数据的接收与解析格式，对底层开发的普及造成了一定的困难；同时应用层对数据库的访问也存在各种各样的现实问题，很难实现数据的共享。CoAP的出现，给了人们一种新的解决思路。

2010年3月，互联网工程任务组（Internet Engineering Task Force，IETF）成立了CoRE （Constrained Restful Environment）工作组，旨在为受限的IP网络提供符合REST（REpresentation State Transfer）架构的应用层协议，也就是现在的CoAP[5]。CoAP也即是IETF工作组提出的6LoWPAN（IPv6 over Low power Wireless Personal Area Networks）协议栈下的应用层协议。6LoWPAN协议栈可以使物联网节点通过网关与传统网络实现互联，而其协议栈结构也与传统互联网协议结构相似，如图1所示。

6LoWPAN协议栈的物理层（Physical Layer， PHY）与链路层的媒体访问控制（中文名称与英文缩写不一致，请作相应调整。Media Access Control， MAC）采用基于IEEE的802.15.4标准，能够为在个人区域网络（10m左右）工作的简单器件，提供低能量消耗、低速率、低成本的组网传输协议。在网络层采用IPv6协议，并在其中添加了适配层，从而降低IP协议对运行环境要求，以适应传感器网络低功耗的需求[6]。传输层采用了资源消耗小、处理速度快、面向事务的用户数据报协议（User Datagram Protocol， UDP），但也由于UDP传输的不可靠性，而时常发生包丢失的问题，因此需要在应用层协议中进一步完善包检测与重发机制[7]。

CoAP作为该协议栈的应用层协议，拥有较短的报头，降低了开销与解析的复杂性；符合REST架构，并最大限度地降低了其与HTTP进行映射的复杂性；支持IPv6以及统一资源标识符（Universal Resource Identifier， URI）的访问；支持对目标节点的资源发现；支持简单的资源订阅以及由此产生的推送通知。虽然CoAP至今仍未最终定稿，不过TinyOS、Contiki等著名的嵌入式操作系统已经实现对其的支持，它也已经开始出现在了物联网应用中[8-9]。

在国内，已经有研究人员开始尝试CoAP的开发，如汤春明等[10]使用Contiki嵌入式操作系统，应用IPv6网关，实现了CoAP并能在火狐浏览器中访问，同时又开发了客户端程序，进一步实现了数据库功能。但国内目前未见对CoAP的设计与研发。

CoAP的实现，能够允许开发人员通过浏览器直接访问物联网节点，进行对节点资源的获取与控制，从而大幅度地降低物联网应用开发的复杂度[11]。Kovatsc等[9]此处是指代文献9吗？请明确。回复：此处没有文献引用，与文献9不相关，copper是Kovatsc在火狐应用平台上的一个工具，我们对之下载、使用后写入文章在火狐上提供了一个面向CoAP的插件copper，通过该插件可以实现对CoAP服务的访问，对节点进行Get、Post、Put以及Delete等方法的操作，并实现了资源发现、资源订阅以及大文件的分段传输。该插件基本实现了所有CoAP的功能，并能够支持CoAP的不同版本，但是由于其插件应用的局限性，通常被作为测试使用，很难在此基础上进行二次开发，或者进一步帮助应用开发人员进行开发。

相比之下，网页模式则更具灵活性，而在国际上已经出现了一些CoAP，最为著名的JCoAP系统，出自罗斯托克大学的开源项目，是基于Java开发，针对HTTPCoAP相互映射的网络，并且与Java SE和Android平台兼容。JCoAP可以运行在Apache服务器上，通过对浏览器发送地址请求的解析，实现了HTTP与CoAP的相互映射，并提供了完整的应用接口开发帮助手册。但是JCoAP还未对浏览器的资源订阅做出相应的支持。Simone Pinton等使用C++开发了一套支持HTTP、HTTPS、FTP面向CoAP映射的网络Squid，同时提供了一套完整了面向TinyOS的底层编程解决方案，方便开发人员的直接利用，但是的功能相对没有JCoAP完善，不支持payload功能，也就无法实现POST、PUT等方法，同时由于没有提供对应的应用开发接口，也大大降低了系统的可拓展性。

2体系架构

本文结合已有CoAP的基础与不足，并结合CoRE工作组对CoAP网络的规范[12]，开发了一套面向互联网应用的CoAP系统，以达到浏览器无需实现CoAP，通过URI直接对物联网节点实施访问，并实现资源发现、信息获取、资源订阅、大组块分段传输等功能，从而达到简化上层应用开发、节约开发成本的目的，让更多的应用开发人员能够投入物联网应用开发中来。

使用.NET FrameWork4框架，在实现了CoAP13 version所有功能的基础上，进一步实现了HTTPCoAP的相互映射，允许浏览器通过HTTP请求直接获取节点上的数据，并实现了payload功能，允许HTTP与CoAP中Get、Post、Delete和Put等方法的相互映射；同时结合CoAP对节点资源发现以及对节点信息的订阅功能，提供了Discovery、Observe方法。具体部署方案如图2所示。

启用后，系统会获取浏览器的所有Web请求，并对这些请求进行过滤分类。遇到非CoAP的请求时，则进行转发，并将响应回传给浏览器，不影响用户对浏览器的使用；当遇到CoAP请求时则进行如下3类操作。

1）一般数据。针对CoAP请求，会先进行HTTP到CoAP的地址映射，包含两种形式，含有特殊网关端口的直接映射http：//[：：1]：5638/foo以及嵌入式映射http：///coap/[：：1]：5638/foo，都会被映射为coap：//[：：1]：5638/foo。会新建一个对应的CoAP请求，生成请求报文，并通过对应网关端口，转发给物联网节点。监听到传回的数据后，会回发至浏览器，当遇到大型数据包（如图像数据），则会采用组块分段传输机制，当全部接收完毕后，统一回发至浏览器。

2）Discovery节点资源发现。由于一般节点都会拥有多个回传资源，如电池电量、电压、主要传感器数据等，因而当人们已知物联网节点的URI或者IPv6地址时，仍无法准确获取自己所想的资源。CoAP提供了资源发现的概念，在实现上采用了人们熟悉的主页形式。当浏览器访问节点根目录时，使用Discovery请求包，让节点发送回资源列表，在处理后，以主页的形式回传给用户，用户则可以通过点击链接，去访问这些资源。

3）Observe节点资源订阅。实时感知是物联网的一大特性，简单的访问并不能满足用户的需要。CoAP允许对节点进行简单的订阅，允许用户通过HTML5的WebSocket技术，实现节点资源数据的实时刷新。当接收到Observe请求时，会先向节点发送一个Observe项的CoAP请求，并通过的WebSocket服务端口与用户浏览器建立链接，每当收到节点的刷新数据时，就通过WebSocket实时传输并展现在浏览器上。

3关键技术

3.1CoAP引擎实现

为实现浏览器无需包含CoAP功能而直接访问物联网节点，需要首先在上完整地实现CoAP。CoAP是6LoWPAN协议栈下的应用层协议，采用了UDP的传输机制，由于UDP的不可靠性，CoAP采用了双层结构的设计，消息层（Messages Layer）负责节点间的通信，同时实现了消息匹配与错误重发、缓存与拥塞控制等功能。请求|响应层（Requests|Responses Layer）则实现具体的请求与响应操作。

CoAP在报文结构上，与HTTP协议结构相似，但报头部分进行了缩减，CoAP仅有不到4B的基本报头，同时也可包含之后的附加选项，如图3所示，V（Version）代表版本号默认为1；T（Type）代表消息类型如CON（连接）、ACK（确认）等；OC（Opitions Count）代表附加选项的个数，选项可包含URI信息、缓存时限、内容格式、路径信息与查询等；Message ID表示消息编号，以及Token用于进行验重与消息匹配的令牌。

本文依照CoAP13的协议规范，对协议的细节进行了实现。包括CoAP请求|响应方法、选项与负载、消息传输与匹配、组播与缓存、错误信息与处理、组块分段传输、资源发现与订阅等，开发完成了工程。工程的实现主要包含两大部分：基础类的开发与消息传输过程的实现。基础类主要完成消息层的报文格式与各类请求|响应方法以及CoAP的一些细节规范的实现，包括媒体类型、编码方式、选项类型、错误列表类和参数信息类等。在实现了所有基础类后，还需要进一步完善消息传输过程，特别是由于CoAP采用了节约功耗但不可靠的UDP，而容易出现漏包、消息重复、传输超时、网络拥塞等问题，因而需要在消息层，自行完成消息的匹配、超时响应、错误重传等过程，详细叙述如下。

当收到HTTP请求时，会根据请求的内容生成新的CoAP请求并发送，发送方法会触发生成对应的消息报文，并提供给通信控制器（Communicator）。通信控制器中包含4个实例化的类方法，首先由令牌控制层（TokenLayer）为每一对请求|响应提供唯一的令牌标记，再由消息控制层（MessageLayer）将消息转发给消息传输层（UDPplayer），它会将消息层的CoAP消息转给UDP进行传输。当节点完成请求并通过消息传输层将响应回发给消息控制层时，会首先利用消息匹配层（Matchinglayer）对请求|响应层进行匹配；再由消息控制层利用重传和指数退避策略（Exponential Backoff）来确保完成消息的可靠传输，匹配确认的对应重传信息并复位，检测并取消重复消息。当消息控制层确认消息无误时，会将报文提供给并触发请求类中的接收响应事件，最终将数据以HTTP响应的形式回发给浏览器。同时当回传的消息包含组块传输项时，会触发组块传输控制层（TransferLayer）的控制，由它将组块逐一存入内部缓存中，当全部传输完成后，统一发送回浏览器。具体过程如图4所示。

以上介绍了总体的类结构以及由它控制的消息传输机制，下面对提供的资源发现、资源订阅、组块传输的功能设计以及实现细节进行重点介绍。

3.2Discovery资源发现

每一个物联网节点都可以拥有多个资源，随着网络和设备的变化也会出现资源的添加或变化。为了方便用户自主使用资源，CoAP支持内置的资源发现，当然该方法也支持节点设备自主向系统公告资源列表。CoAP规定，对于某一节点使用coap：//[path]/.well？known/core访问时，可以获取该节点上的资源列表。这种资源获取方式，类似于访问网站首页时，获取所有子页面的链接，从而方便用户进一步的操作。本文在设计过程中，对于访问节点根目录http：//[path]：5638或节点首页http：//[path]：5638/index的请求会进行地址映射，形成CoAP规定的coap：//[path]：5638/.well？known/core的请求，获取该节点上的资源列表，并以首页形式发送给用户。

具体实现上，当节点接收到消息时，会将消息请求交付给对应的本地资源进行处理。当收到的是资源发现请求时，节点会将本地资源下的子资源列表生成一个响应，以链接、资源类型、资源描述的形式（；rt="block"；title="Large resource"），存入Payload中，回传给。由于节点报文大小的限制，在资源列表中，只会返回资源的相对路径。为了便于用户的直接使用，本文在中对每个资源的地址进行重新的组装large，在每个资源链接下方添加描述，并对可以进行资源订阅的节点添加标注，形成一组资源链接的列表形式。最终生成一个index页面，返回给用户，用户可以直接点击链接，进一步访问节点下的各类资源。

图5分别展示了与火狐copper组件对节点资源列表访问的示意图。相对于火狐copper插件只能运用于火狐浏览器内，为安装了该组件的开发人员进行调试使用，的应用更为灵活。虽然返回的只是一个简易的HTML页面，但它可以被所有浏览器访问，这也方便了应用开发人员的二次开发利用。开发人员可以通过调用将该页面嵌入自己的网站中，并使用CSS（Cascading Style Sheet）页面技术，为之添加与主题相关的图片与样式，实现画面美化，最终形成一个属于自身的物联网应用。

3.3Observe资源订阅

物联网数据具有实时性，对实时变化的数据进行响应是物联网应用的一大特色，因而资源的订阅显得尤为重要。而由于浏览器的请求/响应模式，对于每个Socket链接浏览器只能接受第一次数据，而无法达到数据实时更新的效果，这也是目前多数CoAP未对此功能进行支持的原因。

本文采用了HTML5下的WebSocket技术，使用SuperWebSocket开源类库，该类库支持页面与远程主机进行全双工的通信。在CoPA服务器上，添加了一个WebSocket服务端口。当用户首次访问可以订阅的节点资源时，在回发资源数据时，会生成一个订阅页面，包含当前返回资源的数值与订阅按钮，点击页面按钮即可实现订阅。

对于CoAP本身，它提供了一套资源订阅的机制。如图6所示，当向节点发送一个包含Observe选项的Get请求后，每当节点的资源数据更新时，节点会自动向回传响应包，同时当超过了最大缓存周期（MaxAge）仍未收到新数据时，会重发一次包含Observe选项的Get请求包，继续与节点建立订阅关系，并让节点将新的数据回报给。

本文的中，资源订阅的建立分为两步：第一步由浏览器向发送订阅请求，则向目标节点转发一个含Observe选项的Get请求，并将浏览器与目标节点配对存入Observe管理库，当收到新的节点数据后，会通过Observe管理库将消息配对传给WebSocket端口发送；第二步由浏览器向WebSocket服务端口，发送连接请求，当然该请求也会被端口监听，并以TCP请求的形式建立双向传输通道，WebSocket服务端口收到请求时，会回发握手包，握手成功后信息流就可以实时传输至浏览器。完成以上两步后，每当CoAP收到订阅的数据后，会通过WebSocket服务，向对应浏览器发送数值，实现数据的实时刷新。

资源订阅的结束，当浏览器关闭时，会触发WebSocket会话结束事件，在关闭会话的同时，会将浏览器与对应节点剔除出Observe管理库，并向物联网节点发送结束订阅的请求，从而结束订阅；同时物联网节点会每隔10个包向主机发送一个确认包，确认主机还在观测它，如收不到回应，则自动取消订阅，节省消耗。

3.4Blockwise大文件传输机制

虽然大部分的物联网资源都是简短的数据，但有时也会出现较长的数据包，如摄像头所拍摄的图像信息。由于物联网节点的传输效率较低，尽管6LoWPAN协议栈已经将其二层报文头限制在了127B内，但面对大数据量的数据传输仍然相形见绌，CoAP提供了组块分段传输的解决方案。

每次发出请求|响应包前，程序会在消息层中检测报文长度，当超过一定阈值时，则采取组块分段传输机制。传输过程中，每个响应包除了原始报头外，会添加一个Block选项。Block选项有两种形式：请求包中使用Block1选项，会出现在Put方法中；响应包中使用Block2选项，会出现在处理Get、Post、Put请求发回的响应包中。Block选项的报文主要包括三个属性：本次发送的编号（NUM）、是否有后续包（More bits）、内容长度（SZX）。

Block传输流程如图7所示，其中组块选项表示为Block2：NUM/M/SZX的形式。示例中程序将一次Get请求的响应包划分为了3次组块分段传输。当将Get请求发出后，收到的响应包中，包含Block2选项，示意为第一个组块包，有后续包，本次内容长度为128B；每次收到组块传输响应后，当判断有后续包时，继续发送Get请求，要求发送后续的组块包；当接收第三个组块包时，出现连接超时，遇到漏包将再次发送之前的请求，要求重传，直至收到再无后续包为止。

本文中定义，当程序检测发现包长超过1024B时，采用组块分段传输机制，每次组块传输的内容大小默认为512B。当服务器接收到响应包时，若检测出Block选项，则会在服务器上建立一块缓存，保留报头信息，将之后接收到匹配的组块以编号为次序逐一存储入缓存，当发生缺省时，则立即从缺省位置发回重传请求，直到收到再没有后续包为止。全部传输完成后，才会触发响应接收的监听，并将文件统一发回给浏览器。

4性能测试

本文将在内存大小为4GB，配置2.33GHz双核处理器的台式机上，使用IPv6智能网关（MXG300）与物联网节点（MX231）进行组网测试，在Windows 2003 Server环境下对进行了单点响应速度以及压力性能测试。

4.1单点响应速度测试

测试分别使用CoAP、CoAP客户端以及火狐copper组件对同一节点的资源列表、普通数据、大文件传输进行了响应速率测试。其中CoAP与CoAP客户端，以事件响应为起点，以事件处理完成为终点计时；火狐copper组件以鼠标单击按钮时为起点，以Sniffer中收到返回数据包时为终点计时。分别对各数据类型进行了20次测试，取平均值，结果如表1所示。

测试结果显示，可以有效与物联网节点进行数据访问，模式未影响系统的响应效率，同时与火狐copper组件相比响应速率大体相同，但由于无法精确定位火狐copper组件完成事件时间（缺省了其从收到数据包到完成展示的时间，可能实际值还会略高一些），不过两者性能差异并不显著。

4.2压力性能测试

使用HP LoadRunner11，对实际部署的物联网节点以及模拟节点数据，针对的压力性能进行了测试。按照50用户，每8s增加两位，后每5s减少5位的速度，对节点普通数据获取进行测试，用户变化如图8所示。

测试在4min内，分别对实际部署节点进行了500次访问，对模拟数据进行了4035次访问。其中对实际部署节点的访问，在峰值上发生了5次错误，有26个终止包（终止为用户离线带来的正常停止），对模拟数据的访问基本通过，具体结果如表2所示。

结果显示，运行正常，可稳定支持40名用户同时对实际物联网节点的数据访问需求，超过40人时所发生错误与丢包系底层节点处理能力超过载荷导致的。虽可同时支持的用户数量不大，其性能受两方面因素制约：一方面为实验平台自身处理能力影响，随着服务器性能提升，性能会更加优秀；更重要的一点为，CoAP属于应用层协议，虽然能够对自身进行组播与拥塞控制，但是的整体速度仍受限于底层组网的传输效率以及底层物联网节点的数据处理能力。

5结语

CoAP作为6LoWPAN协议栈的应用层协议，为物联网的上层应用开发提供了新的可能。本文结合现有CoAP的经验与不足，开发了一套CoAPProxy物联网应用。普通浏览器通过可以直接访问物联网节点，获取节点资源列表、资源数据。经测试模式未影响系统的响应速率，同时运行稳定，可支持多用户同时对物联网节点数据访问，但具体访问速率在很大程度上仍受限于底层组网的传输效率以及底层物联网节点的数据处理能力。本文详细介绍了的架构设计与核心功能，期望能为物联网应用开发人员提供新的设计思路，同时将在安全性和通用性方面作进一步加强。