物联网传输协议MQTT与CoAP比较与应用

王剑秋，赵 一

(1.中国电信股份有限公司浙江分公司，浙江 杭州 310006；2.杭州电子科技大学)

物联网传输协议MQTT与CoAP比较与应用

王剑秋1，赵 一2

(1.中国电信股份有限公司浙江分公司，浙江 杭州 310006；2.杭州电子科技大学)

目前在物联网(IoT)领域还没有一个可以适用于所有场景的传输协议。在众多的物联网传输协议中，两个轻量级协议目前应用得最为广泛：MQTT(Message Queue Telemetry)和CoAP(Constrained Application Protocol)。文章从协议特点、实现方式、适用场景等方面对这两个协议进行对比，并进行了服务器端的连接测试仿真，根据两个协议的特点与仿真结果提出了不同应用场景下IoT传输协议选取的建议。

物联网；MQTT；CoAP；传输协议

0 引言

作为计算机、互联网与移动通信之后的世界信息产业的第三次浪潮，物联网将终端从PC扩展到了物品。“感知中国”于2009年由温家宝总理在政府工作报告中提出。自此，物联网正式被列入了国家五大新兴战略性产业之一，在中国全社会受到了极大的关注。

从国内BAT公司动向来看，阿里的云物联套件、百度开放云物联网服务IoT、腾讯QQ物联平台都将MQTT作为IM/IoT共享的接入服务。然而华为NB-IoT战略中的首款芯片Boudica 120以及LiteOS操作系统却支持CoAP协议。

本文针对MQTT和CoAP这两种在物联网领域较热门的协议进行对比，并分析它们各自适用的场景。

1 介绍

MQTT（消息队列遥测传输）和CoAP（约束应用协议）是适用于小型设备的目前应用最广泛的IoT标准协议。MQTT和CoAP都是开放标准，适合受限环境，支持异步通信和在IP上运行。

1.1 MQTT协议

MQTT是基于ISO标准的在TCP/IP协议之上的基于发布订阅的“轻量级”消息协议。它是专门为M2M通信而设计的，最初由IBM开发，覆盖全平台，而且可以基本上把所有的联网设备和外部设备连接起来[1]。

同HTTP协议一样，MQTT协议也是应用层协议。MQTT协议采用了发布/订阅消息模式，就是指发布者与订阅者并不是直接通过MQTT协议交互数据，而是分别与消息代理（Broker）通过MQTT交互数据。

MQTT采用客户端/服务器模型，每个传感器都是一个客户端，并通过TCP连接到被称为代理的服务器。MQTT是面向消息的，每个消息都是离散的数据块，对代理不透明[2]。每个消息都被发布到一个称为主题的地址。客户可以订阅多个主题，每个订阅主题的客户都收到发布到该主题的每个消息。MQTT同时提供三种消息QoS供开发者选择。

图1 MQTT结构图

1.2 CoAP协议

CoAP，即约束应用协议，与HTTP协议一样也是一种文档传输协议。而不同的是，CoAP是针对受限设备的需求来设计的，其数据包大小远小于HTTP的TCP流。CoAP通过UDP协议运行，客户端和服务器通过无连接数据包进行通信，并且允许UDP广播和多播用于寻址[3]。

图2 CoAP结构图

CoAP协议遵循客户端/服务器模型，客户端向服务器发出请求，服务器对请求发回响应[4]。模型中的客户端和服务器是功能逻辑上的划分,节点可兼具客户端和服务器的功能[5]。像HTTP一样，CoAP基于非常成功的REST模型：服务器使资源在URL下可用，客户端使用GET，PUT，POST和DELETE等方法访问这些资源。

2 实现

2.1 MQTT协议的实现

MQTT协议的成熟实现方式有很多，比较常见的有以下几种。

⑴Mosquitto

这是在生产环境中可用的代理之一，目前基于MQTT协议版本3.1和3.1.1。它包括C和C++客户端库，可实现消息订阅和发布，并可根据个人需求定制配置参数。Mosquitto是MQTT协议非常常用的一种测试与实现方式，在Github上较为活跃，是目前最受欢迎的实现方式之一。

⑵Mosca

Mosca是一个封装好的在Node.js上实现MQTT协议消息代理的一种方式。与此同时，它的作者也在维护MQTT.js这样一个运行在Node.js和浏览器的库。二者搭配起来可以轻松地定制所需完成的需求。但是Mosca目前只能提供消息质量QoS 0和QoS 1两个选项。

⑶HiveMQ

在大规模企业级的消息代理上，HiveMQ可以提供很好的支持。企业集成可以最低的延迟处理巨大的吞吐量，并进一步处理数据。HiveMQ服务器具有可扩展性，安全性和简单性。针对个人用户有免费版，是进行生产环境部署的一个很好的选择。

在客户端实现方面，Eclipse公司的paho项目几乎提供了所有主流语言对于MQTT客户端的实现方式。

表1MQTT客户端比较

2.2 CoAP协议的实现

CoAP协议的开源实现，有三个版本较为实用：

⑴libcoap

ibcoap是针对资源受限（如计算能力、射频范围、内存、带宽、网络数据包大小等）设备的轻量级应用程序协议的C实现。该协议由IETF作为RFC 7252标准化，并提供server和client方法，非常方便调试CoAP。

⑵Californium

基于Java实现的Californium是另一个很实用的开源版本。Californium是一个强大的CoAP框架，它为技术人员开发与调试提供了很方便的API。

⑶node-coap

node-coap是建立在Node.js的http库上的一个CoAP协议客户端和服务器的开源库。它也是一种很流行CoAP实现方式，具有快速搭建、简单配置的特性，可以方便地使用它进行测试与开发。

3 对比

3.1 特点

从上面的实现部分可以看出，MQTT和CoAP基本上可以在全平台实现，那么如何针对实际应用场景选择合适的协议就是一个需要解决的问题。首先，需要了解它们各自的特点。

从表2来看，二者从模型到基于的传输协议，以及安全性等方面都有很大的不同点，这让他们在某些方面的应用上相比对方更有优势。

表2MQTT与CoAP的对比

对于MQTT协议来说，相比CoAP它更加完善，是现阶段广域网上的设备之间进行通信的理想选择。它类似于微博，可以关注（订阅）所关心的人（话题），当关注的人发布新消息的时候，关注者就会收到来自服务器推送的信息。当然，与微博有所不同的是服务器在中间可以对订阅者的偏好进行过滤操作。由于采用了发布/订阅的模式，在带宽有限的情况下（如缺少强大网络覆盖的偏远地区），MQTT使物联网的发展成为了可能。

相比MQTT类似于微博，CoAP就像是传统的基于网站的业务，可以访问服务器资源，并且提交自己的数据。同MQTT一样，CoAP也对受限环境做了特殊的设计。不同于采用发布/订阅模式，CoAP采用了UDP传输协议，由于UDP允许广播和多播，其在带宽较少的地区的信息传输有更好的表现。

3.2 适用场景

在现实生活中，物联网正在成为我们生活的组成部分：大到智慧城市、医疗医护，小到汽车、智能家居。有很多场景，其实用两种协议都可以实现，但都有各自的优缺点。以下用最近比较火的共享单车为例子进行比较。

以MQTT协议作为通信协议，忽略掉在信息传输过程中比较复杂的认证、session等过程，简化之后每辆单车就相当于是客户端，云端服务器就等价于消息代理。单车作为客户端订阅各种与自己本身相关的事件主题，如开锁、故障等。当触发事件时，服务器向单车推送相应主题的消息，单车根据消息做出相应的处理。如果出现特殊事件，如服务器奔溃等，服务器可以作为发布者，向每辆单车推送停止运行的消息。

以CoAP实现，类似于传统的Web服务器，单车以GET、POST等方式向服务器发送请求，例如认证、故障等，服务器对请求作出响应，单车使用返回的响应信息进行相应的操作。此时，服务器需要识别每一辆单车，信息交互需要二者同时处于在线状态。

从上面例子看出，在实现共享单车的过程中，使用MQTT可以让客户端和服务器最大限度地解耦，二者不需要交互不需要同时在线。而CoAP最大的优势是其与绝大部分HTTP网站兼容。如果有一个现成的Web服务系统，那么使用CoAP是一个很好的选择。在诸如智能家居等已有现成的Web服务架构的领域，CoAP依赖其对于HTTP的兼容性，开发工作就相对简单。反过来如果以MQTT为传输协议，则需要对架构进行重新设计。

4 仿真实验

为了测试采用MQTT和CoAP协议的服务器在实际开发中的性能，此次设计了测试二者多线程连接的实验。实验采用的是Ubuntu 16.04的操作系统，压力测试软件采用了基于Java的JMeter，Java版本为1.8.0_121。

MQTT协议测试采用XMeter团队开发的MQTT-JMeter插件，服务器用Mosca搭建。而由于JMeter官方暂时没有对CoAP协议测试的支持，所以采用的是Elang2所写的jmeter-coap-sampler，需要在Github上下载并编译到本地环境。测试CoAP服务器使用 node-coap搭建。每组数据的线程数是5000，实测数据如下。

表3 MQTT与CoAP服务器不同硬件条件下连接测试结果

从仿真结果可以看出，随着内存的增大CoAP服务器对于连接请求的响应时间有下降趋势，而错误率逐渐趋向于0，吞吐量也逐渐增大。MQTT服务器的各项数据与CoAP服务器各项数据变化趋势基本相同（在4g内存时，受限于测试机器的性能，数据可能存在一定的误差）。

横向来看，在同一环境下，CoAP对于请求的处理时间、吞吐量均优于相同条件下MQTT服务器的数据，并且MQTT协议的连接错误率远高于CoAP协议。

由于上述实验中MQTT协议的服务器错误率偏高，又在此基础上新增了一组少并发情况下MQTT协议的连接实验。

表4 内存为2g条件下的MQTT服务器连接测试结果

从第二组实验结果可以看出，对于MQTT协议，在2g内存的条件下，500以内的线程数可以使服务器错误率趋近于0，而500以上线程数的条件下，错误率会急剧升高。

从两组仿真实验可以得出，CoAP服务器端各项数据均比MQTT协议表现突出，MQTT的性能需要更高的硬件条件才能更好地发挥。

5 结论

本文从国内大公司发展物联网所选的MQTT和CoAP协议入手，分析了它们目前比较普遍的实现方式以及各自的特点，并且从实际应用中分析在各种情形下协议的合理选取，之后通过实验仿真两个协议服务器的性能。

从特点分析以及实验结果可见，如果开发人员利用现有Web服务器架构来开发，使用CoAP是很好的选择。而如果将应用接入主流的第三方云平台，MQTT是更好的选择。从仿真实验可见，对于硬件要求不高的小型IoT项目开发，如智能家居等，CoAP可以很完美地实现；如果开发大型IoT，从各大公司开发的物联网云构架可以看得出来，到目前为止，MQTT是最好的选择。

[1]Hunkeler U,Hong L T,Stanford-Clark A.MQTT-S-A publish/subscribe protocol for Wireless Sensor Networks[C]//International Conference on Communication Systems Software and MIDDLEWARE and Workshops,2008.Comsware.IEEE,2008:791-798

[2]Bormann C,Castellani A P,Shelby Z.CoAP:An Application Protocol for Billions of Tiny Internet Nodes[J].IEEE Internet Computing,2012.16(2):62-67

[3]Sensinode.Constrained Application Protocol(CoAP)[J],2013.

[4]Al-Fuqaha A,Guizani M,Mohammadi M,et al.Internet of Things:A Survey on Enabling Technologies,Protocols,and Applications[J].IEEE Communications Surveys&Tutorials,2015.17(4):2347-2376

[5]陈旖,张美平,许力.WSN应用层协议MQTT-SN与CoAP的剖析与改进[J].计算机系统应用,2015.2:229-234

Comparison of IoT protocols MQTT and CoAP and their applications

Wang Jianqiu1,Zhao Yi2
（1.China Telecom Co.,Ltd.Zhejiang Branch,Hangzhou,Zhejiang 310006,China;2.HangzhouDianzi University）

At present,in the field of emerging Internet of Things(IoT),there is no transmission protocol can be applied to all scenarios.Among the many IoT protocols,two lightweight protocols are currently the most widely used:MQTT(Message Queue Telemetry)and CoAP(Constrained Application Protocol).This paper compares the two protocols from the characteristics of the protocol,the ways of implementation and the application scenarios,and simulates the server-side connection test.According to the characteristics of the two protocols and the simulation results,the proposal of selecting IoT transmission protocol in different application scenarios is put forward.

Internet of things；MQTT；CoAP；transmission protocol

TP3

A

1006-8228(2017)10-25-04

2017-08-14

王剑秋（1975-），男，杭州人，本科，中级工程师，主要研究方向：通讯工程与计算机技术。

10.16644/j.cnki.cn33-1094/tp.2017.10.008