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

?

基于MQTT協(xié)議的即時(shí)消息業(yè)務(wù)設(shè)計(jì)與實(shí)現(xiàn)①

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

1(中國(guó)科學(xué)院沈陽(yáng)計(jì)算技術(shù)研究所, 沈陽(yáng) 110168)2(中國(guó)科學(xué)院大學(xué), 北京 100049)

近年來(lái), 寬帶接入技術(shù)正以十分驚人的速度發(fā)展. 與此同時(shí), 移動(dòng)互聯(lián)網(wǎng)技術(shù)也日益成熟, 即時(shí)消息業(yè)務(wù)已成為移動(dòng)互聯(lián)時(shí)代的應(yīng)用熱點(diǎn). 在互聯(lián)網(wǎng)中XMPP和SIMPLE被廣泛使用, 但其并不能很好的適用于移動(dòng)互聯(lián)網(wǎng). 采用發(fā)布/訂閱模型的MQTT協(xié)議是一種輕量級(jí)的消息傳輸協(xié)議, 具有低功耗、節(jié)省流量和可擴(kuò)展性強(qiáng)的優(yōu)點(diǎn). 本文首先分析了XMPP和SIMPLE協(xié)議的不足之處, 研究了MQTT協(xié)議的消息格式以及協(xié)議的使用方式, 之后對(duì)即時(shí)消息業(yè)務(wù)進(jìn)行了設(shè)計(jì)和實(shí)現(xiàn). 并在功能和性能上進(jìn)行了相關(guān)的測(cè)試和分析.

即時(shí)消息; 發(fā)布/訂閱; MQTT; 移動(dòng)互聯(lián)網(wǎng)

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

本文主要分為四部分, 第一部分對(duì)SIMPLE和XMPP協(xié)議進(jìn)行了相關(guān)的研究, 并分析了在移動(dòng)互聯(lián)網(wǎng)下兩協(xié)議的不足之處. 第二部分提出了基于發(fā)布/訂閱的輕量級(jí)的MQTT協(xié)議, 對(duì)其進(jìn)行了簡(jiǎn)單地分析, 并闡述了它的消息格式. 第三部分對(duì)即時(shí)消息業(yè)務(wù)的話題、payload以及消息路由進(jìn)行了設(shè)計(jì)和實(shí)現(xiàn). 第四部分, 對(duì)本文設(shè)計(jì)的即時(shí)消息系統(tǒng)進(jìn)行了相關(guān)的測(cè)試和分析.

1 相關(guān)協(xié)議分析

1.1 SIMPLE協(xié)議

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

1.2 XMPP協(xié)議

XMPP由IETF于2004年完成了標(biāo)準(zhǔn)化工作, 符合RFC2778 和 RFC2779 規(guī)范. XMPP源于Jabber 協(xié)議, 它是以XML為基礎(chǔ)開放式的即時(shí)通信協(xié)議[4]. XMPP協(xié)議繼承了XML的靈活性、擴(kuò)展性, 它以TCP/IP傳輸為基礎(chǔ), 定義了客戶端、服務(wù)器和網(wǎng)關(guān)三種角色. 服務(wù)器不僅要承擔(dān)客戶端信息記錄, 還要負(fù)責(zé)連接管理和信息的路由功能. 網(wǎng)關(guān)負(fù)責(zé)各異構(gòu)即時(shí)通迅系統(tǒng)之間的通信.

1.3 XMPP、SIMPLE協(xié)議在移動(dòng)互聯(lián)網(wǎng)中的不足

XMPP和SIMPLE協(xié)議均是基于字符文本進(jìn)行傳輸?shù)耐ㄐ艆f(xié)議, 字符文本協(xié)議通信的效率較低, 為了確保通信的安全, 二者采用了TLS等加密傳輸機(jī)制計(jì)算量較大, 功耗較高.

XMPP和SIMPLE協(xié)議是基于相對(duì)可靠的網(wǎng)絡(luò)上的應(yīng)用層協(xié)議, 在底層網(wǎng)絡(luò)不穩(wěn)定的情況下, 容忍機(jī)制不夠健全, 應(yīng)用在移動(dòng)互聯(lián)網(wǎng)即時(shí)通信時(shí), 網(wǎng)絡(luò)的不穩(wěn)定現(xiàn)象經(jīng)常出現(xiàn), 恢復(fù)網(wǎng)絡(luò)連接需要較多交互數(shù)據(jù)包, 浪費(fèi)用戶流量, 降低了用戶體驗(yàn).

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

2 基于發(fā)布/訂閱的MQTT協(xié)議

2.1發(fā)布/訂閱模型概述

發(fā)布/訂閱模型是一種消息傳播模式, 消息的發(fā)布者不直接將消息發(fā)送到消息的訂閱者, 而是根據(jù)某種特征將發(fā)布的消息進(jìn)行分類, 在這個(gè)過(guò)程中消息的發(fā)布者不需要關(guān)注消息的訂閱者. 同樣, 消息的訂閱者通過(guò)訂閱某個(gè)感興趣的消息, 不需要關(guān)注消息的發(fā)布者. 在這種機(jī)制下, 消息的若干個(gè)發(fā)布者與若干個(gè)訂閱者之間不需要直接進(jìn)行通信, 而是通過(guò)建立消息代理作為中介互相通信. 通過(guò)這種發(fā)布者與訂閱者之間的解耦合關(guān)系, 這種模式提供了更好的網(wǎng)絡(luò)擴(kuò)展性和更動(dòng)態(tài)的網(wǎng)絡(luò)拓?fù)?

發(fā)布/訂閱模型中, 消息的訂閱者往往只接受消息發(fā)布者所發(fā)布消息的某個(gè)子集. 消息的過(guò)濾指的是對(duì)接受和處理的消息進(jìn)行選擇的過(guò)程. 通常有兩種過(guò)濾形式: 分別是基于主題和基于內(nèi)容的過(guò)濾, MQTT協(xié)議采用基于主題的發(fā)布／訂閱模式.

在基于主題(Topic)的發(fā)布／訂閱模型中, 消息以特定的主題名標(biāo)識(shí)被發(fā)布者發(fā)布至消息代理服務(wù)器上. 基于主題的發(fā)布／訂閱模式中, 訂閱同一主題的訂閱者將會(huì)收到相同的消息, 消息的訂閱者可以訂閱多個(gè)主題. 發(fā)布者負(fù)責(zé)定義訂閱者可以訂閱的消息類別. 消息代理負(fù)責(zé)維護(hù)消息隊(duì)列, 執(zhí)行消息的存儲(chǔ)轉(zhuǎn)發(fā)功能.

2.2MQTT協(xié)議簡(jiǎn)介

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

MQTT主要有有以下幾個(gè)特性:

①使用基于主題的發(fā)布/訂閱消息模式, 提供一對(duì)多的消息發(fā)布, 屏蔽了應(yīng)用程序之間的耦合性;

② MQTT協(xié)議有三種級(jí)別的消息發(fā)布服務(wù)質(zhì)量[7]: “至多一次”, 發(fā)生的消息會(huì)丟失或重復(fù), 這一級(jí)別可用于一些傳感器傳輸數(shù)據(jù), 消息丟失一次對(duì)系統(tǒng)不會(huì)有嚴(yán)重影響, 因?yàn)樵诓痪弥笙到y(tǒng)還會(huì)進(jìn)行消息的第二次發(fā)送; “至少一次”, 該情況下能確保傳輸消息的準(zhǔn)確到達(dá), 但有可能會(huì)產(chǎn)生消息重復(fù)的傳輸?shù)默F(xiàn)象; “只有一次”, 確保消息只到達(dá)一次. 這一級(jí)別可用于一些計(jì)費(fèi)系統(tǒng), 使用該級(jí)別表明進(jìn)行傳輸?shù)南?nèi)容特別重要;

③ MQTT協(xié)議采用二進(jìn)制的形式表達(dá), 固定長(zhǎng)度的頭部只有2 字節(jié), 協(xié)議交換達(dá)到最小化, 極大的降低了網(wǎng)絡(luò)帶寬的開銷.

2.3 MQTT協(xié)議的消息格式

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

表1 MQTT協(xié)議的消息格式

消息體的固定報(bào)頭有2個(gè)字節(jié)長(zhǎng), 具體的格式如表2所示.

表2 固定頭域

固定報(bào)頭的高四位是消息的類型, 最多可以支持16種的消息類型. 目前, MQTT協(xié)議已經(jīng)定義了14種消息類型[5].

Dup Flag用于標(biāo)識(shí)是否第一次發(fā)送該消息. 當(dāng)Dup Flag為0時(shí)表示第一次發(fā)送該消息. 雖然Dup Flag為1表示該消息是重傳消息, 但是不能保證用戶之前收到過(guò)該消息.

QOS表明發(fā)布消息的交付質(zhì)量等級(jí), 可選值為 0、1、2.

Retain標(biāo)識(shí)僅在發(fā)布消息中使用. 對(duì)于消息的發(fā)布者, 當(dāng)客戶端發(fā)送消息時(shí), 如果該標(biāo)識(shí)設(shè)置為1, 則消息發(fā)送到訂閱該主題的所有訂閱者之后, 代理服務(wù)器仍然保存該消息. 對(duì)于消息的訂閱者, 當(dāng)一個(gè)主題有了新的訂閱用戶, 最后被保留的消息主題將被設(shè)置保留字段, 然后發(fā)送到新的消息訂閱者. 當(dāng)主題不存在相關(guān)的保留信息時(shí), 則不發(fā)送.

Remaining Length是剩余長(zhǎng)度, 包含Variable header、payload的長(zhǎng)度, 默認(rèn)Remaining Length為1字節(jié), 最多支持?jǐn)U展4字節(jié), 因此一條MQTT可攜帶的消息最高是256MB.

3 即時(shí)消息業(yè)務(wù)的設(shè)計(jì)與實(shí)現(xiàn)

即時(shí)通信在實(shí)際的應(yīng)用場(chǎng)景中, 客戶端與服務(wù)器的具體交互流程如圖1所示.

圖1 IM交互流程簡(jiǎn)圖

客戶端A、B會(huì)分別訂閱/IM/A和/IM/B主題. 客戶端A和B會(huì)向?qū)Ψ降闹黝}上發(fā)布消息, 之后會(huì)通過(guò)代理服務(wù)器進(jìn)行轉(zhuǎn)發(fā)[8]. MQTT協(xié)議中消息不攜帶路由信息和消息的內(nèi)容類型. 因此, 我們需要對(duì)payload中攜帶的消息格式根據(jù)業(yè)務(wù)的需求進(jìn)行明確的規(guī)范, 使客戶端能夠從payload中獲取消息的類別、發(fā)送者的信息以及載荷域的內(nèi)容格式等相關(guān)信息. 由此可見(jiàn), 使用MQTT協(xié)議實(shí)現(xiàn)即時(shí)通信的應(yīng)用關(guān)鍵點(diǎn)在于話題的設(shè)計(jì), 消息的發(fā)布、訂閱流程以及消息路由. 下面將對(duì)即時(shí)消息的上述問(wèn)題進(jìn)行設(shè)計(jì)和實(shí)現(xiàn).

3.1話題格式設(shè)計(jì)

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

在MQTT協(xié)議中話題至少需要一個(gè)字符的長(zhǎng)度, 話題對(duì)大小寫敏感的. 通過(guò)“/”用來(lái)區(qū)分相應(yīng)的話題層級(jí). 規(guī)定, 以“/”開頭的話題為普通話題, 以”$”開頭的話題為系統(tǒng)話題[9]. namespace為用戶所在的組織名稱, 可以為企業(yè)或?qū)W校的標(biāo)識(shí)名. 中間部分用來(lái)表示話題類別, im表示即時(shí)消息話題. 最后的uid代表用戶的唯一標(biāo)示符.

3.2Payload設(shè)計(jì)

對(duì)于一條即時(shí)消息, 消息的接收方在接收到消息之后, 需要知道該消息的發(fā)送時(shí)間、消息的類型、消息內(nèi)容的類型、消息內(nèi)容以及該消息的發(fā)送者等信息. 因此該消息的payload的設(shè)計(jì)如表3所示.

表3 即時(shí)消息的payload設(shè)計(jì)

Sender: 發(fā)送者消息, 變長(zhǎng), 可為空.

TS: 發(fā)送時(shí)的時(shí)間戳, 4個(gè)字節(jié), 不可為空.

在Type中包括發(fā)送消息的類型(高4位)以及消息內(nèi)容的類型(低4位). 消息的類型, 現(xiàn)階段只用三種表示, 具體是0表示是點(diǎn)對(duì)點(diǎn)的即時(shí)消息, 1表示PC端到手機(jī)端的即時(shí)消息, 2表示的是手機(jī)到PC端的即時(shí)消息, 其余13種保留用于今后擴(kuò)展; 消息內(nèi)容的類型, 可表示16種媒體類型, 具體的示例定義如下: 0表示普通文本信息, 1表示圖片消息, 2表示音頻文件, 3表示視頻文件, 4表示PDF文檔, 5表示W(wǎng)ord文檔等. 這里需要注意的是, 在Payload中一次只攜帶一種媒體文件. 采用離線文件傳輸?shù)姆绞? 不在payload中進(jìn)行文件傳輸, 文件上傳結(jié)束后將對(duì)應(yīng)的下載鏈接地址在payload進(jìn)行傳輸. Type的詳細(xì)設(shè)計(jì)如表4.

表4 Type詳細(xì)設(shè)計(jì)

Con-len: 4 個(gè)字節(jié), 表示后面攜帶的媒體內(nèi)容的長(zhǎng)度.

Content: 是將消息內(nèi)容按照json格式組織的字符串. 該字符串默認(rèn)情況下按照json數(shù)組的形式來(lái)組織的, 這樣就允許在消息中支持多種媒體并存, 可以構(gòu)建較為復(fù)雜的應(yīng)用時(shí)滿足對(duì)應(yīng)的需求. 對(duì)于每種媒體, 按照媒體類型不同, 提供不同的描述字段. 具體實(shí)現(xiàn)如下:

"con":[

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

" co": "url 或者文本",//媒體的內(nèi)容

**Optional**

"fn": {

“name”: “text.txt”,

“size”: “500”

}

} // 可以并列多個(gè)消息內(nèi)容

]

在上述定義中,

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

co: 是媒體的內(nèi)容.

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

3.3 預(yù)訂閱設(shè)計(jì)和實(shí)現(xiàn)

IM是通過(guò)話題來(lái)組織的, 而話題的訂閱一般由客戶端完成. 當(dāng)所需訂閱的話題過(guò)多時(shí), 由于客戶端訂閱數(shù)據(jù)量龐大, 必定給網(wǎng)絡(luò)帶來(lái)巨大壓力. 其次, 對(duì)于移動(dòng)設(shè)備而言, 因數(shù)據(jù)流量有限, 勢(shì)必將造成不必要的浪費(fèi). 因此, 為了減輕移動(dòng)客戶端壓力, 提高用戶體驗(yàn), 本文采用預(yù)訂閱設(shè)計(jì)方案, 即在服務(wù)器端構(gòu)造一個(gè)預(yù)訂閱的客戶端. 流程如圖2所示.

圖2 預(yù)訂閱序列圖

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

1) 當(dāng)服務(wù)器檢測(cè)到客戶端是首次連接時(shí), 就會(huì)將uid及其他相關(guān)信息推送到服務(wù)器中的某一話題.

2) 預(yù)訂閱模塊接收到服務(wù)器發(fā)送的消息后, 解析此消息, 獲得新連接用戶的uid及該用戶的預(yù)訂閱話題列表. 根據(jù)訂閱列表, 預(yù)訂閱模塊向代理服務(wù)器進(jìn)行訂閱請(qǐng)求.

3) 通過(guò)代理服務(wù)器的接口實(shí)現(xiàn)預(yù)訂閱模塊中話題的預(yù)訂閱和取消預(yù)訂閱. 完成訂閱后, 代理服務(wù)器向預(yù)訂閱模塊返回確認(rèn)消息.

3.4 消息路由設(shè)計(jì)實(shí)現(xiàn)

本文要求實(shí)現(xiàn)多終端IM消息同步. 對(duì)于接收方而言, 由于同時(shí)訂閱了自己的IM topic, 所以收到消息后可以實(shí)現(xiàn)各終端間的同步. 但對(duì)于發(fā)送方而言, 由于在消息發(fā)送時(shí)各終端沒(méi)有聯(lián)系, 導(dǎo)致發(fā)送方的各終端間無(wú)法同步[10]. 為此, 本文提出了一套通過(guò)在代理服務(wù)器上增加消息路由機(jī)制, 實(shí)現(xiàn)的基于消息路由規(guī)則的多終端消息同步方法.

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

圖3 消息路由示例

具體過(guò)程說(shuō)明如下:

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

② Broker收到消息后, 經(jīng)過(guò)路有規(guī)則查詢, 判定該消息是否有匹配的路由規(guī)則, 如果存在則繼續(xù)進(jìn)行, 否則忽略③和⑤

③ 根據(jù)規(guī)則中的消息路由動(dòng)作進(jìn)行消息路由, 找到路由轉(zhuǎn)發(fā)的目的topic, 圖中為Alice的IM topic.

④ 把IM消息Pub給Jim

⑤ Alice PC端發(fā)送的消息在其他終端得到接收, 并呈現(xiàn)

⑥ 消息分發(fā)到Jim的所有終端

4 即時(shí)消息業(yè)務(wù)的測(cè)試

4.1功能測(cè)試

表5 測(cè)試環(huán)境參數(shù)

本文考慮到平臺(tái)間兼容性問(wèn)題, 在該功能測(cè)試部分采用了以下環(huán)境: 1臺(tái)Android手機(jī), 1臺(tái)iphone5s手機(jī), 1臺(tái)MQTT服務(wù)器(圖4所示), 20Mbps網(wǎng)絡(luò)帶寬.

圖4 消息時(shí)序圖

IOS用戶和Android用戶之間通過(guò)MQTT服務(wù)器, 分別發(fā)送文字、語(yǔ)音、圖片、視頻等不同類型的媒體消息, 消息發(fā)送流程如圖4所示, 呈現(xiàn)效果如圖5所示.

圖5 IM效果圖

測(cè)試結(jié)果表明, 各種類型媒體消息發(fā)送均能即時(shí)顯示.

4.2 IM流量測(cè)試

為了測(cè)試MQTT在移動(dòng)互聯(lián)網(wǎng)中的性能優(yōu)勢(shì), 筆者在測(cè)試過(guò)程中分別對(duì)SIMPLE、XMPP、MQTT三種協(xié)議進(jìn)行了封裝, 并使用wireshark進(jìn)行了抓包, 對(duì)同網(wǎng)絡(luò)環(huán)境下三種協(xié)議所消耗的網(wǎng)絡(luò)流量進(jìn)行了對(duì)比, 結(jié)果如圖6所示.

圖6 三種協(xié)議消耗流量對(duì)比圖

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

4.3服務(wù)器性能測(cè)試

最后, 對(duì)服務(wù)器負(fù)載能力進(jìn)行測(cè)試. 在客戶端模擬大規(guī)模用戶對(duì)服務(wù)器發(fā)起連接請(qǐng)求, 分別模擬10000到100000個(gè)連接請(qǐng)求, 所有請(qǐng)求的連接建立完成后, 分別進(jìn)行不同數(shù)目的消息推送, 測(cè)試所用的時(shí)間以及服務(wù)器CPU的占用率, 測(cè)試結(jié)果如表6所示.

表6 服務(wù)器負(fù)載性能測(cè)試

由表中數(shù)據(jù)可以看出, 本文設(shè)計(jì)的即時(shí)消息業(yè)務(wù)基本滿足了在移動(dòng)互聯(lián)領(lǐng)域上的需求, 且服務(wù)器的負(fù)載也在可以接受的范圍內(nèi).

5 結(jié)語(yǔ)

即時(shí)消息業(yè)務(wù)已經(jīng)發(fā)展成為人們?nèi)粘贤ǖ闹匾?方式之一, 現(xiàn)有的即時(shí)通信協(xié)議不能很好地滿足移動(dòng)互聯(lián)網(wǎng)環(huán)境下的網(wǎng)絡(luò)不穩(wěn)定、流量花費(fèi)高以及移動(dòng)設(shè)備的低功耗等特點(diǎn). 采用基于發(fā)布/訂閱模型的輕量級(jí)消息傳輸?shù)腗QTT協(xié)議, 具有低功耗和移動(dòng)互聯(lián)網(wǎng)帶寬利用率高的特點(diǎn). 本文在分析了相關(guān)私有協(xié)議的基礎(chǔ)上闡釋了MQTT協(xié)議在移動(dòng)互聯(lián)網(wǎng)即時(shí)消息業(yè)務(wù)中的優(yōu)勢(shì), 研究分析了MQTT協(xié)議的消息格式, 并對(duì)即時(shí)消息的話題格式、預(yù)訂閱以及消息路由進(jìn)行了設(shè)計(jì)和實(shí)現(xiàn). 最后對(duì)實(shí)現(xiàn)的即時(shí)消息業(yè)務(wù)進(jìn)行了相關(guān)的測(cè)試和分析.

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 馬躍,孫翱,賈軍營(yíng),孫建偉,于碧輝,楊雪華.MQTT協(xié)議在移動(dòng)互聯(lián)網(wǎng)即時(shí)通信中的應(yīng)用.計(jì)算機(jī)系統(tǒng)應(yīng)用,2016,25(3): 170–176.

9 楊海波,王默涵,賈正鋒,卜立平.面向移動(dòng)互聯(lián)網(wǎng)的Presence/IM機(jī)制研究.小型微型計(jì)算機(jī)系統(tǒng),2015,36(11). 2549–2553.

10 任亨.基于MQTT協(xié)議的消息推送服務(wù)器.計(jì)算機(jī)系統(tǒng)應(yīng)用,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

教育部-中國(guó)移動(dòng)科研基金(2015)(MCM20150103)

2016-06-30;

2016-08-18

[10.15888/j.cnki.csa.005678]