MQTT 全稱爲 Message Queuing Telemetry Transport（消息隊列遙測傳輸）是一種基於發佈/訂閱範式的“輕量級”消息協議，由 IBM 發佈。
1.MQTT是一種發佈/訂閱傳輸協議
主要有三種身份：發佈者（Publisher）、代理（Broker，服務器）、訂閱者（Subscriber）。其中，消息的發佈者和訂閱者都是客戶端，消息代理是服務器，而消息發佈者可以同時是訂閱者，實現了生產者與消費者的脫耦。
2.使用 TCP/IP 提供網絡連接，提供有序、無損、雙向連接
3.對負載內容屏蔽的消息傳輸；
4.具體有三種消息發佈的服務質量：
- 至多一次，消息發佈完全依賴底層 TCP/IP 網絡。會發生消息丟失或重複。這一級別可用於如下情況，環境傳感器數據，丟失一次讀記錄無所謂，因爲不久後還會有第二次發送。
- 至少一次，確保消息到達，但消息重複可能會發生。
- 只有一次，確保消息到達一次。這一級別可用於如下情況，在計費系統中，消息重複或丟失會導致不正確的結果。
5.小型傳輸，開銷小，固定長度的頭部是 2 字節，協議交換最小化，以降低網絡流量；
6.使用Last Will和Testament特性通知有關各方客戶端異常中斷的機制；
Last Will：即遺言機制，用於通知同一主題下的其他設備發送遺言的設備已經斷開了連接。
Testament：遺囑機制，功能類似於Last Will。
假設現在有一個物聯網的應用，題主當然可以直接用TCP socket 做通信，實際上不少人也是這麼做的。然後你就會發現：
* 需要自己寫確認重傳的機制，因爲TCP 連接說不定就斷了。
* 如果有很多個傳感器（生產者），又要寫代碼管理這麼多TCP連接呢。
* 如果同時又有多個地方需要用到這些數據，還得寫一個轉發的邏輯。
* 如果系統很複雜，參與人或公司很多，那通信格式要怎麼定，怎麼改，溝通成本就很大了。
這些東西這麼麻煩，又不想加班寫代碼，那有沒有辦法簡便地解決呢？當然有，就是用現成的協議啦，比如MQTT。
MQTT 提供兩個核心功能：
* 三個級別的QOS
QoS 0：“最多一次”，消息發佈完全依賴底層 TCP/IP 網絡。分發的消息可能丟失或重複。例如，這個等級可用於環境傳感器數據，單次的數據丟失沒關係，因爲不久後還會有第二次發送。
QoS 1：“至少一次”，確保消息可以到達，但消息可能會重複。
QoS 2：“只有一次”，確保消息只到達一次。例如，這個等級可用在一個計費系統中，這裏如果消息重複或丟失會導致不正確的收費。
*基於訂閱/發佈的消息轉發服務。
用了MQTT, 上面提到的這些問題就都被優雅地解決掉啦。