背景
近來公司需要做一個即時通訊工具秆吵，選型用MQTT協(xié)議來做。于是仔細(xì)搜集MQTT相關(guān)的了一些資料五慈，并分享出來供大家參考纳寂。
MQTT簡介
MQTT（Message Queuing Telemetry Transport，消息隊(duì)列遙測傳輸）是IBM開發(fā)的一個即時通訊協(xié)議泻拦，它是一種輕量級的毙芜、基于代理的“發(fā)布/訂閱”模式的消息傳輸協(xié)議。其具有協(xié)議簡潔争拐、小巧腋粥、可擴(kuò)展性強(qiáng)晦雨、省流量、省電等優(yōu)點(diǎn)隘冲，而且已經(jīng)有PHP闹瞧，JAVA，Python展辞，C奥邮，C#，Go等多個語言版本罗珍，基本可以使用在任何平臺上洽腺，幾乎可以把所有聯(lián)網(wǎng)物品和外部連接起來，所以特別適合用來當(dāng)做物聯(lián)網(wǎng)的通信協(xié)議覆旱。
MQTT特點(diǎn)
MQTT協(xié)議是為大量計(jì)算能力有限蘸朋，且工作在低帶寬、不可靠的網(wǎng)絡(luò)的遠(yuǎn)程傳感器和控制設(shè)備通訊而設(shè)計(jì)的協(xié)議扣唱，它具有以下主要的幾項(xiàng)特性：
- 使用發(fā)布/訂閱消息模式藕坯，提供一對多的消息發(fā)布，解除應(yīng)用程序耦合画舌；
- 對負(fù)載內(nèi)容屏蔽的消息傳輸堕担；
- 使用 TCP/IP 提供網(wǎng)絡(luò)連接；
- 有三種消息發(fā)布服務(wù)質(zhì)量：
- “至多一次”曲聂，消息發(fā)布完全依賴底層 TCP/IP 網(wǎng)絡(luò)。會發(fā)生消息丟失或重復(fù)佑惠。這一級別可用于如下情況朋腋，環(huán)境傳感器數(shù)據(jù)，丟失一次讀記錄無所謂膜楷，因?yàn)椴痪煤筮€會有第二次發(fā)送旭咽。
- “至少一次”，確保消息到達(dá)赌厅，但消息重復(fù)可能會發(fā)生穷绵。
- “只有一次”，確保消息到達(dá)一次特愿。這一級別可用于如下情況仲墨，在計(jì)費(fèi)系統(tǒng)中，消息重復(fù)或丟失會導(dǎo)致不正確的結(jié)果揍障。
- 小型傳輸目养，開銷很小（固定長度的頭部是 2 字節(jié)）毒嫡，協(xié)議交換最小化癌蚁，以降低網(wǎng)絡(luò)流量；
- 使用 Last Will 和 Testament 特性通知有關(guān)各方客戶端異常中斷的機(jī)制；
MQTT協(xié)議特征
-
消息模型
MQTT是一種基于代理的發(fā)布/訂閱的消息協(xié)議努释。提供一對多的消息分發(fā)碘梢，解除應(yīng)用程序耦合。一個發(fā)布者可以對應(yīng)多個訂閱者伐蒂，當(dāng)發(fā)布者發(fā)生變化的時候煞躬，他可以將消息一一通知給所有的訂閱者。這種模式提供了更大的網(wǎng)絡(luò)擴(kuò)展性和更動態(tài)的網(wǎng)絡(luò)拓?fù)洹?br>MQTT 消息傳輸模型
-
消息質(zhì)量
MQTT提供三種質(zhì)量的服務(wù)：- 至多一次饿自，可能會出現(xiàn)丟包的現(xiàn)象汰翠。使用在對實(shí)時性要求不高的情況。這一級別可應(yīng)用于如下情景昭雌，如環(huán)境傳感器數(shù)據(jù)复唤，丟失一次讀記錄無所謂，因?yàn)楹芸煜乱淮巫x記錄就會產(chǎn)生烛卧。
- 至少一次佛纫，保證包會到達(dá)目的地，但是可能出現(xiàn)重包总放。
- 正好一次呈宇，保證包會到達(dá)目的地，且不會出現(xiàn)重包的現(xiàn)象局雄。這一級別可用于如計(jì)費(fèi)系統(tǒng)等場景甥啄，在計(jì)費(fèi)系統(tǒng)中，消息丟失或重復(fù)可能會導(dǎo)致生成錯誤的費(fèi)用炬搭。
-
主題名稱
主題名稱（Topic name）用來標(biāo)識已發(fā)布消息的信息的渠道蜈漓。訂閱者用它來確定接收到所關(guān)心的信息。它是一個分層的結(jié)構(gòu)宫盔，用斜線“/”作為分隔符融虽。有兩種通配符可以在主題發(fā)布、訂閱時使用：“#”和“+”灼芭。前者可以通配多層結(jié)構(gòu)有额，而后者只能通配一層結(jié)構(gòu)。例如一個topic ： “a/b/c”,則“a/+/c”和“a/#”都可以和它相等彼绷。發(fā)布不支持模糊匹配巍佑，必須是確定的主題。 -
遺屬
當(dāng)一個客戶端斷開連接的時候苛预，它希望客戶端可以發(fā)送它指定的消息句狼。該消息和普通消息的結(jié)構(gòu)相同。通過設(shè)置該位并填入和信息相關(guān)的內(nèi)容即可热某。 - 消息類型
| 消息類型 | 類型編碼 | 說明 |
|---|---|---|
| reserved | 0 | 保留 |
| connect | 1 | 客戶端到服務(wù)端的連接請求 |
| connACK | 2 | 服務(wù)端對連接請求的響應(yīng) |
| publish | 3 | 發(fā)布消息 |
| puback | 4 | 對發(fā)布消息的回應(yīng) |
| pubRec | 5 | 收到發(fā)布消息（保證傳輸part1） |
| pubRel | 6 | 釋放發(fā)布消息（保證傳輸part2） |
| pubComp | 7 | 完成發(fā)布消息（保證傳輸part3） |
| subscribe | 8 | 客戶端訂閱請求 |
| subBack | 9 | 訂閱請求的回應(yīng) |
| unsubscribe | 10 | 停止訂閱請求 |
| unsubBack | 11 | 停止訂閱請求響應(yīng) |
| pingReq | 12 | Ping請求（保持連接） |
| pingResp | 13 | Ping響應(yīng) |
| disconnect | 14 | 客戶端正在斷開 |
| reserved | 15 | 保留 |
開發(fā)一個MQTT庫需要提供如下命令：
Connect ：當(dāng)一個TCP/IP套接字在服務(wù)器端和客戶端連接建立時需要使用的命令腻菇。
publish ： 是由客戶端向服務(wù)端發(fā)送胳螟，告訴服務(wù)器端自己感興趣的Topic。每一個publishMessage 都會與一個Topic的名字聯(lián)系在一起筹吐。
pubRec: 是publish命令的響應(yīng)糖耸，只不過使用了2級QoS協(xié)議。它是2級QoS協(xié)議的第二條消息
pubRel: 是2級QoS協(xié)議的第三條消息
publComp: 是2級QoS協(xié)議的第四條消息
subscribe： 允許一個客戶端注冊自已感興趣的Topic 名字丘薛，發(fā)布到這些Topic的消息會以publish Message的形式由服務(wù)器端發(fā)送給客戶端嘉竟。
unsubscribe: 從客戶端到服務(wù)器端，退訂一個Topic洋侨。
Ping： 有客戶端向服務(wù)器端發(fā)送的“are you alive”的消息舍扰。
disconnect：斷開這個TCP/IP協(xié)議。
MQTT服務(wù)端和客戶端
MQTT協(xié)議服務(wù)端：https://github.com/mqtt/mqtt.github.io/wiki/servers
MQTT協(xié)議類庫：https://github.com/mqtt/mqtt.github.io/wiki/libraries
MQTT協(xié)議官網(wǎng)：http://mqtt.org/
應(yīng)用場景
推送
再給大家普及下“推送”這個概念希坚，推送這個詞大部分人都會有印象的边苹。比如PC端的推送廣告，比如安卓的推送服務(wù)裁僧，還有一些即時通信軟件如微信个束、易信等也是采用的推送技術(shù)。
現(xiàn)在的推送實(shí)現(xiàn)的方式已經(jīng)非常多了聊疲，主流的有C2DM服務(wù)（Google Cloud Messaging）茬底，基于XML協(xié)議的通訊協(xié)議XMPP協(xié)議（Openfire + Spark + Smack）, 輕量級的、基于代理的“發(fā)布/訂閱”模式的消息傳輸協(xié)議MQTT協(xié)議获洲，還可以通過嵌入SDK使用第三方提供的推送服務(wù)阱表，如百度云推送、極光推送贡珊、智游推送捶枢、騰訊信鴿等。
推送利用的也是類似于上面提到的代理技術(shù)飞崖，從而將數(shù)據(jù)源源不斷地推向客戶機(jī)。筆者對其它協(xié)議了解不多所以也不敢多做妄言谨胞，但是現(xiàn)在國內(nèi)很多企業(yè)都已經(jīng)廣泛使用MQTT作為Android手機(jī)客戶端與服務(wù)器端推送消息的協(xié)議固歪。其中Sohu，Cmstop手機(jī)客戶端中均有使用到MQTT作為消息推送消息胯努。
