天天看點

掃盲貼:認識MQTT通信協定1、概述2、更多資料3、MQTT簡介4、MQTT應用現狀5、MQTT特點6、市面上的主流推送方案應用比較7、結語

1、概述

MQTT(Message Queuing Telemetry Transport,消息隊列遙測傳輸)是IBM開發的一個即時通訊協定,有可能成為物聯網的重要組成部分。該協定支援所有平台,幾乎可以把所有聯網物品和外部連接配接起來,被用來當做傳感器和緻動器(比如通過Twitter讓房屋聯網)的通信協定。

MQTT協定技術文檔:點此進入,當然也有PDF版的,百度一下,不過個人感覺不是官網上的字型和排版最舒服。

MQTT是輕量級基于代理的釋出/訂閱的消息傳輸協定,它可以通過很少的代碼和帶寬和遠端裝置連接配接。例如通過衛星和代理連接配接,通過撥号和醫療保健提供者連接配接,以及在一些自動化或小型裝置上,而且由于小巧,省電,協定開銷小和能高效的向一和多個接收者傳遞資訊,故同樣适用于稱動應用裝置上。

相信在想深入學習這個協定必是奔着解決某個問題而來的,上面給出了适用的場景,我之是以想深入的學習和了解這個協定,理由如下:

[1] 可以實作手機消息推送(PUSH);

[2] 協定簡單,最小的頭部隻需2個位元組,特别适合于嵌入式裝置場景中;

[3] 這是個了解什麼是協定絕好的例子。相比于其它複雜的協定例如tcp、http協定,至少說明文檔看的下去。

(本文同步釋出于:http://www.52im.net/thread-318-1-1.html)

2、更多資料

《一個基于MQTT通信協定的完整Android推送Demo [附件下載下傳]》

《求教android消息推送:GCM、XMPP、MQTT三種方案的優劣》

《移動端實時消息推送技術淺析》

《絕對幹貨:基于Netty實作海量接入的推送服務技術要點》

《開源免費的實時資訊推送伺服器DDPush介紹》

(更多文章請進入:http://www.52im.net/forum.php?mod=collection&action=view&ctid=11)

3、MQTT簡介

早在1999年,IBM的Andy Stanford-Clark博士以及Arcom公司ArlenNipper博士發明了MQTT(Message Queuing Telemetry Transport,消息隊列遙測傳輸)技術 。

MQTT的話題是他們在談論開源物聯網平台Pachube時提到的。Stanford-Clark認為Pachube很酷,其不足之處是不具備真正的推送功能。你需要不斷的進行輪詢才能得到即時資料。這正是MQTT能夠實作的,他提到了使用推送通信系統的石油管道檢測系統。

4、MQTT應用現狀

IBM和St. Jude 醫療中心通過MQTT開發了一套Merlin系統,該系統使用了用于家庭保健的傳感器。St. Jude醫療中心設計了一個叫做[email protected]的心髒裝置,這種無線發射器可以用來監控那些已經植入複律-除顫器和起搏器(兩者都是基本的傳感器)的心髒病人。

該産品利用MQTT把病人的即時更新資訊傳給醫生/醫院,然後醫院進行儲存。這樣的話,病人就不用親自去醫院檢查心髒儀器了,醫生可以随時檢視病人的資料,給出建議,病人在家裡就可以自行檢查。

IBM稱該發射器包括一個大型觸摸屏,一個嵌入式鍵盤平台,以及一個Linux作業系統。

在未來幾年,MQTT的應用會越來越廣,值得關注。

通過MQTT協定,目前已經擴充出了數十個MQTT伺服器端程式,可以通過PHP,JAVA,Python,C,C#等系統語言來向MQTT發送相關消息。

此外,國内很多企業都廣泛使用MQTT作為Android手機用戶端與伺服器端推送消息的協定。其中Sohu,Cmstop手機用戶端中均有使用到MQTT作為消息推送協定。據Cmstop主要負責消息推送的進階研發工程師李文凱稱,随着移動網際網路的發展,MQTT由于開放源代碼,耗電量小等特點,将會在移動消息推送領域有更多的貢獻,在物聯網領域,傳感器與伺服器的通信,資訊的收集,MQTT都可以作為考慮的方案之一。在未來MQTT會進入到我們生活的各各方面。

如果需要下載下傳MQTT伺服器端,可以直接去MQTT官方網站點選software進行下載下傳MQTT協定衍生出來的各個不同版本。

5、MQTT特點

MQTT協定是為大量計算能力有限,且工作在低帶寬、不可靠的網絡的遠端傳感器和控制裝置通訊而設計的協定。

它具有以下主要的幾項特性:

1、使用釋出/訂閱消息模式,提供一對多的消息釋出,解除應用程式耦合:

這一點很類似于XMPP,但是MQTT的資訊備援遠小于XMPP(因為XMPP使用的是XML這種格式來傳遞資料,你懂的)。

2、對負載内容屏蔽的消息傳輸。

3、使用TCP/IP提供網絡連接配接:

主流的MQTT是基于TCP連接配接進行資料推送的,但是同樣有基于UDP的版本,叫做MQTT-SN。這兩種版本由于基于不同的連接配接方式,優缺點自然也就各有不同了。

4、有三種消息釋出服務品質:

[1] “至多一次”,消息釋出完全依賴底層TCP/IP網絡。會發生消息丢失或重複:

這一級别可用于如下情況,環境傳感器資料,丢失一次讀記錄無所謂,因為不久後還會有第二次發送。這一種方式主要普通APP的推送,倘若你的智能裝置在消息推送時未聯網,推送過去沒收到,再次聯網也就收不到了。

[2] “至少一次”,確定消息到達,但消息重複可能會發生:

這一種方式比較雞肋,在我的想象中沒能想到這種品質的發送在正常的APP開發中有什麼用處。

[3] “隻有一次”,確定消息到達一次:

這一級别可用于如下情況,在計費系統中,消息重複或丢失會導緻不正确的結果。這種最高品質的消息釋出服務還可以用于即時通訊類的APP的推送,確定使用者收到且隻會收到一次。

5、小型傳輸,開銷很小(固定長度的頭部是2位元組),協定交換最小化,以降低網絡流量:

這就是為什麼在介紹裡說它非常适合“在物聯網領域,傳感器與伺服器的通信,資訊的收集”,要知道嵌入式裝置的運算能力和帶寬都相對薄弱,使用這種協定來傳遞消息再适合不過了。

6、使用Last Will和Testament特性通知有關各方用戶端異常中斷的機制:

Last Will:即遺言機制,用于通知同一主題下的其他裝置發送遺言的裝置已經斷開了連接配接。

Testament:遺囑機制,功能類似于Last Will 。

6、市面上的主流推送方案應用比較

►[1] APNS(Apple Push Notification Service)和GCM(Google Cloud Messaging) 

APNS和GCM是iOS和Android兩大陣營提出的官方推送方案,這兩者的技術架構較為相似。都是由系統來統一的維護一個長連接配接,所有的APP統一發送心跳和接收推送。

APNS使用的友善性毋庸置疑,但是GCM卻在國内舉步維艱,具體原因有以下三個:

1)Google與我國政府交惡,導緻GMS(Google Mobile Service)在國内無法正常使用,而GCM是依賴于GMS的,是以無法順利使用。

2)由于國内2G和移動3G的NAT逾時時間都小于GCM心跳時間(28分鐘),TCP長連接配接必然無法保活,每次都要等28分鐘心跳失敗重連後才能收到Push。

3)某些營運商可能限制了5228端口,移動3G/2G下,發現幾乎無法連接配接上GCM伺服器,也就無法獲得GCM通知,WhatsApp放背景10分鐘後,經常很長時間都收不到Push消息。

►[2] XMPP

XMPP是一種基于标準通用标記語言的子集XML的協定,它繼承了在XML環境中靈活的發展性。是以,基于XMPP的應用具有超強的可擴充性。經過擴充以後的XMPP可以通過發送擴充的資訊來處理使用者的需求,以及在XMPP的頂端建立如内容釋出系統和基于位址的服務等應用程式。而且,XMPP包含了針對伺服器端的軟體協定,使之能與另一個進行通話,這使得開發者更容易建立客戶應用程式或給一個配好系統添加功能。

XMPP的優點是:協定成熟,強大,可擴充性強,并且有成熟的開源方案。

XMPP的缺點是:資訊備援量大(資訊的格式是 XML),因而費流量,費電。

►[3] MQTT

MQTT的具體概念已經在上面的文字中介紹過了,總結如下:

MQTT的優點是:協定簡潔輕巧,資料備援量低。并且支援的裝置從智能硬體到智能手機無所不包。

MQTT的缺點是:伺服器端實作難度大,雖然已經有了C++版本的服務端元件,但是并不開源。而且在推送數量較大時如何處理并發是十分考驗背景人員的技術水準的。

►[4] HTTP輪詢

HTTP輪詢就是在一個給定的時間間隔後,定時向伺服器發送請求,檢視是否有新的資料。

HTTP輪詢的優點是:實作簡單、可控性強,部署硬體成本低。

HTTP輪詢的缺點是:實時性差,隻有時間到了才會向伺服器檢視是否有新的資料。兩次請求之間的時間間隔過大,則失去了即時推送的意義。但如果設定的時間間隔較短的,又會費電費流量。

►[5] 第三方推送

在推送這一分支領域有許許多多的第三方推送服務,例如:極光,個推等。

優點是:內建友善。

缺點是:大量推送資料後,付費服務是在所難免。而且因為是通用共享雲,是以你的服務品質是否有保證,也就不能要求太多了,必竟你一毛錢也沒出或者也不打算出。

7、結語

林林總總的推送方案大體就這些了,移動裝置主要是針對Androis來說的,對于iOS開發者而言,使用蘋果的APNS�就一步到位了。本文作者的另一篇從理論到實踐講解使用MQTT實作Android推送的Demo文章請見:http://www.52im.net/thread-315-1-1.html。

(本文同步釋出于:http://www.52im.net/thread-318-1-1.html)