基于MQTT協議的輕量化文本信息分發技術研究

熊風光,陳 霖,韓慧妍,張 元,龐 敏,焦世超

(1.中北大學 計算機科學與技術,山西 太原 030051;2.機器視覺與虛擬現實山西省重點實驗室,山西 太原 030051 3.山西省視覺信息處理及智能機器人工程研究中心,山西 太原 030051)

0 引 言

隨著移動互聯網的發展和普及,越來越多的人使用手機、平板電腦等移動設備進行信息獲取和交流[1]。借助傳統的通信網絡在一些偏遠地區、災害現場、海洋、航空等特殊場景下獲取信息可能會受到限制。第一,傳統的通信網絡受限于地理位置和網絡覆蓋范圍,導致其信號弱或沒有信號;第二,傳統的通信網絡在自然災害、戰爭等突發事件中容易受到破壞;第三,傳統的通信網絡需要鋪設大量的基礎設施才能實現信息傳輸。針對上述問題,衛星通信網絡[2]的價值就體現了出來,衛星通信網絡可以覆蓋地面基站網絡無法覆蓋的地方,同時,衛星通信是天上的鏈路,不會受到地面災害環境因素的影響,并且不依賴于基礎設施建設。在復雜的環境場景下,使用衛星通信網絡進行通信設備之間的通信是一個不錯的選擇。衛星通信網絡雖有覆蓋范圍大、依賴性小等優點[3],但其存在著一些缺點:其一,衛星通信網絡的網絡時延大、丟包率高,導致數據在傳輸過程中會出現不穩定情況而丟失;其二,衛星通信網絡的信道窄,在傳輸數據信息量比較大時會增加傳輸時間、降低傳輸效率。以上問題導致衛星通信網絡無法完全在通信設備中展開使用。現有文本信息分發技術是基于JSON數據的傳統分發技術以及數據分塊和重組分發技術。但是已有技術在衛星通信網絡環境下分發有以下不足之處:第一,由于衛星的頻譜資源有限,分發大量的文本信息可能會導致帶寬瓶頸,限制數據傳輸的速度和容量;第二,由于信號在地面和衛星之間的傳輸,有可能被惡意攻擊者截獲、竊聽或篡改;第三,數據分塊和重組分發技術是將文本信息分成較小的數據塊,通過衛星鏈路逐個傳輸,然后在接收端重新組裝成完整的文本信息。如果某個數據塊丟失或出錯,整個文本信息的完整性可能會受到影響。針對上述問題,該文研究了基于MQTT(Message Queuing Telemetry Transport)協議的輕量化文本信息分發技術。設計了數據校驗加密算法、文本信息輕量化處理方法和離線消息存儲機制。

1 相關工作

1.1 MQTT協議

MQTT[4]是采用發布/訂閱模式、基于TCP/IP協議的通信協議,具有輕量級、簡單、開放等特點。它能夠在低帶寬或者不可靠的網絡上傳輸數據,功耗非常低,以輕量級、簡單、易于部署等優點使MQTT成為約束環境下的理想通信協議[5]。

1.2 GZIP壓縮算法

GZIP算法是一種基于DEFLATE算法[6]的數據壓縮算法,這是HTTP標準中使用的壓縮方案之一,通過減少網絡傳輸的字節大小來最小化延遲。它采用了霍夫曼編碼和LZ77算法對數據進行壓縮,可以獲得更高的壓縮比和更快的解壓速度[7]。GZIP廣泛應用于各種領域,包括文件壓縮、網頁壓縮、日志文件壓縮等。它在Web服務器中常用于對傳輸的內容進行壓縮,以減少數據傳輸的帶寬消耗和提高用戶訪問速度。

1.3 AES加密算法

AES(Advanced Encryption Standard,高級加密標準)是一種安全可靠的對稱加密算法,其密鑰長度可達到128位、192位或者256位,具有安全性高、速度快、可靠性高等特點[8]。AES被認為是一種安全可靠的加密算法,已經通過了多個密碼學標準的審查和認可,應用于保護敏感數據的安全性,包括網絡通信、數據存儲和加密文件等領域。

2 文中方法

2.1 總體架構

針對文本信息在衛星通信網絡下的分發過程存在安全性弱、效率低下、可靠性不高的問題,該文開展輕量化文本信息分發技術研究。主要工作如下:

(1)基于MQTT協議進行設備通信準備工作,建立可靠的數據鏈路連接;

(2)針對文本信息安全性弱的問題,將AES加密算法與CRC校驗工具結合使用,對加密的文本信息在分發至接收端進行解密后執行CRC校驗,檢驗數據是否被篡改;

(3)針對文本信息分發效率低下的問題,對分發的文本信息進行輕量化操作,即利用GZIP壓縮算法對待分發的信息進行壓縮;

(4)針對文本信息分發過程中可靠性不高的問題,設計離線消息存儲機制,確保文本信息可以被接收端接收。

輕量化文本信息分發流程如圖1所示。文本信息由服務端分系統進行分發,應用端分系統接收并展示。首先進行創建主題、創建發布訂閱機制、設計設備心跳和設備連接等過程,連通服務端分系統與應用端分系統的通信狀態。然后服務端準備向應用端發送文本信息,服務端生成文本信息校驗碼、文本信息進行加密處理、文本信息進行輕量化處理、文本信息序列化。經過處理后的文本信息準備分發,分發之前判斷應用端用戶是否在線,若不在線,則將文本信息進行離線存儲,待用戶上線之后發送;若在線,則將文本信息分發至應用端。應用端在接收文本信息之后,進行文本信息反序列化、數據解密、數據完整性校驗等一系列操作,數據完整性校驗用于判斷數據在分發的過程中是否被惡意篡改,若文本信息被篡改,則通知服務端文本信息被篡改并且在應用端不進行展示;若文本信息沒有被篡改,則提取文本信息,進行文本信息展示。

圖1 輕量化文本信息分發流程

2.2 設備通信準備工作

2.2.1 主題設計

主題[9]本質上是一個使用UTF-8編碼的字符串,用來對發布的消息進行區分,在Publish報文中,隨著消息載體一起發布。主題可以是由單一級別的主題組成,例如user1,也可以是由多個級別的主題組成,例如qingliang/clientUser/user1,主題的各個級別之間使用“/”進行分割。主題是區分大小寫的,user和User是兩個不同的主題。

客戶端在訂閱主題時,可以選擇訂閱特定的主題消息,也可以通過使用通配符訂閱若干個主題消息。通配符只能在訂閱主題時使用,而不能在發布消息時使用。主題通配符有兩種存在形式:單級通配符、多級通配符。單級通配符使用“+”表示,例如qingliang/+/user,單級通配符可以代替一個主題層級。多級通配符使用“#”表示,例如qingliang/#/user,多級通配符可以代替任意數量的主題層級。

在輕量化文本信息分發技術的研究中,設計了兩種主題,分別如下:

(1)登錄主題:用于應用端登錄的主題,服務端訂閱;

(2)信息分發主題:用于服務端向應用端下發文本信息的主題,客戶端訂閱。

2.2.2 發布訂閱機制

發布訂閱(Publish/Subscribe)機制[10]是一種消息轉發機制,在這種消息轉發機制下,消息分發的完整流程分為三步:訂閱-發布-轉發。同一客戶端既可以是消息的發布者,也可以是消息的訂閱者。訂閱-發布流程如圖2所示,客戶端3訂閱主題qingliang/user/user2、客戶端4訂閱主題qingliang/user/user1,客戶端1向主題qingliang/user/user1發布消息“10”、客戶端2向主題qingliang/user/user2發布消息“20”。由于客戶端3訂閱主題與客戶端2發布消息的主題匹配成功,客戶端3會接收到由客戶端2發布并且由服務器轉發的消息“20”。同理,客戶端4會接收到由客戶端1發布并且經過服務器轉發的消息“10”。

圖2 發布訂閱機制

2.2.3 設備連接設計

客戶端設備與服務端建立可靠的連接是后續一切服務的基礎,MQTT客戶端之間想要實現發布訂閱機制、通信等服務,必須要通過MQTT服務端,因此客戶端與服務端建立連接是一項很重要的工作。

MQTT客戶端與服務端在建立連接的過程中,客戶端先向服務端發送CONNECT報文,服務端收到報文后,向客戶端發送CONNACK報文。CONNECT報文包含了clientId,cleanSession,keepAlive,username,password等數據信息,其中clientId是客戶端的唯一標識;cleanSession有true和false兩個值,如果設置為true,則表示當服務端向客戶端發送消息時,無論客戶端是否收到,都不會再次發送,這種情況適用于發送不重要的報文,如果設置為false,則表示服務端會接收客戶端的確認消息,服務端會保存信息繼續發送,直至接收到客戶端的確認收到消息,這種情況適合重要的報文,并且在此情況下Qos的設置要大于0;keepAlive是用于服務端實時監測客戶端的連接情況。CONNACK報文包含了returnCode,sessionPresent等數據信息,其中returnCode是連接的狀態碼,用來表示客戶端的連接情況,返回“0”表示客戶端與服務端連接成功,返回非“0”值表示連接失敗;sessionPresent表示當前clientId所對應的設備是否有未確認收到的消息,如果返回值為true,說明此時有尚未確認收到的消息,不需要重新訂閱主題,連接之后會收到保存在服務端的消息;如果返回值為false,說明原本的訂閱關系已消失,需要重新訂閱主題。

2.2.4 設備心跳設計

設備心跳設計[11]是實現客戶端與服務端建立可靠連接的關鍵。為了確認客戶端與服務端的連接狀態,除了客戶端正常向服務端發送消息之外,在沒有發送消息的空閑時間,客戶端會在心跳時間主動向服務端發送消息,這條消息稱為PINGREQ(心跳請求),如果服務端收到了客戶端的消息,則認為客戶端處于在線狀態,同時會回復一條消息,這條消息稱為PINGRESP(心跳響應),反之則處于離線狀態。

由于心跳時間是在客戶端設定的,為了讓服務端知道客戶端的心跳時間,客戶端需要將該時間通知給服務端。在2.2.3設備連接時的CONNECT報文中有一個字段是keepAlive,這個字段就是用于設置心跳時間并通知服務端。

心跳機制是否會觸發是根據客戶端發送消息的頻率來決定的。第一,客戶端在心跳時間之內向服務端發送消息,此時服務端不需要心跳請求也可以知道客戶端是在線的,這個時候心跳機制沒有觸發;第二,客戶端在心跳時間之內沒有向服務端發送消息,此時客戶端需要發送心跳請求給服務端,這個時候觸發了心跳機制。服務端在1.5倍的心跳時間之內沒有收到客戶端發送的心跳請求或者普通消息,如公式1,則認為客戶端與服務端已經斷開了連接。

stime>1.5×ctime

(1)

其中,ctime是客戶端心跳時間,stime是服務端監測時間。

2.3 輕量化文本信息分發技術研究

2.3.1 數據校驗加密算法

數據校驗和加密算法是保護數據安全的重要措施。數據校驗算法[12]可以檢測到數據在傳輸過程中是否被篡改,確保數據的完整性;數據加密算法[13]可以將數據轉換為一種難以理解的格式,防止數據被篡改,確保數據的機密性。數據在發送方要先校驗后加密,接收方先解密后校驗。該文將循環冗余校驗算法(CRC)與AES加密算法相結合以確保數據在傳輸過程中的完整性和機密性。

數據校驗算法是用于檢測數據在傳輸或存儲過程中是否被篡改或損壞的技術。常見的數據校驗算法包括奇偶校驗、循環冗余校驗、校驗和、哈希函數等。CRC可以高效地檢測數據是否被篡改,不會占用過多的系統資源或帶來太大的通信延遲;CRC與其他數據校驗算法相比具有更強的檢測能力。因此,該文的數據校驗算法采用循環冗余校驗算法(CRC)。

數據加密是保護數據安全的重要措施[14]。數據加密算法可以將數據轉換為一種難以理解的格式,防止數據被篡改,確保數據的機密性。數據加密算法分為以下三類:對稱加密算法、非對稱加密算法、散列函數算法。由于對稱加密具有加密和解密速度快、加密效率高等優點,該文選擇對稱加密算法中的AES進行加密。加密的具體流程如圖3所示。

圖3 數據加密流程

(1)字節代換。

每一輪的第一個階段都是從字節代換開始,這一步依賴于非線性S-box,將原始矩陣通過S-box進行變換。將4×4矩陣的每一個字節都進行字節代換,高4位作為x值,低4位作為y值,通過x,y值在S-box中找到對應的目標值進行替換,得到一個新的矩陣。

(2)行位移。

字節代換之后執行狀態的下一步是行位移,這一步是在每行中循環地將狀態字節向左移動。第一行的字節保持不變,第二行的字節向左循環移動一個字節,第三行的字節向左循環移動兩個字節,第四行的字節向左循環移動三個字節。新狀態矩陣沒有改變大小,仍然是原來的16字節,但是改變了狀態字節的位置。

(3)列混合。

行位移的下一步是列混合,這一步只在前9輪中使用,第10輪是沒有這一步的。這一步是將輸入的矩陣左乘一個給定的4×4矩陣,得到一個新的矩陣,見公式2。由于列混合的運算是在GF(28)域上的運算,所以運算方式和平時的十進制運算方法是有所區別的。公式3計算第一行數據、公式4計算第二行數據、公式5計算第三行數據、公式6計算第四行數據。

(2)

K0,j=(2*S0,j)⊕(3*S1,j)⊕S2,j⊕S3,j

(3)

K1,j=S0,j⊕(2*S1,j)⊕(3*S2,j)⊕S3,j

(4)

K2,j=S0,j⊕S1,j⊕(2*S2,j)⊕(3*S3,j)

(5)

K3,j=(3*S0,j)⊕S1,j⊕S2,j⊕(2*S3,j)

(6)

給定的矩陣中只有01,02,03三種數據,接下來對這三種數據的運算進行描述。所有的運算都要轉成二進制運算,01乘以任何數都是本身;02的二進制是00000010,02與其他數據相乘的規則見公式7;03的二進制是00000011,03與其他數據相乘的規則見公式8。

(00000010)*(a7a6a5a4a3a2a1a0)=

(7)

(00000011)*(a7a6a5a4a3a2a1a0)=

[(00000010)⊕(00000001)]*

(a7a6a5a4a3a2a1a0)=

[(00000010)*(a7a6a5a4a3a2a1a0)]⊕

(a7a6a5a4a3a2a1a0)

(8)

(4)輪密鑰加。

列混合的下一步是輪密鑰加,這一步是AES算法中最關鍵的階段,能夠在加密數據期間提供更多的安全性,創建密鑰與密文之間的關系。輪密鑰加的第一次運算(即初始變換)是將明文矩陣與原始密鑰矩陣進行異或運算,剩下10次的輪密鑰加運算是將經過密鑰擴展產生的新密鑰與上一步產生的新矩陣進行異或運算。

(5)密鑰擴展。

AES算法是基于AES密鑰擴展進行加密和解密的算法,密鑰擴展是AES算法中重要的步驟。每一輪都會產生一把新密鑰,新密鑰用于每一輪的加密。密鑰的大小是16字節(K0～K15),前四個字節K0～K3表示為W0,接下來的四個字節K4～K7表示為W1,以此類推。

每一輪密鑰擴展運算規則如下:如果i不是4的倍數,那么第i列由式9確定;

W[i]=W[i-4]⊕W[i-1]

(9)

如果i是4的倍數,那么第i列由式10確定。

W[i]=W[i-1]⊕T(W[i-1])

(10)

公式10的函數T由3部分組成:字循環、字節代換和輪常量異或。字循環是將1個字中的4個字節循環左移1個字節;輪常量異或是將經過前兩步得到的結果同輪常量Rcon[j]進行異或,其中j表示輪數。

上述加密過程是針對16字節的數據,但實際上文件大小不會是16字節。對于一個文件的加密解密過程如圖4所示,將一個文件分成n個16字節長度的明文數據,定義一個16字節的初始向量counter1,對counter1進行AES加密,得到的數據和明文1進行異或得到密文1;counter1加1得到counter2,對counter2進行AES加密,得到數據和明文2進行異或得到密文2,以此類推,一直計算到最后一個密文n,將n個密文拼接在一起就是文件對應的密文。解密過程與加密過程類似,counter1進行AES加密后得到的數據與密文1進行異或得到明文1,counter2進行AES加密后得到的數據與密文2進行異或得到明文2,以此類推,一直計算到最后一個明文n,將n個明文拼接在一起就是解密后的文件數據。在這種加密解密過程中,雙方互相需要知道counter1的值和AES的密鑰。

圖4 文件加密解密過程

2.3.2 文本信息輕量化處理

為了減輕網絡帶寬壓力、提高傳輸效率,在文本信息分發之前需要進行輕量化處理。提出使用GZIP算法[15]結合文本信息的特點進行壓縮。

輕量化文本信息分發技術結合GZIP算法進行文本信息壓縮的流程如圖5所示。首先,提取準備分發的文本消息,將提取到的消息使用GZIP壓縮算法進行壓縮,得到更小的空間占用;接著,將壓縮后的消息轉換為字節流數組,將字節流數組封裝至待分發的消息體中;然后,將消息分發至應用端,應用端接收到消息之后進行轉碼解壓縮;最后,將得到的消息進行完整展示。

圖5 文本信息輕量化處理流程

2.3.3 離線消息存儲

由于不穩定的網絡環境,應用端設備會出現異常掉線的情況。在應用端設備異常掉線或者應用端設備用戶沒有登錄的期間,可能會有應用端用戶訂閱的主題消息發布,為了保證應用端用戶上線之后能夠正常收到離線時發布的消息,系統需要將這部分離線的消息存儲起來,等到應用端用戶上線之后再將消息推送給應用端用戶,以確保消息的可靠傳輸。

離線消息存儲的設計對本系統的開發有以下優點:

(1)離線消息存儲可以確保即使應用端用戶處于離線狀態,也能夠在用戶上線時接收到消息;

(2)應用端用戶不用擔心錯過任何信息,增強用戶的滿意度和體驗感;

(3)離線消息存儲在數據庫中,減少了消息的重復傳輸,從而降低了網絡的負載,提高了傳輸的效率。

綜上所述,該文將離線消息存儲到MySQL數據中,并且根據應用端用戶上線時的用戶名關鍵字將離線消息推送給指定用戶。具體的離線消息存儲設計如下所示:

首先在MySQL數據庫中創建一個離線消息存儲表temporary_storage,包含字段主鍵(id)、接收者id(application_user_id)、消息id(message_id)、消息內容(content)、消息類型(type)。數據庫表設計如表1所示。

表1 離線消息存儲表temporary_storage

服務端用戶在給應用端用戶發送消息時,先將數據存儲到temporary_storage表中,再發送給應用端用戶。應用端用戶收到消息后,返回至服務端一條確認收到消息,此時服務端將temporary_storage表中數據根據message_id進行刪除;如果沒有接收到應用端用戶的確認消息,服務端則認為應用端用戶處于離線狀態,將數據存儲至temporary_storage表中。當應用端用戶登錄時,根據用戶名application_id關鍵字檢查temporary_storage表中是否是該用戶的離線消息,將屬于該用戶的離線消息進行補發。

3 實驗結果與分析

為了驗證本章消息分發技術的設計以及數據加密算法、消息輕量化處理、數據校驗算法、離線消息存儲的正確性、可行性以及有效性,本小節設計了如下實驗,并且將本章所研究的輕量化文本信息分發技術與傳統JSON文本信息分發技術進行對比。

(1)數據加密實驗。

本節將使用的AES加密算法和目前流行的MD5,SHA-256,DES,RSA四種加密算法進行性能比較,使用hutool工具對五種加密算法進行加密速度上的實驗對比。由于一次加密過程的計算時間具有偶然性,為了盡可能消除偶然性因素,在該實驗中隨機生成10個長度為100字節的字符串進行10次加密,記錄每次加密的時間并計算平均耗時,時間單位為納秒。實驗對比結果如表2所示。

(2)消息輕量化處理實驗。

(a)編排一條數據,采用文本信息輕量化處理技術發送給在線用戶;

(b)同樣的一條數據,采用傳統JSON技術發送給在線用戶;

(c)查看控制臺輸出的消息分發前的長度與分發后長度。

實驗結果如表3所示。經過文本信息輕量化處理技術處理的文本信息長度小于原始文本信息。第二行是通過傳統JSON文本信息進行分發的結果,原始文本信息為1 745 bytes,經過JSON分發的文本信息為1 755 bytes;第三行是經過該文研究的輕量化文本信息分發技術的結果,原始文本信息為1 745 bytes,經過輕量化處理之后文本信息為931 bytes。

表3 文本信息分發對比

(3)數據校驗實驗。

(a)應用端設備用戶正常登錄;

(b)一條數據,發送給應用端用戶;

(c)編排一條新的數據,在后臺對這條數據的字節進行修改,模擬數據被篡改,再次發送給應用端用戶。

圖6為驗證結果,圖6(a)是第一條數據分發情況,第一條數據成功被應用端所接收;圖6(b)是第二條數據分發情況,第二條數據沒有被應用端接收,并且在服務端顯示數據被篡改。

(a)數據分發被應用段接收

(4)離線消息存儲實驗。

(a)應用端設備用戶沒有登錄,處于離線狀態;

(b)編排一條數據,發送給離線的用戶;

(c)應用端用戶登錄賬號,查看消息接收狀態。

圖7為驗證結果,圖7(a)表明用戶離線時,數據接收失敗,服務端顯示用戶不在線;圖7(b)表明應用端用戶登錄之后,數據成功接收,并且在服務端顯示接收成功。

(a)用戶離線下的分發失敗

實驗結果分析:

(1)數據加密算法的實驗過程及結果表明,AES在所對比的算法中具有較快的加密速度,證明了加密算法的先進性。

(2)輕量化處理驗證過程及結果表明,文本信息通過輕量化處理技術分發后的長度明顯小于消息分發前的長度,可見文本信息在發送時成功地進行了輕量化處理,證明了輕量化處理的可行性。

(3)數據校驗算法的驗證過程及結果表明,沒有被篡改的數據可以被應用端用戶成功接收,已經發生篡改的數據是不可以被應用端用戶接收的,在服務端的分發結果界面可以看到實時每條數據的接收情況,證明了數據校驗的有效性。

(4)離線消息存儲的驗證過程及結果表明,當用戶離線時,已經發送的消息被暫存至數據庫,待用戶在線時,用戶可以成功接收到該用戶對應的離線數據,證明了離線消息存儲機制的正確性、可靠性。

4 結束語

針對文本信息分發過程中存在的效率低下、可靠性不高的問題,研究了基于MQTT協議的輕量化文本信息分發技術。在文本信息分發過程中,為了保證數據的安全性、完整性和穩定性,提出了數據校驗加密算法以及離線消息存儲等方法。同時,為了適應網絡帶寬、提高分發效率,提出了對文本信息進行輕量化處理的方法。

但當前研究工作仍有待改進,文本信息分發技術采用的數據加密算法屬于傳統加密算法,在未來可以基于人工智能等新技術對加密算法有更深層次的研究,從而應對未來可能面臨的各種安全威脅。