基于消息過濾算法實現MQTT協議智能家居的識別

邱雨 彭大芹 梁吉申 林峰 項磊

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

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

中圖分類號： TN915?34 文獻標識碼： A 文章編號： 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 引 言

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

1 MQTT協議研究

1.1 協議簡介

消息隊列遙測傳輸（Message Queuing Telemetry Transport，MQTT）是一種輕量級基于代理的發布/訂閱的消息傳輸協議。協議簡單，最小的固定頭部只需要2 B，其采用TCP/IP進行基本的網絡連接，有三種服務質量（QoS）應對消息發送的級別。

1.2 MQTT消息格式

對于每一個MQTT協議命令消息的頭部都包含了一個固定報頭，有些消息還需要一個可變報頭和一個有效載荷。固定報頭和可變報頭的格式如下。

1.2.1 固定報頭

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

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

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

1.2.2 可變報頭

圖2是MQTT協議的可變報頭。在可變頭部中，第一部分是協議的名字，MSB與LSB表示在Protocol Name中后面的字節長度，這里是6個字節，即“MQIsdp”。Topic Name是訂閱消息標識，可以用來區分消息的推送類別，訂閱者使用這個關鍵字來識別想要接收的消息。

2 對智能家居中的MQTT協議的分析

根據Wireshark，在無線局域網的情況下，在Linux系統中用airodump?ng抓取智能家居的主機與外界通信時IEEE 802.11的PCAP包，并篩選出MQTT協議的數據包。IEEE 802.11數據包的格式如圖3所示，其中PCAP包會被封裝一層IEEE制定的IEEE 802.11標準的一些標簽。

然后針對MQTT這一層進行解讀，由于識別智能家居的MQTT協議，一般只涉及PUBLISH消息，所以本文只針對這個消息進行解讀。PUBLISH消息見圖4。

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

3 識別系統中消息過濾算法

3.1 過濾算法

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

3.2 改進的BF算法

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

假設目標串S：abc$cel/Gespdev/G86Pxmz。模式串T：dev/G86P。

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

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

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

3） 第三次匹配：當特殊字符匹配成功后，一分為二，同時向前向后開始匹配，目標串與模式串相同，匹配成功。

4 識別智能家居品牌的實現

4.1 識別系統總體框架設計

基于MQTT協議的智能家居系統網絡由兩部分組成：內部家居設備網絡以及外部互聯網。在MQTT協議的智能家居安防設備中，手機發送控制命令到主機上，需要經過消息過濾層，即Broker。發送到Broker的控制命令再轉交給訂閱了此主題（Topic字段）的智能家居安防主機，主機根據控制命令的類別進行相應的反應，如所有安防設備撤防、針對某個防區（如臥室）撤防等[4]。

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

4.2 識別系統的實現

系統通過C語言實現。識別系統代碼實現的框圖如圖9所示。

首先定義4個結構體，結構體ip_address用來存放4個字節的IP地址；結構體ip_header存放網絡層封裝的IP報頭的各個字段，報頭中第一個字節的后4位用來計算報頭總長度，即結構體ip_header中的成員ver_ih1，IP報頭一般為20 B；結構體tcp_header存放傳輸層封住的TCP報頭的關鍵字段，若不加擴展TCP報頭一般為20 B。定義結構體方便指針的指向，只要明確各個結構體的首地址，就容易得到傳輸在網絡中的數據包中各個位置的信息。

獲取網卡接口模塊包括得到設備列表、打印列表與輸入選擇，其中得到設備列表函數為pcap_findalldevs。在Windows系統下獲取網絡接口模塊的顯示效果如圖10所示。

在抓取數據包模塊中，pcap_open函數打開適配器，將抓取模式設置為混雜模式，即抓取經過本機的所有數據流；接著用pcap_dataklink函數檢查數據鏈路層，將數據鏈路層的標準設置為IEEE 802.11；pcap_loop函數開始捕捉數據包。

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

在識別系統中設置回調函數，回調函數使用了前面定義結構體的各個成員。捕捉數據包時調用回調函數，每抓取一個數據流，就進行過濾，讀取這個數據流的各個字節。

識別系統的效果圖如圖11所示。當協議為TCP協議時，不進行進一步的識別。只有當協議為MQTT協議時，才將Topic位用BF算法相匹配，識別出智能家居安防設備廠商。

5 結 語

本文研究MQTT協議的結構，針對PCAP數據包對使用MQTT協議的智能家居設備進行了解讀與分析，并提出改進型的BF模式匹配算法，設計開發了MQTT協議的智能家居安防設備的識別系統，成功實現了智能家居識別。目前大多數研究是對MQTT協議的即時通信系統的實現，在識別系統這一塊較少，未來將引入數據庫，把市面上智能家居安防設備廠商存儲在數據庫中，豐富并完善識別系統，實現更多功能。

參考文獻

[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協議的綜合消息推送[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平臺基于MQTT協議的推送機制[J].計算機系統應用，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模式匹配算法的實現與應用[J].電腦編程技巧與維護，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協議的通用智能家居系統設計與實現[D].西安：西安電子科技大學，2014.

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