物聯(lián)網(wǎng)傳輸協(xié)議MQTT與CoAP比較與應(yīng)用

王劍秋，趙 一

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

物聯(lián)網(wǎng)傳輸協(xié)議MQTT與CoAP比較與應(yīng)用

王劍秋1，趙 一2

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

目前在物聯(lián)網(wǎng)(IoT)領(lǐng)域還沒有一個可以適用于所有場景的傳輸協(xié)議。在眾多的物聯(lián)網(wǎng)傳輸協(xié)議中，兩個輕量級協(xié)議目前應(yīng)用得最為廣泛：MQTT(Message Queue Telemetry)和CoAP(Constrained Application Protocol)。文章從協(xié)議特點、實現(xiàn)方式、適用場景等方面對這兩個協(xié)議進行對比，并進行了服務(wù)器端的連接測試仿真，根據(jù)兩個協(xié)議的特點與仿真結(jié)果提出了不同應(yīng)用場景下IoT傳輸協(xié)議選取的建議。

物聯(lián)網(wǎng)；MQTT；CoAP；傳輸協(xié)議

0 引言

作為計算機、互聯(lián)網(wǎng)與移動通信之后的世界信息產(chǎn)業(yè)的第三次浪潮，物聯(lián)網(wǎng)將終端從PC擴展到了物品?！案兄袊庇?009年由溫家寶總理在政府工作報告中提出。自此，物聯(lián)網(wǎng)正式被列入了國家五大新興戰(zhàn)略性產(chǎn)業(yè)之一，在中國全社會受到了極大的關(guān)注。

從國內(nèi)BAT公司動向來看，阿里的云物聯(lián)套件、百度開放云物聯(lián)網(wǎng)服務(wù)IoT、騰訊QQ物聯(lián)平臺都將MQTT作為IM/IoT共享的接入服務(wù)。然而華為NB-IoT戰(zhàn)略中的首款芯片Boudica 120以及LiteOS操作系統(tǒng)卻支持CoAP協(xié)議。

本文針對MQTT和CoAP這兩種在物聯(lián)網(wǎng)領(lǐng)域較熱門的協(xié)議進行對比，并分析它們各自適用的場景。

1 介紹

MQTT（消息隊列遙測傳輸）和CoAP（約束應(yīng)用協(xié)議）是適用于小型設(shè)備的目前應(yīng)用最廣泛的IoT標準協(xié)議。MQTT和CoAP都是開放標準，適合受限環(huán)境，支持異步通信和在IP上運行。

1.1 MQTT協(xié)議

MQTT是基于ISO標準的在TCP/IP協(xié)議之上的基于發(fā)布訂閱的“輕量級”消息協(xié)議。它是專門為M2M通信而設(shè)計的，最初由IBM開發(fā)，覆蓋全平臺，而且可以基本上把所有的聯(lián)網(wǎng)設(shè)備和外部設(shè)備連接起來[1]。

同HTTP協(xié)議一樣，MQTT協(xié)議也是應(yīng)用層協(xié)議。MQTT協(xié)議采用了發(fā)布/訂閱消息模式，就是指發(fā)布者與訂閱者并不是直接通過MQTT協(xié)議交互數(shù)據(jù)，而是分別與消息代理（Broker）通過MQTT交互數(shù)據(jù)。

MQTT采用客戶端/服務(wù)器模型，每個傳感器都是一個客戶端，并通過TCP連接到被稱為代理的服務(wù)器。MQTT是面向消息的，每個消息都是離散的數(shù)據(jù)塊，對代理不透明[2]。每個消息都被發(fā)布到一個稱為主題的地址。客戶可以訂閱多個主題，每個訂閱主題的客戶都收到發(fā)布到該主題的每個消息。MQTT同時提供三種消息QoS供開發(fā)者選擇。

圖1 MQTT結(jié)構(gòu)圖

1.2 CoAP協(xié)議

CoAP，即約束應(yīng)用協(xié)議，與HTTP協(xié)議一樣也是一種文檔傳輸協(xié)議。而不同的是，CoAP是針對受限設(shè)備的需求來設(shè)計的，其數(shù)據(jù)包大小遠小于HTTP的TCP流。CoAP通過UDP協(xié)議運行，客戶端和服務(wù)器通過無連接數(shù)據(jù)包進行通信，并且允許UDP廣播和多播用于尋址[3]。

圖2 CoAP結(jié)構(gòu)圖

CoAP協(xié)議遵循客戶端/服務(wù)器模型，客戶端向服務(wù)器發(fā)出請求，服務(wù)器對請求發(fā)回響應(yīng)[4]。模型中的客戶端和服務(wù)器是功能邏輯上的劃分,節(jié)點可兼具客戶端和服務(wù)器的功能[5]。像HTTP一樣，CoAP基于非常成功的REST模型：服務(wù)器使資源在URL下可用，客戶端使用GET，PUT，POST和DELETE等方法訪問這些資源。

2 實現(xiàn)

2.1 MQTT協(xié)議的實現(xiàn)

MQTT協(xié)議的成熟實現(xiàn)方式有很多，比較常見的有以下幾種。

⑴Mosquitto

這是在生產(chǎn)環(huán)境中可用的代理之一，目前基于MQTT協(xié)議版本3.1和3.1.1。它包括C和C++客戶端庫，可實現(xiàn)消息訂閱和發(fā)布，并可根據(jù)個人需求定制配置參數(shù)。Mosquitto是MQTT協(xié)議非常常用的一種測試與實現(xiàn)方式，在Github上較為活躍，是目前最受歡迎的實現(xiàn)方式之一。

⑵Mosca

Mosca是一個封裝好的在Node.js上實現(xiàn)MQTT協(xié)議消息代理的一種方式。與此同時，它的作者也在維護MQTT.js這樣一個運行在Node.js和瀏覽器的庫。二者搭配起來可以輕松地定制所需完成的需求。但是Mosca目前只能提供消息質(zhì)量QoS 0和QoS 1兩個選項。

⑶HiveMQ

在大規(guī)模企業(yè)級的消息代理上，HiveMQ可以提供很好的支持。企業(yè)集成可以最低的延遲處理巨大的吞吐量，并進一步處理數(shù)據(jù)。HiveMQ服務(wù)器具有可擴展性，安全性和簡單性。針對個人用戶有免費版，是進行生產(chǎn)環(huán)境部署的一個很好的選擇。

在客戶端實現(xiàn)方面，Eclipse公司的paho項目幾乎提供了所有主流語言對于MQTT客戶端的實現(xiàn)方式。

表1MQTT客戶端比較

2.2 CoAP協(xié)議的實現(xiàn)

CoAP協(xié)議的開源實現(xiàn)，有三個版本較為實用：

⑴libcoap

ibcoap是針對資源受限（如計算能力、射頻范圍、內(nèi)存、帶寬、網(wǎng)絡(luò)數(shù)據(jù)包大小等）設(shè)備的輕量級應(yīng)用程序協(xié)議的C實現(xiàn)。該協(xié)議由IETF作為RFC 7252標準化，并提供server和client方法，非常方便調(diào)試CoAP。

⑵Californium

基于Java實現(xiàn)的Californium是另一個很實用的開源版本。Californium是一個強大的CoAP框架，它為技術(shù)人員開發(fā)與調(diào)試提供了很方便的API。

⑶node-coap

node-coap是建立在Node.js的http庫上的一個CoAP協(xié)議客戶端和服務(wù)器的開源庫。它也是一種很流行CoAP實現(xiàn)方式，具有快速搭建、簡單配置的特性，可以方便地使用它進行測試與開發(fā)。

3 對比

3.1 特點

從上面的實現(xiàn)部分可以看出，MQTT和CoAP基本上可以在全平臺實現(xiàn)，那么如何針對實際應(yīng)用場景選擇合適的協(xié)議就是一個需要解決的問題。首先，需要了解它們各自的特點。

從表2來看，二者從模型到基于的傳輸協(xié)議，以及安全性等方面都有很大的不同點，這讓他們在某些方面的應(yīng)用上相比對方更有優(yōu)勢。

表2MQTT與CoAP的對比

對于MQTT協(xié)議來說，相比CoAP它更加完善，是現(xiàn)階段廣域網(wǎng)上的設(shè)備之間進行通信的理想選擇。它類似于微博，可以關(guān)注（訂閱）所關(guān)心的人（話題），當關(guān)注的人發(fā)布新消息的時候，關(guān)注者就會收到來自服務(wù)器推送的信息。當然，與微博有所不同的是服務(wù)器在中間可以對訂閱者的偏好進行過濾操作。由于采用了發(fā)布/訂閱的模式，在帶寬有限的情況下（如缺少強大網(wǎng)絡(luò)覆蓋的偏遠地區(qū)），MQTT使物聯(lián)網(wǎng)的發(fā)展成為了可能。

相比MQTT類似于微博，CoAP就像是傳統(tǒng)的基于網(wǎng)站的業(yè)務(wù)，可以訪問服務(wù)器資源，并且提交自己的數(shù)據(jù)。同MQTT一樣，CoAP也對受限環(huán)境做了特殊的設(shè)計。不同于采用發(fā)布/訂閱模式，CoAP采用了UDP傳輸協(xié)議，由于UDP允許廣播和多播，其在帶寬較少的地區(qū)的信息傳輸有更好的表現(xiàn)。

3.2 適用場景

在現(xiàn)實生活中，物聯(lián)網(wǎng)正在成為我們生活的組成部分：大到智慧城市、醫(yī)療醫(yī)護，小到汽車、智能家居。有很多場景，其實用兩種協(xié)議都可以實現(xiàn)，但都有各自的優(yōu)缺點。以下用最近比較火的共享單車為例子進行比較。

以MQTT協(xié)議作為通信協(xié)議，忽略掉在信息傳輸過程中比較復雜的認證、session等過程，簡化之后每輛單車就相當于是客戶端，云端服務(wù)器就等價于消息代理。單車作為客戶端訂閱各種與自己本身相關(guān)的事件主題，如開鎖、故障等。當觸發(fā)事件時，服務(wù)器向單車推送相應(yīng)主題的消息，單車根據(jù)消息做出相應(yīng)的處理。如果出現(xiàn)特殊事件，如服務(wù)器奔潰等，服務(wù)器可以作為發(fā)布者，向每輛單車推送停止運行的消息。

以CoAP實現(xiàn)，類似于傳統(tǒng)的Web服務(wù)器，單車以GET、POST等方式向服務(wù)器發(fā)送請求，例如認證、故障等，服務(wù)器對請求作出響應(yīng)，單車使用返回的響應(yīng)信息進行相應(yīng)的操作。此時，服務(wù)器需要識別每一輛單車，信息交互需要二者同時處于在線狀態(tài)。

從上面例子看出，在實現(xiàn)共享單車的過程中，使用MQTT可以讓客戶端和服務(wù)器最大限度地解耦，二者不需要交互不需要同時在線。而CoAP最大的優(yōu)勢是其與絕大部分HTTP網(wǎng)站兼容。如果有一個現(xiàn)成的Web服務(wù)系統(tǒng)，那么使用CoAP是一個很好的選擇。在諸如智能家居等已有現(xiàn)成的Web服務(wù)架構(gòu)的領(lǐng)域，CoAP依賴其對于HTTP的兼容性，開發(fā)工作就相對簡單。反過來如果以MQTT為傳輸協(xié)議，則需要對架構(gòu)進行重新設(shè)計。

4 仿真實驗

為了測試采用MQTT和CoAP協(xié)議的服務(wù)器在實際開發(fā)中的性能，此次設(shè)計了測試二者多線程連接的實驗。實驗采用的是Ubuntu 16.04的操作系統(tǒng)，壓力測試軟件采用了基于Java的JMeter，Java版本為1.8.0_121。

MQTT協(xié)議測試采用XMeter團隊開發(fā)的MQTT-JMeter插件，服務(wù)器用Mosca搭建。而由于JMeter官方暫時沒有對CoAP協(xié)議測試的支持，所以采用的是Elang2所寫的jmeter-coap-sampler，需要在Github上下載并編譯到本地環(huán)境。測試CoAP服務(wù)器使用 node-coap搭建。每組數(shù)據(jù)的線程數(shù)是5000，實測數(shù)據(jù)如下。

表3 MQTT與CoAP服務(wù)器不同硬件條件下連接測試結(jié)果

從仿真結(jié)果可以看出，隨著內(nèi)存的增大CoAP服務(wù)器對于連接請求的響應(yīng)時間有下降趨勢，而錯誤率逐漸趨向于0，吞吐量也逐漸增大。MQTT服務(wù)器的各項數(shù)據(jù)與CoAP服務(wù)器各項數(shù)據(jù)變化趨勢基本相同（在4g內(nèi)存時，受限于測試機器的性能，數(shù)據(jù)可能存在一定的誤差）。

橫向來看，在同一環(huán)境下，CoAP對于請求的處理時間、吞吐量均優(yōu)于相同條件下MQTT服務(wù)器的數(shù)據(jù)，并且MQTT協(xié)議的連接錯誤率遠高于CoAP協(xié)議。

由于上述實驗中MQTT協(xié)議的服務(wù)器錯誤率偏高，又在此基礎(chǔ)上新增了一組少并發(fā)情況下MQTT協(xié)議的連接實驗。

表4 內(nèi)存為2g條件下的MQTT服務(wù)器連接測試結(jié)果

從第二組實驗結(jié)果可以看出，對于MQTT協(xié)議，在2g內(nèi)存的條件下，500以內(nèi)的線程數(shù)可以使服務(wù)器錯誤率趨近于0，而500以上線程數(shù)的條件下，錯誤率會急劇升高。

從兩組仿真實驗可以得出，CoAP服務(wù)器端各項數(shù)據(jù)均比MQTT協(xié)議表現(xiàn)突出，MQTT的性能需要更高的硬件條件才能更好地發(fā)揮。

5 結(jié)論

本文從國內(nèi)大公司發(fā)展物聯(lián)網(wǎng)所選的MQTT和CoAP協(xié)議入手，分析了它們目前比較普遍的實現(xiàn)方式以及各自的特點，并且從實際應(yīng)用中分析在各種情形下協(xié)議的合理選取，之后通過實驗仿真兩個協(xié)議服務(wù)器的性能。

從特點分析以及實驗結(jié)果可見，如果開發(fā)人員利用現(xiàn)有Web服務(wù)器架構(gòu)來開發(fā)，使用CoAP是很好的選擇。而如果將應(yīng)用接入主流的第三方云平臺，MQTT是更好的選擇。從仿真實驗可見，對于硬件要求不高的小型IoT項目開發(fā)，如智能家居等，CoAP可以很完美地實現(xiàn)；如果開發(fā)大型IoT，從各大公司開發(fā)的物聯(lián)網(wǎng)云構(gòu)架可以看得出來，到目前為止，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應(yīng)用層協(xié)議MQTT-SN與CoAP的剖析與改進[J].計算機系統(tǒng)應(yīng)用,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-），男，杭州人，本科，中級工程師，主要研究方向：通訊工程與計算機技術(shù)。

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