MQTT（MessageQueueing Telemetry Transport Protocol）的全稱是消息隊列遙感傳輸協議的縮寫，是由IBM公司推出的壹種基於輕量級代理的發布/訂閱模式的消息傳輸協議，運行在TCP協議棧之上，為其提供有序、可靠、雙向連接的網絡連接保證。由於其開放、簡單和易於實現所以能夠應用在資源受限的環境中，對於M2M和物聯網應用程序來說是壹個相當不錯的選擇。
2、 為什麽要用MQTT？
MQTT協議是針對如下情況設計的：
M2M（Machine to Machine） communication，機器端到端通信，比如傳感器之間的數據通訊 因為是Machine to Machine，需要考慮： Machine，或者叫設備，比如溫度傳感器，硬件能力很弱，協議要考慮盡量小的資源消耗，比如計算能力和存儲等 M2M可能是無線連接，網絡不穩定，帶寬也比較小
MQTT的特點:
發布/訂閱消息模式，提供壹對多的消息發布，解除應用程序耦合。這壹點很類似於1. 這裏是列表文本XMPP，但是MQTT的信息冗余遠小於XMPP.
對負載內容屏蔽的消息傳輸。
使用TCP/IP提供網絡連接。主流的MQTT是基於TCP連接進行數據推送的，但是同樣有基於UDP的版本，叫做MQTT-SN。這兩種版本由於基於不同的連接方式，優缺點自然也就各有不同了。
三種消息傳輸方式QoS：
0代表“至多壹次”，消息發布完全依賴底層 TCP/IP 網絡。會發生消息丟失或重復。這壹級別可用於如下情況，環境傳感器數據，丟失壹次讀記錄無所謂，因為不久後還會有第二次發送。
1代表“至少壹次”，確保消息到達，但消息重復可能會發生。
2代表“只有壹次”，確保消息到達壹次。這壹級別可用於如下情況，在計費系統中，消息重復或丟失會導致不正確的結果。 備註：由於服務端采用Mosca實現，Mosca目前只支持到QoS 1
如果發送的是臨時的消息，例如給某topic所有在線的設備發送壹條消息，丟失的話也無所謂，0就可以了（客戶端登錄的時候要指明支持的QoS級別，同時發送消息的時候也要指明這條消息支持的QoS級別），如果需要客戶端保證能接收消息，需要指定QoS為1，如果同時需要加入客戶端不在線也要能接收到消息，那麽客戶端登錄的時候要指定session的有效性，接收離線消息需要指定服務端要保留客戶端的session狀態。
mqtt基於訂閱者模型架構，客戶端如果互相通信，必須在同壹訂閱主題下，即都訂閱了同壹個topic，客戶端之間是沒辦法直接通訊的。訂閱模型顯而易見的好處是群發消息的話只需要發布到topic，所有訂閱了這個topic的客戶端就可以接收到消息了。
發送消息必須發送到某個topic，重點說明的是不管客戶端是否訂閱了該topic都可以向topic發送了消息，還有如果客戶端訂閱了該主題，那麽自己發送的消息也會接收到。
小型傳輸，開銷很小（固定長度的頭部是2字節），協議交換最小化，以降低網絡流量。這就是為什麽在介紹裏說它非常適合“在物聯網領域，傳感器與服務器的通信，信息的收集”，要知道嵌入式設備的運算能力和帶寬都相對薄弱，使用這種協議來傳遞消息再適合不過了。
使用Last Will和Testament特性通知有關各方客戶端異常中斷的機制。Last Will：即遺言機制，用於通知同壹主題下的其他設備發送遺言的設備已經斷開了連接。Testament：遺囑機制，功能類似於Last Will 。