邱雨 彭大芹 梁吉申 林峰 項(xiàng)磊

摘 要： 隨著智能家居的迅猛發(fā)展，使其在高、中、低不同市場上都存在著很多競爭。YunOS智能操作系統(tǒng)的推出也加快了智能家居行業(yè)的發(fā)展。Message Queuing Telemetry Transport（MQTT）協(xié)議是為大量計(jì)算能力有限，并且工作在低帶寬、不可靠的網(wǎng)絡(luò)的遠(yuǎn)程傳感器和控制設(shè)備通信而設(shè)計(jì)的協(xié)議。由于開銷小，適用小型傳輸，在智能家居中得到大量運(yùn)用。通過對(duì)MQTT協(xié)議結(jié)構(gòu)以及關(guān)鍵字段的研究，并從實(shí)際環(huán)境中抓取到的智能家居中Packet Capture（PCAP）包進(jìn)行分析，提出一種改進(jìn)型的消息過濾算法將MQTT協(xié)議中訂閱的主題與智能家居品牌聯(lián)系起來，實(shí)現(xiàn)識(shí)別智能家居設(shè)備廠商的目的。

關(guān)鍵詞： 智能家居； MQTT； 消息過濾算法； 小型傳輸； PCAP包； 關(guān)鍵字段

中圖分類號(hào)： TN915?34 文獻(xiàn)標(biāo)識(shí)碼： A 文章編號(hào)： 1004?373X（2018）16?0064?04

Abstract： With the rapid development of the smart home， a lot of competitions exist in its various high， medium and low level markets. On the other hand， the launch of the YunOS smart operating system also speeds up the development of the smart home industry. The message queuing telemetry transport （MQTT） protocol is designed for communications between a great quantity of remote sensors and control equipments which have limited calculation capabilities and work on unreliable low?bandwidth networks. As the MQTT protocol has small overheads and is suitable for small transmissions， it is widely used in the smart home. An improved message filtering algorithm is proposed by studying the structure and key fields of the MQTT protocol， and analyzing the PCAP package grasped in real environments for the smart home， so as to associate the subscription topics of the MQTT protocol with the smart home brands， which can achieve the purpose of identifying the manufacturers of smart home equipments.

Keywords： smart home； MQTT； message filtering algorithm； small transmission； PCAP package； key field

0 引 言

隨著人們生活水平的不斷提高，追求的生活質(zhì)量也越來越高，智能家居在日常生活中體現(xiàn)出重要地位。MQTT是用作制動(dòng)器和傳感器的通信協(xié)議。由于其適用于小型傳輸，所需的帶寬小，并且可以較好地工作在不穩(wěn)定的網(wǎng)絡(luò)中，使得MQTT協(xié)議廣泛應(yīng)用在物聯(lián)網(wǎng)和機(jī)器與機(jī)器（M2M）通信環(huán)境中[1]。本文設(shè)計(jì)一款基于MQTT協(xié)議的智能家居安防設(shè)備的識(shí)別系統(tǒng)，首先研究了MQTT協(xié)議，通過Wireshark抓取了MQTT協(xié)議的PCAP包，分析了MQTT協(xié)議的PCAP包中Publish Message里各字段的作用，采用改進(jìn)的消息過濾算法對(duì)MQTT協(xié)議數(shù)據(jù)流相關(guān)字節(jié)的關(guān)鍵字進(jìn)行匹配，識(shí)別出智能家居生產(chǎn)商。

1 MQTT協(xié)議研究

1.1 協(xié)議簡介

消息隊(duì)列遙測傳輸（Message Queuing Telemetry Transport，MQTT）是一種輕量級(jí)基于代理的發(fā)布/訂閱的消息傳輸協(xié)議。協(xié)議簡單，最小的固定頭部只需要2 B，其采用TCP/IP進(jìn)行基本的網(wǎng)絡(luò)連接，有三種服務(wù)質(zhì)量（QoS）應(yīng)對(duì)消息發(fā)送的級(jí)別。

1.2 MQTT消息格式

對(duì)于每一個(gè)MQTT協(xié)議命令消息的頭部都包含了一個(gè)固定報(bào)頭，有些消息還需要一個(gè)可變報(bào)頭和一個(gè)有效載荷。固定報(bào)頭和可變報(bào)頭的格式如下。

1.2.1 固定報(bào)頭

固定報(bào)頭的第一個(gè)字節(jié)包含了類型和標(biāo)簽（DUP， QoS level，RETAIN），第二個(gè)字節(jié)（至少含有一個(gè)字節(jié)）包含接下來的變長頭部和消息體的總大小。固定報(bào)頭見圖1。

圖1中：Message Type是4位無符號(hào)的數(shù)值；DUP flag設(shè)置為1表示客戶端或者服務(wù)器重新發(fā)送一個(gè)PUBLISH，PUBREL，SUBSCRIBE或者UNSUBSCRIBE消息。如果DUP設(shè)置為1，那么可變報(bào)頭將包含Message ID字段：QoS表示發(fā)送PUBLISH消息的級(jí)別。QoS為0時(shí)，PUBLISH消息至多發(fā)送1次。

第二個(gè)字節(jié)Remaining Length保存后面的可變頭部和消息體的總大小。這個(gè)字節(jié)可以進(jìn)行擴(kuò)展，如果可變頭部與消息體的總大小在0～127之間，那么直接保存，不需要擴(kuò)展字節(jié)。但可變頭部與消息體的總大小在128～16 383，則需要擴(kuò)展一個(gè)字節(jié)，使用第二個(gè)字節(jié)保存其長度。Remaining Length最多可以為4個(gè)字節(jié)。

1.2.2 可變報(bào)頭

圖2是MQTT協(xié)議的可變報(bào)頭。在可變頭部中，第一部分是協(xié)議的名字，MSB與LSB表示在Protocol Name中后面的字節(jié)長度，這里是6個(gè)字節(jié)，即“MQIsdp”。Topic Name是訂閱消息標(biāo)識(shí)，可以用來區(qū)分消息的推送類別，訂閱者使用這個(gè)關(guān)鍵字來識(shí)別想要接收的消息。

2 對(duì)智能家居中的MQTT協(xié)議的分析

根據(jù)Wireshark，在無線局域網(wǎng)的情況下，在Linux系統(tǒng)中用airodump?ng抓取智能家居的主機(jī)與外界通信時(shí)IEEE 802.11的PCAP包，并篩選出MQTT協(xié)議的數(shù)據(jù)包。IEEE 802.11數(shù)據(jù)包的格式如圖3所示，其中PCAP包會(huì)被封裝一層IEEE制定的IEEE 802.11標(biāo)準(zhǔn)的一些標(biāo)簽。

然后針對(duì)MQTT這一層進(jìn)行解讀，由于識(shí)別智能家居的MQTT協(xié)議，一般只涉及PUBLISH消息，所以本文只針對(duì)這個(gè)消息進(jìn)行解讀。PUBLISH消息見圖4。

在Publish Message中，第一個(gè)字節(jié)是0x30，轉(zhuǎn)化成二進(jìn)制是00110000，代表這個(gè)消息是PUBLISH消息，QoS設(shè)置為00，即這個(gè)消息至多被發(fā)送一次。Msg Len代表可變頭部與消息體的總大小，此處大小是302，因?yàn)榻橛?28～16 363之間，故需要擴(kuò)展成兩個(gè)字節(jié)來存放，即0x30后面的兩個(gè)字節(jié)：0XAE與0x02。計(jì)算方式為：302=46+2×128，46轉(zhuǎn)為二進(jìn)制數(shù)為00101110，將最高位置1，表示后面還有存放的字節(jié)，置1后成為10101110，即0XAE，后一個(gè)字節(jié)存放0x02。接下來就是可變報(bào)頭的Topic Name關(guān)鍵字，定義有效載荷數(shù)據(jù)發(fā)送的信息頻道。訂閱者根據(jù)Topic Name來識(shí)別出他們想要接收的消息。此處存放的Topic Name轉(zhuǎn)化為ASCII碼為dev2app/G86PxmzRfHq98dbJotEoms。后面存放的字節(jié)就是PUBLISH消息的數(shù)據(jù)段。

3 識(shí)別系統(tǒng)中消息過濾算法

3.1 過濾算法

在關(guān)鍵字過濾中，常用的算法有BF（Brute Force）、KMP（Knuth Morris Pratt）等[2]。Brute?Force（BF）算法是一種字符串模式匹配算法。假設(shè)目標(biāo)串長度為n，模式串長度為m，首先將目標(biāo)串S的第一個(gè)字符與模式串T的第一個(gè)字符進(jìn)行匹配，若相等則將S的第二個(gè)字符與T的第二個(gè)字符進(jìn)行匹配，以此類推；若比較過程中相應(yīng)字符串不相等，則將目標(biāo)串S的第二個(gè)字符與模式串T的第一個(gè)字符進(jìn)行匹配，依次比較下去。BF算法是蠻力算法，運(yùn)行效率不高，最壞情況下要進(jìn)行m×（n-m+1）次比較，時(shí)間復(fù)雜度[3]為O（nm）。

3.2 改進(jìn)的BF算法

由于此識(shí)別系統(tǒng)可能應(yīng)用于嵌入式設(shè)備中，算法的運(yùn)行效率要求較高，所以對(duì)MQTT協(xié)議的Topic位先進(jìn)行特殊字符查找。設(shè)模式串特殊符號(hào)前有s位，如果目標(biāo)串也含有特殊字符，則從特殊字符開始當(dāng)作分界線，往前匹配s位同時(shí)往后匹配模式串其余位。首先需要對(duì)目標(biāo)串遍歷，找出特殊字符位置，時(shí)間復(fù)雜度為O（n）。接著匹配模式串其余位，若不匹配，則跳到下一個(gè)特殊字符處，重復(fù)上面的工作，這樣匹配只需n的常數(shù)倍，即時(shí)間復(fù)雜度為O（n）。若遍歷后沒有特殊字符，則進(jìn)行原始的BF模式匹配算法，最壞的情況下所需的時(shí)間復(fù)雜度仍然是O（nm）。

假設(shè)目標(biāo)串S：abc$cel/Gespdev/G86Pxmz。模式串T：dev/G86P。

在識(shí)別系統(tǒng)的BF模式匹配算法模塊中，首先遍歷目標(biāo)串S，找出特殊字符“$”與“/”。匹配過程中的i表示匹配的次數(shù)，j表示目標(biāo)串的位置。匹配結(jié)果見圖5～圖7。

1） 第一次匹配：此時(shí)特殊字符處不相等，匹配失敗。

2） 第二次匹配：特殊字符匹配成功，往前匹配時(shí)失敗。

3） 第三次匹配：當(dāng)特殊字符匹配成功后，一分為二，同時(shí)向前向后開始匹配，目標(biāo)串與模式串相同，匹配成功。

4 識(shí)別智能家居品牌的實(shí)現(xiàn)

4.1 識(shí)別系統(tǒng)總體框架設(shè)計(jì)

基于MQTT協(xié)議的智能家居系統(tǒng)網(wǎng)絡(luò)由兩部分組成：內(nèi)部家居設(shè)備網(wǎng)絡(luò)以及外部互聯(lián)網(wǎng)。在MQTT協(xié)議的智能家居安防設(shè)備中，手機(jī)發(fā)送控制命令到主機(jī)上，需要經(jīng)過消息過濾層，即Broker。發(fā)送到Broker的控制命令再轉(zhuǎn)交給訂閱了此主題（Topic字段）的智能家居安防主機(jī)，主機(jī)根據(jù)控制命令的類別進(jìn)行相應(yīng)的反應(yīng)，如所有安防設(shè)備撤防、針對(duì)某個(gè)防區(qū)（如臥室）撤防等[4]。

由于智能主機(jī)一般會(huì)接入家庭的無線路由器，主機(jī)通過WiFi與外界通信，所以識(shí)別系統(tǒng)時(shí)將抓取主機(jī)與Broker通信的數(shù)據(jù)流，然后根據(jù)協(xié)議字段篩選出MQTT協(xié)議的數(shù)據(jù)包，讀出安防設(shè)備廠商在MQTT協(xié)議中設(shè)置的Topic位，采用改進(jìn)型的BF模式匹配算法，識(shí)別出智能家居品牌。系統(tǒng)總體框架設(shè)計(jì)圖如圖8所示。

4.2 識(shí)別系統(tǒng)的實(shí)現(xiàn)

系統(tǒng)通過C語言實(shí)現(xiàn)。識(shí)別系統(tǒng)代碼實(shí)現(xiàn)的框圖如圖9所示。

首先定義4個(gè)結(jié)構(gòu)體，結(jié)構(gòu)體ip_address用來存放4個(gè)字節(jié)的IP地址；結(jié)構(gòu)體ip_header存放網(wǎng)絡(luò)層封裝的IP報(bào)頭的各個(gè)字段，報(bào)頭中第一個(gè)字節(jié)的后4位用來計(jì)算報(bào)頭總長度，即結(jié)構(gòu)體ip_header中的成員ver_ih1，IP報(bào)頭一般為20 B；結(jié)構(gòu)體tcp_header存放傳輸層封住的TCP報(bào)頭的關(guān)鍵字段，若不加擴(kuò)展TCP報(bào)頭一般為20 B。定義結(jié)構(gòu)體方便指針的指向，只要明確各個(gè)結(jié)構(gòu)體的首地址，就容易得到傳輸在網(wǎng)絡(luò)中的數(shù)據(jù)包中各個(gè)位置的信息。

獲取網(wǎng)卡接口模塊包括得到設(shè)備列表、打印列表與輸入選擇，其中得到設(shè)備列表函數(shù)為pcap_findalldevs。在Windows系統(tǒng)下獲取網(wǎng)絡(luò)接口模塊的顯示效果如圖10所示。

在抓取數(shù)據(jù)包模塊中，pcap_open函數(shù)打開適配器，將抓取模式設(shè)置為混雜模式，即抓取經(jīng)過本機(jī)的所有數(shù)據(jù)流；接著用pcap_dataklink函數(shù)檢查數(shù)據(jù)鏈路層，將數(shù)據(jù)鏈路層的標(biāo)準(zhǔn)設(shè)置為IEEE 802.11；pcap_loop函數(shù)開始捕捉數(shù)據(jù)包。

過濾器模塊就是在抓取經(jīng)過本機(jī)的所有數(shù)據(jù)流時(shí)過濾出自己想要的數(shù)據(jù)流，如UDP協(xié)議的數(shù)據(jù)流、TCP協(xié)議的數(shù)據(jù)流等。由于MQTT協(xié)議是基于TCP的，所以過濾出TCP協(xié)議的數(shù)據(jù)流。首先用pcap_compile函數(shù)編譯過濾器，然后用pcap_setfilter設(shè)置過濾器，這時(shí)將過濾出TCP協(xié)議的數(shù)據(jù)流，最后根據(jù)關(guān)鍵字判斷出MQTT協(xié)議的數(shù)據(jù)流。

在識(shí)別系統(tǒng)中設(shè)置回調(diào)函數(shù)，回調(diào)函數(shù)使用了前面定義結(jié)構(gòu)體的各個(gè)成員。捕捉數(shù)據(jù)包時(shí)調(diào)用回調(diào)函數(shù)，每抓取一個(gè)數(shù)據(jù)流，就進(jìn)行過濾，讀取這個(gè)數(shù)據(jù)流的各個(gè)字節(jié)。

識(shí)別系統(tǒng)的效果圖如圖11所示。當(dāng)協(xié)議為TCP協(xié)議時(shí)，不進(jìn)行進(jìn)一步的識(shí)別。只有當(dāng)協(xié)議為MQTT協(xié)議時(shí)，才將Topic位用BF算法相匹配，識(shí)別出智能家居安防設(shè)備廠商。

5 結(jié) 語

本文研究MQTT協(xié)議的結(jié)構(gòu)，針對(duì)PCAP數(shù)據(jù)包對(duì)使用MQTT協(xié)議的智能家居設(shè)備進(jìn)行了解讀與分析，并提出改進(jìn)型的BF模式匹配算法，設(shè)計(jì)開發(fā)了MQTT協(xié)議的智能家居安防設(shè)備的識(shí)別系統(tǒng)，成功實(shí)現(xiàn)了智能家居識(shí)別。目前大多數(shù)研究是對(duì)MQTT協(xié)議的即時(shí)通信系統(tǒng)的實(shí)現(xiàn)，在識(shí)別系統(tǒng)這一塊較少，未來將引入數(shù)據(jù)庫，把市面上智能家居安防設(shè)備廠商存儲(chǔ)在數(shù)據(jù)庫中，豐富并完善識(shí)別系統(tǒng)，實(shí)現(xiàn)更多功能。

參考文獻(xiàn)

[1] LUZURIAGA J E， CANO J C， CALAFATE C， et al. Handling mobility in IoT applications using the MQTT protocol [C]// Proceedings of International Conference on Internet Technologies & Applications. Wrexham： IEEE， 2015： 245?250.

[2] 蔣鵬，袁嵩.基于MQTT協(xié)議的綜合消息推送[J].現(xiàn)代計(jì)算機(jī)，2014（11）：11?15.

JIANG Peng， YUAN Song. Integrated message push based on MQTT protocol [J]. Modern computer， 2014（11）： 11?15.

[3] YASSEIN M B， SHATNAWI M， ALJWARNEH S， et al. Internet of Things： survey and open issues of MQTT protocol [C]// Proceedings of International Conference on Engineering & MIS. Monastir： IEEE， 2017： 1?5.

[4] LEE S， KIM H， HONG D K， et al. Correlation analysis of MQTT loss and delay according to QoS level [C]// Proceedings of International Conference on Information Networking. Bangkok： IEEE， 2013： 714?717.

[5] IBM， Eurotech. MQTT V3.1 protocol specification [S/OL]. [2011?02?28]. https： //wenku.baidu.com/view/dedf6ed9d15abe23482f4

d65.html.

[6] NAIK N. Choice of effective messaging protocols for IoT systems： MQTT， CoAP， AMQP and HTTP [C]// Proceedings of IEEE International Systems Engineering Symposium. Vienna： IEEE， 2017： 1?7.

[7] HUNKELER U， TRUONG H L， STANFORD?CLARK A. MQTT?S： A publish/subscribe protocol for wireless sensor networks [C]// Proceedings of 3rd International Conference on Communication Systems Software and Middleware and Workshops. Bangalore： IEEE， 2008： 791?798.

[8] 許金喜，張新有.Android平臺(tái)基于MQTT協(xié)議的推送機(jī)制[J].計(jì)算機(jī)系統(tǒng)應(yīng)用，2015，24（1）：185?190.

XU Jinxi， ZHANG Xinyou. Push mechanism on Android platform based on MQTT protocol [J]. Computer systems & applications， 2015， 24（1）： 185?190.

[9] 明廷堂.BF與KMP模式匹配算法的實(shí)現(xiàn)與應(yīng)用[J].電腦編程技巧與維護(hù)，2013（23）：24?28.

MING Tingtang. Implementation and application of BF and KMP pattern matching algorithm [J]. Computer programming skills & maintenance， 2013（23）： 24?28.

[10] 顧亞文.基于MQTT協(xié)議的通用智能家居系統(tǒng)設(shè)計(jì)與實(shí)現(xiàn)[D].西安：西安電子科技大學(xué)，2014.

GU Yawen. Design and implementation of general smart home system based on MQTT protocol [D]. Xian： Xidian University， 2014.