MQTT協(xié)議在物聯(lián)網(wǎng)中的應用研究

龔永罡 付俊英 汪昕宇 王蘊琪 高 爽

(北京工商大學計算機與信息工程學院，北京 100048)

1 引言

通信對于物聯(lián)網(wǎng)來說是非常常見和至關(guān)重要的，不管是移動通信技術(shù)還是近距離無線傳輸技術(shù)，都會對物聯(lián)網(wǎng)的發(fā)展產(chǎn)生影響。而在通信中，通信協(xié)議是指雙方實體完成通信或服務必須遵循的規(guī)則和約定，顯得尤為重要。在物聯(lián)網(wǎng)的三層體系結(jié)構(gòu)中，感知層和應用層需要通過網(wǎng)絡層進行通信，目前TCP/IP已經(jīng)成為互聯(lián)網(wǎng)的事實標準，物聯(lián)網(wǎng)通信協(xié)議主要是運行在互聯(lián)網(wǎng)TCP/IP協(xié)議之上的設備通訊協(xié)議，負責設備通過互聯(lián)網(wǎng)進行通信和數(shù)據(jù)交換。由于HTTP協(xié)議開發(fā)成本低，開放性高；在構(gòu)建物聯(lián)網(wǎng)系統(tǒng)時，很多廠商都基于HTTP協(xié)議進行開發(fā)。但在資源緊缺型的嵌入式系統(tǒng)中或網(wǎng)絡帶寬非常昂貴的環(huán)境中，HTTP協(xié)議并不適用。MQTT協(xié)議具有低功耗、開放、簡單、輕量級以及易于實現(xiàn)的特點，使其即便是在資源有限的環(huán)境中也能易于使用，廣泛應用于遙感、智能家居、能源監(jiān)測和醫(yī)療應用等領域，是物聯(lián)網(wǎng)的重要組成部分。

本文討論并通過實驗對比了HTTP協(xié)議和MQTT協(xié)議在智能家居領域的應用，測試結(jié)果表明MQTT在降低功耗和推送功能開發(fā)上優(yōu)勢明顯。

2 物聯(lián)網(wǎng)通信協(xié)議概述

目前在物聯(lián)網(wǎng)領域中，可以采用的消息傳輸方案主要有以下幾種：HTTP協(xié)議、Ajax輪詢、Websocket、MQTT和Co-AP協(xié)議，以下對HTTP和MQTT做一下介紹。

2.1 HTTP協(xié)議

HTTP協(xié)議的特點是簡捷、快速，適用于分布式超媒體信息系統(tǒng)，是一個基于請求和響應模式的應用層協(xié)議。它承載于TCP協(xié)議之上，通過客戶端建立TCP連接，向服務器指定端口（默認端口80）發(fā)出HTTP請求，服務器接收到請求后返回一個響應消息。HTTP協(xié)議包含傳輸信息和命令，適用于內(nèi)聯(lián)網(wǎng)／因特網(wǎng)應用系統(tǒng)之間的通信來促成各種應用資源超媒體訪問集成，也可用于Web訪問。目前流行的AJAX、WebSocket和CoAP協(xié)議，本質(zhì)上都是在HTTP基礎封裝的，沒有改變HTTP基礎的特點。由于HTTP協(xié)議開放程度高，開發(fā)成本低，所以在構(gòu)建物聯(lián)網(wǎng)系統(tǒng)時，很多廠商都是基于HTTP協(xié)議進行開發(fā)的。

2.2MQTT協(xié)議

2.2.1 MQTT協(xié)議分析

由Arcom（現(xiàn)在的Eurotech）和IBM公司開發(fā)的MQTT（Message Queuing Telemetry Transport，消息隊列遙測傳輸）協(xié)議是一種輕量級基于發(fā)布/訂閱模式的消息傳輸協(xié)議。MQTT協(xié)議在計算方面受到了限制，適用于不可靠的網(wǎng)絡設備和低帶寬所設計的協(xié)議。它的特點是小型傳輸、功耗小、網(wǎng)絡流量低，并有效分配與傳輸最小數(shù)據(jù)包；MQTT協(xié)議可用于移動系統(tǒng)應用，是物聯(lián)網(wǎng)重要的通信協(xié)議之一。

2.2.2 MQTT協(xié)議的數(shù)據(jù)表示

MQTT消息體主要分為三部分：有效載荷，固定報頭和可變報頭。每個命令消息都必須包括固定報頭部分，固定報頭為2個字節(jié)，其格式如表1所示。

表1MQTT固定報頭格式表

其中Message Type為消息類型，大約有14種；Qos level為服務質(zhì)量，有3種等級，分別為Qos0、Qos1、Qos2，等級越高，產(chǎn)生的系統(tǒng)開銷就會越多，因此對通信效率產(chǎn)生的影響也就越大；Remaining Length是指除固定報頭之外的消息長度，包括有效載荷部分和可變頭部，最大可擴展為4 bytes，最大長度可以為256M。

2.2.3 MQTT的控制數(shù)據(jù)包的格式

MQTT協(xié)議簡單，傳輸量小，成本少，可最小化協(xié)議交換，大大降低網(wǎng)絡流量，且固定報頭只有2 bytes。它采用的消息模式為發(fā)布/訂閱及一對多的消息發(fā)布模式，解除了對負載內(nèi)容屏蔽及應用程序耦合的消息傳輸?；赥CP上的應用層協(xié)議MQTT，支持基于TLS／SSL加密通道的傳輸。且MQTT在進行connect時支持認證。此外，MQTT還有3種不同的消息發(fā)布服務質(zhì)量，分別為：

“至多一次”：消息發(fā)布完全依賴底層TCP/IP網(wǎng)絡，會出現(xiàn)消息丟失或重復的現(xiàn)象。

“至少一次”：確保消息抵達，但可能會發(fā)生消息重復的現(xiàn)象。

“只有一次”：確保消息抵達一次，可以用在計費系統(tǒng)中，可能會發(fā)生消息重復或因為丟失數(shù)據(jù)而導致產(chǎn)生不正確結(jié)果的現(xiàn)象。

功耗、流量及傳輸這幾個特性對于移動終端應用是必需要涉及到的地方。對于MQTT協(xié)議而言，在滿足即時消息的基本需求情況下，同時在功耗、流量、傳輸上的問題也得到了解決。首先MQTT的固定長度只有2 bytes，其流量消耗十分小。其次，因為MQTT協(xié)議本身很簡單，再加上頭部簡小，因此解析成本低，功耗也就比較小。另外MQTT非常容易擴展，便于用戶的再次開發(fā)。以上內(nèi)容可以總結(jié)出，MQTT協(xié)議更適用于移動終端，因此本文采取了基于MQTT協(xié)議的解決方案。

圖1MQTT運行框架

3MQTT協(xié)議在智能家居中的應用

本文以智能廚房油煙機控制系統(tǒng)與應用端進行通信為例進行應用分析。

3.1MQTT通信協(xié)議

MQTT的信息發(fā)布是基于話題的。只需要在發(fā)布的時候指定某個話題，并不需要配置相關(guān)的話題。

MQTT協(xié)議定義了發(fā)布服務器和客戶端兩個對象，如圖1所示。作為整個通信系統(tǒng)網(wǎng)絡核心的發(fā)布服務器，可以連接多個客戶端。而框架中信息的產(chǎn)生者和接收者則為客戶端。

（1）服務器接受的信息是客戶端通過subscribe發(fā)布的；

（2）發(fā)布服務器上的某個話題信息是某個客戶端通過publish發(fā)布的；

（3）發(fā)布服務器再將這個信息轉(zhuǎn)發(fā)到對這個話題感興趣的客戶端。

圖2 系統(tǒng)總體通信

3.2 智能廚房油煙機控制系統(tǒng)及應用端與MQTT之間的通信

智能廚房油煙機系統(tǒng)包括了四個部分：基于Open WRT系統(tǒng)的無線路由器，手機控制端，基于樹莓派的網(wǎng)關(guān)和智能油煙機設備。如圖2所示為系統(tǒng)的總體通信圖。

從圖2可知，（1）手機通信模塊提供了與系統(tǒng)服務端交互的功能，采用TLS-PSK安全協(xié)議保證數(shù)據(jù)傳輸?shù)陌踩?。?）MQTT發(fā)布服務端：整個系統(tǒng)的MQTT通信發(fā)布服務端為Mosquitto，Mosquitto管理和轉(zhuǎn)發(fā)所有的MQTT報文，同時負責TLS-PSK框架配置和管理，還提供用基本的訪問權(quán)限控制和用戶認證功能。（3）MQTT客戶端模塊：手機控制端和網(wǎng)關(guān)與Open WRT系統(tǒng)上的信息處理模塊的通信功能是由MQTT客戶端模塊提供的。MQTT客戶端模塊從網(wǎng)關(guān)接收設備狀態(tài)信息，并將信息推送到手機控制終端。另外，手機控制端發(fā)布的控制命令也是由它負責接收的，且在命令被處理完成后再推送給網(wǎng)關(guān)。

4 HTTP和MQTT協(xié)議通信效率對比測試

我們搭建了實驗環(huán)境，對HTTP和MQTT協(xié)議在物聯(lián)網(wǎng)應用中的通信效率進行了對比測試，在智能廚房油煙機中，進行測試時分別采用MQTT協(xié)議的實現(xiàn)與HTTP協(xié)議的實現(xiàn)，抓取數(shù)據(jù)包和分析數(shù)據(jù)包時采用sniffer。MQTT協(xié)議和HTTP協(xié)議的響應時間、吞吐量、消耗流量如表2所示。

MQTT測試環(huán)境：1個智能油煙機客戶端，阿里IOT云服務器（提供MQTT服務），wifi網(wǎng)絡環(huán)境。

HTTP測試環(huán)境：1個智能油煙機客戶端，Ayla IOT云服務器（提供REST服務），wifi網(wǎng)絡環(huán)境。

測試采樣10000條，獲取的通信響應和吞吐量指標響應如表2所示：

表2 測試結(jié)果

10000次采樣測試結(jié)果表明，在平均響應時間上MQTT為4ms，而HTTP為13ms，在吞吐量指標上，單位時間MQTT比HTTP要大，因此，可以得出結(jié)論，同樣的環(huán)境中，MQTT在通信效率上有明顯的優(yōu)勢。

5HTTP和MQTT消息推送方案分析

隨著移動互聯(lián)網(wǎng)和智能終端的普及，在物聯(lián)網(wǎng)應用中，對在手機類移動終端設備上獲取信息提出了更高的要求，主要體現(xiàn)在時限性和移動性兩個方面。時限性要求把信息在規(guī)定的時間內(nèi)發(fā)送到移動終端設備；移動性要求在信息傳輸時保持低功耗，低速率。不管是IOS還是Android，如果采用“拉取”的推送方式，在程序中信息的更新通知需要持續(xù)的檢查，獲取消息時需給服務器發(fā)送拉取請求[1]，更新的信息無法直接通過服務器被主動發(fā)送給用戶，這就增加了交互的次數(shù)和負擔，同時也增加了移動端的資源開銷，而推送方式縮短反應時間，提高效率，第一時間把更新信息推送給移動端[2,3]。目前在Android和IOS平臺上都有自己的推送系統(tǒng)，但在網(wǎng)絡中，操作系統(tǒng)和開發(fā)方面會受到各方面的限制，同一款應用在這個功能上需要采用不同的技術(shù)方案，有很大的局限性。比如Android推送無法直接使用Google的云消息服務器，只能采用國內(nèi)的代理推送服務器，而iphoneAPNS只適用于IOS，不能跨平臺推送，使用MQTT可以避免上述問題，節(jié)省了開發(fā)人員寶貴的開發(fā)時間。

通過對目前Android平臺上最主流的幾種消息推送方案的分析和對比，可以清楚地了解到MATT協(xié)議是最快速，也最省流量的（固定頭長度僅為2個字節(jié)），在IOS和Android平臺上進行推送功能開發(fā)具有一致性，且極易擴展，適合二次開發(fā)。所以本文推薦使用MQTT協(xié)議的方案進行實現(xiàn)。

6 結(jié)語

本文詳細剖析了用于物聯(lián)網(wǎng)通信的HTTP協(xié)議和MQTT協(xié)議，并從功耗和消息推送功能開發(fā)效率兩方面進行了比對，實踐證明基于TCP/IP之上的HTTP協(xié)議不適合資源緊缺型的嵌入式系統(tǒng)或網(wǎng)絡帶寬非常昂貴的環(huán)境，另外HTTP協(xié)議開發(fā)消息推送功能非常繁瑣，而MQTT協(xié)議具有低功耗、開放、簡單、輕量級以及易于實現(xiàn)的特點，在資源受限的環(huán)境中也能得到很好的使用，更適合用于物聯(lián)網(wǎng)領域的通信，在降低功耗和推送功能開發(fā)上具有非常明顯的優(yōu)勢。

[1]劉軍霞，熊選東，付建丹．基于發(fā)布/訂閱的推模式服務調(diào)用[J]．計算機系統(tǒng)應用，2012(12)：196-199．

[2]李小智．基于消息中間件的服務器推送技術(shù)的應用研究[D]．長沙:湖南大學，2010．

[3]梅蕊．跨服務器消息發(fā)布與推送機制的研究[D]．武漢:華中科技大學，2011．

[4]崔健，段振剛，齊志男，等．基于物聯(lián)網(wǎng)云平臺的壁掛爐遠程控制系統(tǒng)[J]．計算機系統(tǒng)應用，2015，24(9)：56-60．

[5]徐汶東．基于無線通信的智能油煙機控制系統(tǒng)設計[J]．ICSSS，2015：421-425．

[6]任亨．基于MQT T協(xié)議的消息推送服務器[J]．計算機系統(tǒng)應用，2014，23(3)：77–82．