1、前沿
萬物聯網的時代即將到來，物聯網也由當初的概念開始進一步落實。隨着無線網絡技術飛速發展，各種設備都可以連接網絡，實現遠程控制。例如智能家居最近非常火爆，智能插座、智能LED燈、智能攝像頭等。在互聯網時代，HTTP協議負責建立網絡連接，而到了物聯網時代，由於智能硬件的差異，相比互聯網終端，硬件配置要低的多，而且智能設備的環境也想多復雜，物聯網中的數據傳輸會面臨很多問題，比如在網絡不穩定的情況下，如果保證數據的傳輸沒有問題，如何保證數據不被重復發送，連接斷開后如何進行重連，而HTTP協議由於太重量級了，不是適合物聯網。因此IBM公司為此提出一種輕量級的MQTT協議（MQ Telemetry Transport），適合於低帶寬、不可靠連接、嵌入式設備、CPU、內存資源緊張，適用於各種受限的環境。
2、協議特征
（1）消息模型
MQTT是一種基於代理的發布/訂閱的消息協議。提供一對多的消息分發，解除應用程序耦合。一個發布者可以對應多個訂閱者，當發布者發生變化的時候，他可以將消息一一通知給所有的訂閱者。這種模式提供了更大的網絡擴展性和更動態的網絡拓撲。
（2）消息質量
MQTT提供三種質量的服務：
1）至多一次，可能會出現丟包的現象。使用在對實時性要求不高的情況。這一級別可應用於如下情景，如環境傳感器數據，丟失一次讀記錄無所謂，因為很快下一次讀記錄就會產生。
2）至少一次，保證包會到達目的地，但是可能出現重包。
3）正好一次，保證包會到達目的地，且不會出現重包的現象。這一級別可用於如計費系統等場景，在計費系統中，消息丟失或重復可能會導致生成錯誤的費用。
（3）主題名稱
主題名稱（Topic name）用來標識已發布消息的信息的渠道。訂閱者用它來確定接收到所關心的信息。它是一個分層的結構，用斜線“/”作為分隔符。有兩種通配符可以在主題發布、訂閱時使用：“#”和“+”。前者可以通配多層結構，而后者只能通配一層結構。例如一個topic ： “a/b/c”,則“a/+/c”和“a/#”都可以和它相等。發布不支持模糊匹配，必須是確定的主題。
（4）遺屬
當一個客戶端斷開連接的時候，它希望客戶端可以發送它指定的消息。該消息和普通消息的結構相同。通過設置該位並填入和信息相關的內容即可。
（5）消息類型
| Reserved | 0 | 保留 |
| Connect | 1 | 客戶端到服務端的連接請求 |
| ConnACK | 2 | 服務端對連接請求的響應 |
| Publish | 3 | 發布消息 |
| puback | 4 | 對發布消息的回應 |
| pubRec | 5 | 收到發布消息（保證傳輸part1） |
| pubRel | 6 | 釋放發布消息（保證傳輸part2） |
| pubComp | 7 | 完成發布消息（保證傳輸part3） |
| subscribe | 8 | 客戶端訂閱請求 |
| subBack | 9 | 訂閱請求的回應 |
| unsubscribe | 10 | 停止訂閱請求 |
| unsubBack | 11 | 停止訂閱請求響應 |
| pingReq | 12 | Ping請求（保持連接） |
| pingResp | 13 | Ping響應 |
| disconnect | 14 | 客戶端正在斷開 |
| reserved | 15 | 保留 |
開發一個MQTT庫需要提供如下命令：
Connect ：當一個TCP/IP套接字在服務器端和客戶端連接建立時需要使用的命令。
publish ： 是由客戶端向服務端發送，告訴服務器端自己感興趣的Topic。每一個publishMessage 都會與一個Topic的名字聯系在一起。
pubRec: 是publish命令的響應，只不過使用了2級QoS協議。它是2級QoS協議的第二條消息
pubRel: 是2級QoS協議的第三條消息
publComp: 是2級QoS協議的第四條消息
subscribe： 允許一個客戶端注冊自已感興趣的Topic 名字，發布到這些Topic的消息會以publish Message的形式由服務器端發送給客戶端。
unsubscribe: 從客戶端到服務器端，退訂一個Topic。
Ping： 有客戶端向服務器端發送的“are you alive”的消息。
disconnect：斷開這個TCP/IP協議
3、MQTT服務端和客戶端
https://github.com/mqtt/mqtt.github.io/wiki/servers
https://github.com/mqtt/mqtt.github.io/wiki/libraries
MQTT協議官網：http://mqtt.org/