一、消息模型：
MQTT是一種基於代理的發佈/訂閱的消息協議。提供一對多的消息分發，解除應用程序耦合。一個發佈者能夠對應多個訂閱者，當發佈者發生變化的時候，他能夠將消息一一通知給全部的訂閱者。這種模式提供了更大的網絡擴展性和更動態的網絡拓撲。 
git
二、消息質量
MQTT提供三種質量的服務：
1）至多一次，可能會出現丟包的現象。使用在對實時性要求不高的狀況。這一級別可應用於以下情景，如環境傳感器數據，丟失一次讀記錄無所謂，由於很快下一次讀記錄就會產生。github
2）至少一次，保證包會到達目的地，可是可能出現重包。服務器
3）正好一次，保證包會到達目的地，且不會出現重包的現象。這一級別可用於如計費系統等場景，在計費系統中，消息丟失或重複可能會致使生成錯誤的費用。網絡
三、主題名稱
主題名稱（Topic name）用來標識已發佈消息的信息的渠道。訂閱者用它來肯定接收到所關心的信息。它是一個分層的結構，用斜線「/」做爲分隔符。有兩種通配符能夠在主題發佈、訂閱時使用：「#」和「+」。前者能夠通配多層結構，然後者只能通配一層結構。例如一個topic ： 「a/b/c」,則「a/+/c」和「a/#」均可以和它相等。發佈不支持模糊匹配，必須是肯定的主題。spa
四、遺屬代理
當一個客戶端斷開鏈接的時候，它但願客戶端能夠發送它指定的消息。該消息和普通消息的結構相同。經過設置該位並填入和信息相關的內容便可。server
六、消息類型blog
| 名字 | 值 | 流動方向 | 描述 |
|---|---|---|---|
| Reserved | 0 | 禁止 | 保留 |
| Connect | 1 | 客戶端到服務端 | 客戶端到服務端的鏈接請求 |
| ConnACK | 2 | 服務端到客戶端 | 服務端對鏈接請求的響應 |
| Publish | 3 | 兩個方向都容許 | 發佈消息（QoS0） |
| puback | 4 | 兩個方向都容許 | 對QoS1發佈消息的迴應 |
| pubRec | 5 | 兩個方向都容許 | 收到發佈消息（QoS2保證傳輸第一步） |
| pubRel | 6 | 兩個方向都容許 | 釋放發佈消息（QoS2保證傳輸第二步） |
| pubComp | 7 | 兩個方向都容許 | 完成發佈消息（QoS2保證傳輸第三步） |
| subscribe | 8 | 客戶端到服務端 | 客戶端訂閱請求 |
| subBack | 9 | 服務端到客戶端 | 訂閱請求的確認 |
| unsubscribe | 10 | 客戶端到服務端 | 客戶端取消訂閱請求 |
| unsubBack | 11 | 服務端到客戶端 | 取消訂閱請求確認 |
| pingReq | 12 | 客戶端到服務端 | Ping（心跳）請求（保持鏈接） |
| pingResp | 13 | 服務端到客戶端 | Ping（心跳）響應 |
| disconnect | 14 | 客戶端到服務端 | 客戶端斷開鏈接 |
| reserved | 15 | 禁止 | 保留 |
開發一個MQTT庫須要提供以下命令：開發
Connect ：當一個TCP/IP套接字在服務器端和客戶端鏈接創建時須要使用的命令。get
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協議
三、MQTT服務端和客戶端