https://www.douban.com/group/topic/87228054/
來自:
Loly 2016-06-08 17:47:08
MQTT（Message Queuing Telemetry Transport，消息隊列遙測傳輸）是IBM開發(fā)的一個即時通訊協(xié)議，有可能成為物聯(lián)網(wǎng)的重要組成部分。該協(xié)議支持所有平臺，幾乎可以把所有聯(lián)網(wǎng)物品和外部連接起來，被用來當(dāng)做傳感器和致動器（比如通過Twitter讓房屋聯(lián)網(wǎng)）的通信協(xié)議。
MQTT協(xié)議技術(shù)文檔：點此進入，當(dāng)然也有PDF版的，百度一下，不過個人感覺不是官網(wǎng)上的字體和排版最舒服。
MQTT是輕量級基于代理的發(fā)布/訂閱的消息傳輸協(xié)議，它可以通過很少的代碼和帶寬和遠(yuǎn)程設(shè)備連接。例如通過衛(wèi)星和代理連接，通過撥號和醫(yī)療保健提供者連接，以及在一些自動化或小型設(shè)備上，而且由于小巧，省電，協(xié)議開銷小和能高效的向一和多個接收者傳遞信息，故同樣適用于稱動應(yīng)用設(shè)備上。
相信在想深入學(xué)習(xí)這個協(xié)議必是奔著解決某個問題而來的，上面給出了適用的場景，我之所以想深入的學(xué)習(xí)和了解這個協(xié)議，理由如下：
可以實現(xiàn)手機消息推送（PUSH）
協(xié)議簡單，最小的頭部只需2個字節(jié)，特別適合于嵌入式設(shè)備場景中。
這是個了解什么是協(xié)議絕好的例子。相比于其它復(fù)雜的協(xié)議例如tcp、http協(xié)議，至少說明文檔看的下去。
【更多資料】
《一個基于MQTT通信協(xié)議的完整Android推送Demo [附件下載]》：
http://www.52im.net/forum.php?mod=viewthread&tid=315&;ctid=11《求教android消息推送：GCM、XMPP、MQTT三種方案的優(yōu)劣》：
http://www.52im.net/forum.php?mod=viewthread&tid=314&;ctid=11《移動端實時消息推送技術(shù)淺析》：
http://www.52im.net/forum.php?mod=viewthread&tid=288&;ctid=11《絕對干貨：基于Netty實現(xiàn)海量接入的推送服務(wù)技術(shù)要點》：
http://www.52im.net/forum.php?mod=viewthread&tid=166&;ctid=11《開源免費的實時信息推送服務(wù)器DDPush介紹》：
http://www.52im.net/forum.php?mod=viewthread&tid=32&ctid=11（更多文章請進入：
http://www.52im.net/forum.php?mod=collection&action=view&ctid=11）
【MQTT簡介】
早在1999年，IBM的Andy Stanford-Clark博士以及Arcom公司ArlenNipper博士發(fā)明了MQTT（Message Queuing Telemetry Transport，消息隊列遙測傳輸）技術(shù) 。
MQTT的話題是他們在談?wù)撻_源物聯(lián)網(wǎng)平臺Pachube時提到的。Stanford-Clark認(rèn)為Pachube很酷，其不足之處是不具備真正的推送功能。你需要不斷的進行輪詢才能得到即時數(shù)據(jù)。這正是MQTT能夠?qū)崿F(xiàn)的，他提到了使用推送通信系統(tǒng)的石油管道檢測系統(tǒng)。
MQTT應(yīng)用現(xiàn)狀
IBM和St. Jude 醫(yī)療中心通過MQTT開發(fā)了一套Merlin系統(tǒng)，該系統(tǒng)使用了用于家庭保健的傳感器。St. Jude醫(yī)療中心設(shè)計了一個叫做Merlin@home的心臟裝置，這種無線發(fā)射器可以用來監(jiān)控那些已經(jīng)植入復(fù)律-除顫器和起搏器（兩者都是基本的傳感器）的心臟病人。
該產(chǎn)品利用MQTT把病人的即時更新信息傳給醫(yī)生/醫(yī)院，然后醫(yī)院進行保存。這樣的話，病人就不用親自去醫(yī)院檢查心臟儀器了，醫(yī)生可以隨時查看病人的數(shù)據(jù)，給出建議，病人在家里就可以自行檢查。
IBM稱該發(fā)射器包括一個大型觸摸屏，一個嵌入式鍵盤平臺，以及一個Linux操作系統(tǒng)。
在未來幾年，MQTT的應(yīng)用會越來越廣，值得關(guān)注。
通過MQTT協(xié)議，目前已經(jīng)擴展出了數(shù)十個MQTT服務(wù)器端程序，可以通過PHP，JAVA，Python，C，C#等系統(tǒng)語言來向MQTT發(fā)送相關(guān)消息。
此外，國內(nèi)很多企業(yè)都廣泛使用MQTT作為Android手機客戶端與服務(wù)器端推送消息的協(xié)議。其中Sohu，Cmstop手機客戶端中均有使用到MQTT作為消息推送協(xié)議。據(jù)Cmstop主要負(fù)責(zé)消息推送的高級研發(fā)工程師李文凱稱，隨著移動互聯(lián)網(wǎng)的發(fā)展，MQTT由于開放源代碼，耗電量小等特點，將會在移動消息推送領(lǐng)域有更多的貢獻，在物聯(lián)網(wǎng)領(lǐng)域，傳感器與服務(wù)器的通信，信息的收集，MQTT都可以作為考慮的方案之一。在未來MQTT會進入到我們生活的各各方面。
如果需要下載MQTT服務(wù)器端，可以直接去MQTT官方網(wǎng)站點擊software進行下載MQTT協(xié)議衍生出來的各個不同版本。
【MQTT特點】
MQTT協(xié)議是為大量計算能力有限，且工作在低帶寬、不可靠的網(wǎng)絡(luò)的遠(yuǎn)程傳感器和控制設(shè)備通訊而設(shè)計的協(xié)議。
它具有以下主要的幾項特性：
1、使用發(fā)布/訂閱消息模式，提供一對多的消息發(fā)布，解除應(yīng)用程序耦合：
這一點很類似于XMPP，但是MQTT的信息冗余遠(yuǎn)小于XMPP（因為XMPP使用的是XML這種格式來傳遞數(shù)據(jù)，你懂的）。
2、對負(fù)載內(nèi)容屏蔽的消息傳輸。
3、使用TCP/IP提供網(wǎng)絡(luò)連接：
主流的MQTT是基于TCP連接進行數(shù)據(jù)推送的，但是同樣有基于UDP的版本，叫做MQTT-SN。這兩種版本由于基于不同的連接方式，優(yōu)缺點自然也就各有不同了。
4、有三種消息發(fā)布服務(wù)質(zhì)量：
“至多一次”，消息發(fā)布完全依賴底層TCP/IP網(wǎng)絡(luò)。會發(fā)生消息丟失或重復(fù)：
這一級別可用于如下情況，環(huán)境傳感器數(shù)據(jù)，丟失一次讀記錄無所謂，因為不久后還會有第二次發(fā)送。這一種方式主要普通APP的推送，倘若你的智能設(shè)備在消息推送時未聯(lián)網(wǎng)，推送過去沒收到，再次聯(lián)網(wǎng)也就收不到了。
“至少一次”，確保消息到達(dá)，但消息重復(fù)可能會發(fā)生：
這一種方式比較雞肋，在我的想象中沒能想到這種質(zhì)量的發(fā)送在常規(guī)的APP開發(fā)中有什么用處。
“只有一次”，確保消息到達(dá)一次：
這一級別可用于如下情況，在計費系統(tǒng)中，消息重復(fù)或丟失會導(dǎo)致不正確的結(jié)果。這種最高質(zhì)量的消息發(fā)布服務(wù)還可以用于即時通訊類的APP的推送，確保用戶收到且只會收到一次。
5、小型傳輸，開銷很?。ü潭ㄩL度的頭部是2字節(jié)），協(xié)議交換最小化，以降低網(wǎng)絡(luò)流量：
這就是為什么在介紹里說它非常適合“在物聯(lián)網(wǎng)領(lǐng)域，傳感器與服務(wù)器的通信，信息的收集”，要知道嵌入式設(shè)備的運算能力和帶寬都相對薄弱，使用這種協(xié)議來傳遞消息再適合不過了。
6、使用Last Will和Testament特性通知有關(guān)各方客戶端異常中斷的機制：
Last Will：即遺言機制，用于通知同一主題下的其他設(shè)備發(fā)送遺言的設(shè)備已經(jīng)斷開了連接。
Testament：遺囑機制，功能類似于Last Will 。
【市面上的主流推送方案應(yīng)用比較】
1APNS（Apple Push Notification Service）和GCM（Google Cloud Messaging）
APNS和GCM是iOS和Android兩大陣營提出的官方推送方案，這兩者的技術(shù)架構(gòu)較為相似。都是由系統(tǒng)來統(tǒng)一的維護一個長連接，所有的APP統(tǒng)一發(fā)送心跳和接收推送。
APNS使用的方便性毋庸置疑，但是GCM卻在國內(nèi)舉步維艱，具體原因有以下三個：
Google與我國政府交惡，導(dǎo)致GMS（Google Mobile Service）在國內(nèi)無法正常使用，而GCM是依賴于GMS的，所以無法順利使用。
由于國內(nèi)2G和移動3G的NAT超時時間都小于GCM心跳時間(28分鐘)，TCP長連接必然無法?；?，每次都要等28分鐘心跳失敗重連后才能收到Push。
某些運營商可能限制了5228端口，移動3G/2G下，發(fā)現(xiàn)幾乎無法連接上GCM服務(wù)器，也就無法獲得GCM通知，WhatsApp放后臺10分鐘后，經(jīng)常很長時間都收不到Push消息。
2XMPP
XMPP是一種基于標(biāo)準(zhǔn)通用標(biāo)記語言的子集XML的協(xié)議，它繼承了在XML環(huán)境中靈活的發(fā)展性。因此，基于XMPP的應(yīng)用具有超強的可擴展性。經(jīng)過擴展以后的XMPP可以通過發(fā)送擴展的信息來處理用戶的需求，以及在XMPP的頂端建立如內(nèi)容發(fā)布系統(tǒng)和基于地址的服務(wù)等應(yīng)用程序。而且，XMPP包含了針對服務(wù)器端的軟件協(xié)議，使之能與另一個進行通話，這使得開發(fā)者更容易建立客戶應(yīng)用程序或給一個配好系統(tǒng)添加功能。
XMPP的優(yōu)點是：協(xié)議成熟，強大，可擴展性強，并且有成熟的開源方案。
XMPP的缺點是：信息冗余量大（信息的格式是 XML），因而費流量，費電。
3MQTT
MQTT的具體概念已經(jīng)在上面的文字中介紹過了，總結(jié)如下：
MQTT的優(yōu)點是：協(xié)議簡潔輕巧，數(shù)據(jù)冗余量低。并且支持的設(shè)備從智能硬件到智能手機無所不包。
MQTT的缺點是：服務(wù)器端實現(xiàn)難度大，雖然已經(jīng)有了C++版本的服務(wù)端組件，但是并不開源。而且在推送數(shù)量較大時如何處理并發(fā)是十分考驗后臺人員的技術(shù)水平的。
4HTTP輪詢
HTTP輪詢就是在一個給定的時間間隔后，定時向服務(wù)器發(fā)送請求，查看是否有新的數(shù)據(jù)。
HTTP輪詢的優(yōu)點是：實現(xiàn)簡單、可控性強，部署硬件成本低。
HTTP輪詢的缺點是：實時性差，只有時間到了才會向服務(wù)器查看是否有新的數(shù)據(jù)。兩次請求之間的時間間隔過大，則失去了即時推送的意義。但如果設(shè)置的時間間隔較短的，又會費電費流量。
5第三方推送
在推送這一分支領(lǐng)域有許許多多的第三方推送服務(wù)，例如：極光，個推等。
優(yōu)點是：集成方便。
缺點是：大量推送數(shù)據(jù)后，付費服務(wù)是在所難免。而且因為是通用共享云，所以你的服務(wù)質(zhì)量是否有保證，也就不能要求太多了，必竟你一毛錢也沒出或者也不打算出。
【結(jié)語】
林林總總的推送方案大體就這些了，移動設(shè)備主要是針對Androis來說的，對于iOS開發(fā)者而言，使用蘋果的APNS就一步到位了。即時通訊網(wǎng)的另一篇從理論到實踐講解使用MQTT實現(xiàn)Android推送的Demo文章請見：
http://www.52im.net/thread-315-1-1.html。
（
http://www.52im.net/thread-318-1-1.html）
