基于MQTT協議的即時消息業務設計與實現①

林 滸, 張家銘,2, 楊海波

?

基于MQTT協議的即時消息業務設計與實現①

林 滸1, 張家銘1,2, 楊海波1

1(中國科學院沈陽計算技術研究所, 沈陽 110168)2(中國科學院大學, 北京 100049)

近年來, 寬帶接入技術正以十分驚人的速度發展. 與此同時, 移動互聯網技術也日益成熟, 即時消息業務已成為移動互聯時代的應用熱點. 在互聯網中XMPP和SIMPLE被廣泛使用, 但其并不能很好的適用于移動互聯網. 采用發布/訂閱模型的MQTT協議是一種輕量級的消息傳輸協議, 具有低功耗、節省流量和可擴展性強的優點. 本文首先分析了XMPP和SIMPLE協議的不足之處, 研究了MQTT協議的消息格式以及協議的使用方式, 之后對即時消息業務進行了設計和實現. 并在功能和性能上進行了相關的測試和分析.

即時消息; 發布/訂閱; MQTT; 移動互聯網

隨著移動互聯網和移動智能終端的普及, 移動智能終端已經成為網民接入互聯網的重要途徑, 即時通信迎來了前所未有的發展契機. 與此同時, 由于用戶通常會隨身攜帶手機, 移動消息應用在手機客戶端上的重要性也逐漸凸顯, 移動消息中的即時消息業務成為一個炙手可熱的研究領域. 目前, 即時消息除了通過采用私有協議(如QQ、微信等)實現外, 還主要通過SIMPLE和XMPP兩大類協議. 然而, 由于移動智能終端對流量有限制, 對網絡的帶寬以及終端的功耗等有特殊的要求, 因此即時消息業務對即時通信協議有更高的要求. 然而上述兩種協議均不能較好的滿足移動消息的應用場景. 本文通過對解決當前即時消息業務的相關協議進行研究和分析, 提出了更適合移動互聯網的基于MQTT協議的即時消息業務解決方案.

本文主要分為四部分, 第一部分對SIMPLE和XMPP協議進行了相關的研究, 并分析了在移動互聯網下兩協議的不足之處. 第二部分提出了基于發布/訂閱的輕量級的MQTT協議, 對其進行了簡單地分析, 并闡述了它的消息格式. 第三部分對即時消息業務的話題、payload以及消息路由進行了設計和實現. 第四部分, 對本文設計的即時消息系統進行了相關的測試和分析.

1 相關協議分析

1.1 SIMPLE協議

SIMPLE(SIP for Instant Messaging and Presence Leveraging Extensions)協議簇是由IETF SIMPLE工作組制定的, 主要是擴展SIP協議, 以使其支持IM服務[3]. SIMPLE工作組為SIMPLE協議的規范制定做了大量的工作, 并且發布了一系列RFC文檔. SIMPLE提出session模式和page模式[3]. session模式中, 即時消息被作為一種類似于音視頻的媒體, 通過SIP信令進行交互, 即時消息協商后建立一個會話, 通過建立的會話進行消息媒體的交互. page模式中, 通過SIP請求包裹即時消息的內容發送消息的方式. 通過對SIP協議的擴展, SIMPLE協議有了很大的改進. 在完成了SIP信令協商之后, 一般的多媒體會話需要使用一些其他協議來建立用戶代理之間的會話通道以此完成會話數據的交互. 基于SIMPLE協議的即時消息交互不需要建立會話通道, 消息通過SIMPLE協議的消息命令直接發送, 每個消息都由一個單獨的消息命令來傳播, 彼此獨立.

1.2 XMPP協議

XMPP由IETF于2004年完成了標準化工作, 符合RFC2778 和 RFC2779 規范. XMPP源于Jabber 協議, 它是以XML為基礎開放式的即時通信協議[4]. XMPP協議繼承了XML的靈活性、擴展性, 它以TCP/IP傳輸為基礎, 定義了客戶端、服務器和網關三種角色. 服務器不僅要承擔客戶端信息記錄, 還要負責連接管理和信息的路由功能. 網關負責各異構即時通迅系統之間的通信.

1.3 XMPP、SIMPLE協議在移動互聯網中的不足

XMPP和SIMPLE協議均是基于字符文本進行傳輸的通信協議, 字符文本協議通信的效率較低, 為了確保通信的安全, 二者采用了TLS等加密傳輸機制計算量較大, 功耗較高.

XMPP和SIMPLE協議是基于相對可靠的網絡上的應用層協議, 在底層網絡不穩定的情況下, 容忍機制不夠健全, 應用在移動互聯網即時通信時, 網絡的不穩定現象經常出現, 恢復網絡連接需要較多交互數據包, 浪費用戶流量, 降低了用戶體驗.

XMPP和SIMPLE協議是基于消息體尋址的協議, 消息體中包含了消息的發送者、消息的接收者以及消息路由用的會話標示等頭域, 這使得消息體過大, 極大的降低了帶寬的利用率.

2 基于發布/訂閱的MQTT協議

2.1發布/訂閱模型概述

發布/訂閱模型是一種消息傳播模式, 消息的發布者不直接將消息發送到消息的訂閱者, 而是根據某種特征將發布的消息進行分類, 在這個過程中消息的發布者不需要關注消息的訂閱者. 同樣, 消息的訂閱者通過訂閱某個感興趣的消息, 不需要關注消息的發布者. 在這種機制下, 消息的若干個發布者與若干個訂閱者之間不需要直接進行通信, 而是通過建立消息代理作為中介互相通信. 通過這種發布者與訂閱者之間的解耦合關系, 這種模式提供了更好的網絡擴展性和更動態的網絡拓撲.

發布/訂閱模型中, 消息的訂閱者往往只接受消息發布者所發布消息的某個子集. 消息的過濾指的是對接受和處理的消息進行選擇的過程. 通常有兩種過濾形式: 分別是基于主題和基于內容的過濾, MQTT協議采用基于主題的發布／訂閱模式.

在基于主題(Topic)的發布／訂閱模型中, 消息以特定的主題名標識被發布者發布至消息代理服務器上. 基于主題的發布／訂閱模式中, 訂閱同一主題的訂閱者將會收到相同的消息, 消息的訂閱者可以訂閱多個主題. 發布者負責定義訂閱者可以訂閱的消息類別. 消息代理負責維護消息隊列, 執行消息的存儲轉發功能.

2.2MQTT協議簡介

MQTT(Message Queuing Telemetry Transport, 消息隊列遙測傳輸)是由IBM公司開發的即時通訊協議, 它是一個基于發布/訂閱模型、輕量級的消息傳輸協議[1]. 具有開放、易用、精簡等特點. MQTT協議是為那些計算能力有限, 且需要工作在低帶寬、不可靠的網絡通訊而設計的協議[2].

MQTT主要有有以下幾個特性:

①使用基于主題的發布/訂閱消息模式, 提供一對多的消息發布, 屏蔽了應用程序之間的耦合性;

② MQTT協議有三種級別的消息發布服務質量[7]: “至多一次”, 發生的消息會丟失或重復, 這一級別可用于一些傳感器傳輸數據, 消息丟失一次對系統不會有嚴重影響, 因為在不久之后系統還會進行消息的第二次發送; “至少一次”, 該情況下能確保傳輸消息的準確到達, 但有可能會產生消息重復的傳輸的現象; “只有一次”, 確保消息只到達一次. 這一級別可用于一些計費系統, 使用該級別表明進行傳輸的消息內容特別重要;

③ MQTT協議采用二進制的形式表達, 固定長度的頭部只有2 字節, 協議交換達到最小化, 極大的降低了網絡帶寬的開銷.

2.3 MQTT協議的消息格式

MQTT消息體由固定報頭、可變報頭以及有效載荷三部分組成[6], 固定報頭是每個消息體都必須要包含的部分, 固定報頭部分的長度為2字節. 消息格式如表1所示.

表1 MQTT協議的消息格式

消息體的固定報頭有2個字節長, 具體的格式如表2所示.

表2 固定頭域

固定報頭的高四位是消息的類型, 最多可以支持16種的消息類型. 目前, MQTT協議已經定義了14種消息類型[5].

Dup Flag用于標識是否第一次發送該消息. 當Dup Flag為0時表示第一次發送該消息. 雖然Dup Flag為1表示該消息是重傳消息, 但是不能保證用戶之前收到過該消息.

QOS表明發布消息的交付質量等級, 可選值為 0、1、2.

Retain標識僅在發布消息中使用. 對于消息的發布者, 當客戶端發送消息時, 如果該標識設置為1, 則消息發送到訂閱該主題的所有訂閱者之后, 代理服務器仍然保存該消息. 對于消息的訂閱者, 當一個主題有了新的訂閱用戶, 最后被保留的消息主題將被設置保留字段, 然后發送到新的消息訂閱者. 當主題不存在相關的保留信息時, 則不發送.

Remaining Length是剩余長度, 包含Variable header、payload的長度, 默認Remaining Length為1字節, 最多支持擴展4字節, 因此一條MQTT可攜帶的消息最高是256MB.

3 即時消息業務的設計與實現

即時通信在實際的應用場景中, 客戶端與服務器的具體交互流程如圖1所示.

圖1 IM交互流程簡圖

客戶端A、B會分別訂閱/IM/A和/IM/B主題. 客戶端A和B會向對方的主題上發布消息, 之后會通過代理服務器進行轉發[8]. MQTT協議中消息不攜帶路由信息和消息的內容類型. 因此, 我們需要對payload中攜帶的消息格式根據業務的需求進行明確的規范, 使客戶端能夠從payload中獲取消息的類別、發送者的信息以及載荷域的內容格式等相關信息. 由此可見, 使用MQTT協議實現即時通信的應用關鍵點在于話題的設計, 消息的發布、訂閱流程以及消息路由. 下面將對即時消息的上述問題進行設計和實現.

3.1話題格式設計

話題格式為:/namespace/im/u/uid.

在MQTT協議中話題至少需要一個字符的長度, 話題對大小寫敏感的. 通過“/”用來區分相應的話題層級. 規定, 以“/”開頭的話題為普通話題, 以”$”開頭的話題為系統話題[9]. namespace為用戶所在的組織名稱, 可以為企業或學校的標識名. 中間部分用來表示話題類別, im表示即時消息話題. 最后的uid代表用戶的唯一標示符.

3.2Payload設計

對于一條即時消息, 消息的接收方在接收到消息之后, 需要知道該消息的發送時間、消息的類型、消息內容的類型、消息內容以及該消息的發送者等信息. 因此該消息的payload的設計如表3所示.

表3 即時消息的payload設計

Sender: 發送者消息, 變長, 可為空.

TS: 發送時的時間戳, 4個字節, 不可為空.

在Type中包括發送消息的類型(高4位)以及消息內容的類型(低4位). 消息的類型, 現階段只用三種表示, 具體是0表示是點對點的即時消息, 1表示PC端到手機端的即時消息, 2表示的是手機到PC端的即時消息, 其余13種保留用于今后擴展; 消息內容的類型, 可表示16種媒體類型, 具體的示例定義如下: 0表示普通文本信息, 1表示圖片消息, 2表示音頻文件, 3表示視頻文件, 4表示PDF文檔, 5表示Word文檔等. 這里需要注意的是, 在Payload中一次只攜帶一種媒體文件. 采用離線文件傳輸的方式, 不在payload中進行文件傳輸, 文件上傳結束后將對應的下載鏈接地址在payload進行傳輸. Type的詳細設計如表4.

表4 Type詳細設計

Con-len: 4 個字節, 表示后面攜帶的媒體內容的長度.

Content: 是將消息內容按照json格式組織的字符串. 該字符串默認情況下按照json數組的形式來組織的, 這樣就允許在消息中支持多種媒體并存, 可以構建較為復雜的應用時滿足對應的需求. 對于每種媒體, 按照媒體類型不同, 提供不同的描述字段. 具體實現如下:

"con":[

{"ty": 0, // 0:文本,1:圖片, 2:音頻, 3:視頻, 4:文檔文件, 5:文件, 6:地圖, 14 :富媒體

" co": "url 或者文本",//媒體的內容

**Optional**

"fn": {

“name”: “text.txt”,

“size”: “500”

}

} // 可以并列多個消息內容

]

在上述定義中,

ty: 是媒體的類型, 目前需要考慮支持的媒體類型包括: 文本, 圖片, 音頻, 視頻, 文檔, 文件, 地圖位置, html代碼, 以及其他富媒體, 如通知、公告、輕應用數據等.

co: 是媒體的內容.

fn: 如果媒體涉及到文件或者文檔名字, 這里給出的是文件.

3.3 預訂閱設計和實現

IM是通過話題來組織的, 而話題的訂閱一般由客戶端完成. 當所需訂閱的話題過多時, 由于客戶端訂閱數據量龐大, 必定給網絡帶來巨大壓力. 其次, 對于移動設備而言, 因數據流量有限, 勢必將造成不必要的浪費. 因此, 為了減輕移動客戶端壓力, 提高用戶體驗, 本文采用預訂閱設計方案, 即在服務器端構造一個預訂閱的客戶端. 流程如圖2所示.

圖2 預訂閱序列圖

預訂閱模塊幫助用戶完成訂閱話題工作的具體流程:

1) 當服務器檢測到客戶端是首次連接時, 就會將uid及其他相關信息推送到服務器中的某一話題.

2) 預訂閱模塊接收到服務器發送的消息后, 解析此消息, 獲得新連接用戶的uid及該用戶的預訂閱話題列表. 根據訂閱列表, 預訂閱模塊向代理服務器進行訂閱請求.

3) 通過代理服務器的接口實現預訂閱模塊中話題的預訂閱和取消預訂閱. 完成訂閱后, 代理服務器向預訂閱模塊返回確認消息.

3.4 消息路由設計實現

本文要求實現多終端IM消息同步. 對于接收方而言, 由于同時訂閱了自己的IM topic, 所以收到消息后可以實現各終端間的同步. 但對于發送方而言, 由于在消息發送時各終端沒有聯系, 導致發送方的各終端間無法同步[10]. 為此, 本文提出了一套通過在代理服務器上增加消息路由機制, 實現的基于消息路由規則的多終端消息同步方法.

發送到一個話題上的消息需要根據消息路由規則, 判斷是否同時復制到其他話題上. 該規則采用話題的模糊匹配, 對于匹配成功的消息, 將其轉發至特定話題上. 其中一條消息路由規則的基本組成部分為三部分, 源地址(src Topic)、消息路由動作(action)、目的地址(dest Topic). 消息路由的詳細過程如圖3所示.

圖3 消息路由示例

具體過程說明如下:

① Alice的PC端向Jim的IM topic上發送一條消息

② Broker收到消息后, 經過路有規則查詢, 判定該消息是否有匹配的路由規則, 如果存在則繼續進行, 否則忽略③和⑤

③ 根據規則中的消息路由動作進行消息路由, 找到路由轉發的目的topic, 圖中為Alice的IM topic.

④ 把IM消息Pub給Jim

⑤ Alice PC端發送的消息在其他終端得到接收, 并呈現

⑥ 消息分發到Jim的所有終端

4 即時消息業務的測試

4.1功能測試

表5 測試環境參數

本文考慮到平臺間兼容性問題, 在該功能測試部分采用了以下環境: 1臺Android手機, 1臺iphone5s手機, 1臺MQTT服務器(圖4所示), 20Mbps網絡帶寬.

圖4 消息時序圖

IOS用戶和Android用戶之間通過MQTT服務器, 分別發送文字、語音、圖片、視頻等不同類型的媒體消息, 消息發送流程如圖4所示, 呈現效果如圖5所示.

圖5 IM效果圖

測試結果表明, 各種類型媒體消息發送均能即時顯示.

4.2 IM流量測試

為了測試MQTT在移動互聯網中的性能優勢, 筆者在測試過程中分別對SIMPLE、XMPP、MQTT三種協議進行了封裝, 并使用wireshark進行了抓包, 對同網絡環境下三種協議所消耗的網絡流量進行了對比, 結果如圖6所示.

圖6 三種協議消耗流量對比圖

從上圖可以看出, 隨著發送消息文本數據包(橫坐標)的增加, 三種協議消耗的流量(縱坐標)均在不停地增加. 其中, MQTT協議的增幅最小, XMPP協議次之, 但增幅也不大, SIMPLE協議增幅最大. 由以上試驗數據可以看出, 在流量消耗這方面MQTT協議的性能最好.

4.3服務器性能測試

最后, 對服務器負載能力進行測試. 在客戶端模擬大規模用戶對服務器發起連接請求, 分別模擬10000到100000個連接請求, 所有請求的連接建立完成后, 分別進行不同數目的消息推送, 測試所用的時間以及服務器CPU的占用率, 測試結果如表6所示.

表6 服務器負載性能測試

由表中數據可以看出, 本文設計的即時消息業務基本滿足了在移動互聯領域上的需求, 且服務器的負載也在可以接受的范圍內.

5 結語

即時消息業務已經發展成為人們日常溝通的重要 方式之一, 現有的即時通信協議不能很好地滿足移動互聯網環境下的網絡不穩定、流量花費高以及移動設備的低功耗等特點. 采用基于發布/訂閱模型的輕量級消息傳輸的MQTT協議, 具有低功耗和移動互聯網帶寬利用率高的特點. 本文在分析了相關私有協議的基礎上闡釋了MQTT協議在移動互聯網即時消息業務中的優勢, 研究分析了MQTT協議的消息格式, 并對即時消息的話題格式、預訂閱以及消息路由進行了設計和實現. 最后對實現的即時消息業務進行了相關的測試和分析.

1 Banks A, Gupta R. OASIS Standard MQTT Version 3.1.1. http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/mqtt-v3.1.1.html. [2014-10-29].

2 Tang K, Wang Y, Liu H, et al. Design and implementation of push notification system based on the MQTT protocol. Proc. International Conference on Informationence& Computer Applications. 2013. 92. 116–119.

3 Day M, Rosenberg J, Sugano H. A model for presence and instant messaging. IETF, 2000, 2: RFC2778.

4 Extensible Messaging and Presence Protocol http://xmpp.org/.

5 IBM. MQTT Telemetry Transport. http://msqq.org. [2013-06-05].

6 IBM, Eurotech. MQTT3.1Protocol Specification. http//public. dhe.ibm.com/software/dw/webservices/ws-mqtt/mqtt-v3rl.html. [2010-08-24].

7 Lee S, Kim H, Hong D, Ju H. Correlation analysis of MQTT loss and delay according to Qos level. Information Networking (ICOIN). Bangkok. 2013.

8 馬躍,孫翱,賈軍營,孫建偉,于碧輝,楊雪華.MQTT協議在移動互聯網即時通信中的應用.計算機系統應用,2016,25(3): 170–176.

9 楊海波,王默涵,賈正鋒,卜立平.面向移動互聯網的Presence/IM機制研究.小型微型計算機系統,2015,36(11). 2549–2553.

10 任亨.基于MQTT協議的消息推送服務器.計算機系統應用,2014,23(3):77–82.

Design and Implementation of Instant Messaging Business Based on the MQTT Protocol

LIN Hu1, ZHANG Jia-Ming1,2, YANG Hai-Bo1

1(Shenyang Institute of Computing Technology, Chinese Academy of Sciences, Shenyang 110168, China)2(University of Chinese Academy of Sciences, Beijing 100049, China)

In recent years, broadband access is developing with astonishing speed. At the same time, the mobile Internet technology is also increasingly mature, instant messaging business have become a hot point of the era of mobile Internet applications. XMPP and SIMPLE are widely used in the Internet, but they are not suited to the mobile Internet. The MQTT is a publish/subscribe model based and lightweight messaging protocol, which has the advantages of reducing power consumption, decreasing flow and has strong flexibility. Firstly, this article analyzes the shortcomings of XMPP and SIMPLE protocol. Secondly, it introduces the message format and the usage of the MQTT protocol. After the design and implementation of the instant messaging business, the related testing and analysis are carried on the function and performance.

instant messaging; Pub/Sub; MQTT; mobile Internet

教育部-中國移動科研基金(2015)(MCM20150103)

2016-06-30;

2016-08-18

[10.15888/j.cnki.csa.005678]