前言：
MQTT中文官網地址：http://mqtt.p2hp.com/mqtt-5-0
一：什么是Mqtt
答：MQTT是一個客戶端服務端架構的發布/訂閱模式的消息傳輸協議。它的設計思想是輕巧、開放、簡單、規范，因此易於實現。這些特點使得它對很多場景來說都是很好的選擇，包括受限的環境如機器與機器的通信（M2M）以及物聯網環境（IoT），這些場景要求很小的代碼封裝或者網絡帶寬非常昂貴。
本協議運行在TCP/IP，或其它提供了有序、可靠、雙向連接的網絡連接上。它有以下特點：
1.使用發布/訂閱消息模式，提供了一對多的消息分發和應用之間的解耦。
2.消息傳輸不需要知道負載內容。
3。提供三種等級的服務質量：
（1）“最多一次”，盡操作環境所能提供的最大努力分發消息。消息可能會丟失。例如，這個等級可用於環境傳感器數據，單次的數據丟失沒關系，因為不久之后會再次發送。
（2）“至少一次”，保證消息可以到達，但是可能會重復。
（3）“僅一次”，保證消息只到達一次。例如，這個等級可用在一個計費系統中，這里如果消息重復或丟失會導致不正確的收費。
4.很小的傳輸消耗和協議數據交換，最大限度減少網絡流量。
5.異常連接斷開發生時，能通知到相關各方。
二：Mqtt中的關鍵字
答：本規范中用到的關鍵字 必須 MUST，不能 MUST NOT，要求 REQUIRED，將會 SHALL，不會 SHALL NOT，應該 SHOULD，不應該 SHOULD NOT，推薦 RECOMMENDED，可以 MAY，可選 OPTIONAL 都是按照 IETF RFC 2119 [RFC2119] 中的描述解釋。
三：Mqtt術語
答：應用消息 Application Message MQTT協議通過網絡傳輸應用數據。應用消息通過MQTT傳輸時，它們有關聯的服務質量（QoS）和主題（Topic）。
客戶端 Client
使用MQTT的程序或設備。客戶端總是通過網絡連接到服務端。它可以
- 打開連接到服務端的網絡連接
- 發布應用消息給其它相關的客戶端
- 訂閱以請求接受相關的應用消息
- 取消訂閱以移除接受應用消息的請求
- 關閉連接到服務端的網絡連接
服務端 Server
一個程序或設備，作為發送消息的客戶端和請求訂閱的客戶端之間的中介。服務端
- 接受來自客戶端的網絡連接
- 接受客戶端發布的應用消息
- 處理客戶端的訂閱和取消訂閱請求
- 轉發應用消息給符合條件的已訂閱客戶端
- 關閉來自客戶端的網絡連接
會話 Subscription
客戶端和服務端之間的狀態交互。一些會話持續時長與網絡連接一樣，另一些可以在客戶端和服務端的多個連續網絡連接間擴展。
訂閱 Subscription
訂閱包含一個主題過濾器（Topic Filter）和一個最大的服務質量（QoS）等級。訂閱與單個會話（Session）關聯。會話可以包含多於一個的訂閱。會話的每個訂閱都有一個不同的主題過濾器。
共享訂閱 Shared Subscription
一個共享訂閱包含一個主題過濾器（Topic Filter）和一個最大的服務質量（QoS）等級。一個共享訂閱可以與多個訂閱會話相關聯，便於支持大范圍消息交換模式。一條主題匹配的應用消息只發送給關聯到此共享訂閱的多個會話中的一個會話。一個會話可以包括多個共享訂閱，可以同時包含共享訂閱與非共享訂閱。
通配符訂閱 Wildcard Subscription
通配符訂閱是指主題過濾器（Topic Filter）包含一個或多個通配符的訂閱。通配符訂閱使得一次訂閱匹配多個主題名（Topic Name）。4.7節 描述了主題過濾器中的通配符。
主題名 Topic Name
附加在應用消息上的一個標簽，服務端已知且與訂閱匹配。服務端發送應用消息的一個副本給每一個匹配的客戶端訂閱。
主題過濾器 Topic Filter
訂閱中包含的一個表達式，用於表示相關的一個或多個主題。主題過濾器可以使用通配符。
MQTT控制報文 MQTT Control Packet
通過網絡連接發送的信息數據包。MQTT 規范定義了十四種不同類型的MQTT控制報文，其中一個（PUBLISH 報文）用於傳輸應用消息。
無效報文 Malformed Packet
根據規范不能被正確解析的控制報文。4.13節 描述了如何進行相應的錯誤處理。
協議錯誤 Protocol Error
在報文解析之后發現包含協議不允許或與客戶端或服務端當前狀態不一致的數據的錯誤。4.13節 描述了如何進行相應的錯誤處理。
遺囑消息 Will Message
在網絡連接非正常關閉的情況下，由服務端發布的應用消息
四：Mqtt 控制報文格式
答：MQTT協議通過交換預定義的MQTT控制報文來通信。這一節描述這些報文的格式。
MQTT控制報文由三部分組成，按照下圖描述的順序：
（1）控制報文的結構
| Fixed Header固定報頭，所有控制報文都包含 |
| Variable Header 可變報頭，部分控制報文包含 |
| Payload 有效載荷，部分控制報文包含 |
解析：固定報頭：每個MQTT控制報文都包含一個固定報頭，固定報頭格式如下：
| 比特位 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
|---|---|---|---|---|---|---|---|---|
| byte 1 | MQTT控制報文的類型 | 用於指定控制報文類型的標志位 | ||||||
| byte 2... | 剩余長度 | |||||||
Mqtt控制報文的類型：
| 名字 | 值 | 報文流動方向 | 描述 |
|---|---|---|---|
| Reserved | 0 | 禁止 | 保留 |
| CONNECT | 1 | 客戶端到服務端 | 客戶端請求連接服務端 |
| CONNACK | 2 | 服務端到客戶端 | 連接報文確認 |
| PUBLISH | 3 | 兩個方向都允許 | 發布消息 |
| PUBACK | 4 | 兩個方向都允許 | QoS 1消息發布收到確認 |
| PUBREC | 5 | 兩個方向都允許 | 發布收到（保證交付第一步） |
| PUBREL | 6 | 兩個方向都允許 | 發布釋放（保證交付第二步） |
| PUBCOMP | 7 | 兩個方向都允許 | QoS 2消息發布完成（保證交互第三步） |
| SUBSCRIBE | 8 | 客戶端到服務端 | 客戶端訂閱請求 |
| SUBACK | 9 | 服務端到客戶端 | 訂閱請求報文確認 |
| UNSUBSCRIBE | 10 | 客戶端到服務端 | 客戶端取消訂閱請求 |
| UNSUBACK | 11 | 服務端到客戶端 | 取消訂閱報文確認 |
| PINGREQ | 12 | 客戶端到服務端 | 心跳請求 |
| PINGRESP | 13 | 服務端到客戶端 | 心跳響應 |
| DISCONNECT | 14 | 兩個方向都允許 | 斷開連接通知 |
| AUTH | 15 | 兩個方向都允許 | 認證信息交換 |
可變報頭：某些 MQTT 控制報文包含一個可變報頭部分。它在固定報頭和有效載荷之間。可變報頭的內容根據報文類型的不同而不同。可變報頭的報文標識符（Packet Identifier）字段存在於在多個類型的報文里。
報文標識符：部分類型MQTT控制報文的可變報頭部分包含了2個字節的報文標識符字段。這些MQTT控制報文類型為：PUBLISH報文（當QoS>0時），PUBACK，PUBREC，PUBREC，PUBREL，PUBCOMP，SUBSCRIBE，SUBACK，UNSUBSCRIBE，UNSUBACK。
需要報文標識符的MQTT控制報文如下表所示。
報文
| 名字 | 值 |
|---|---|
| CONNECT | 不需要 |
| CONNACK | 不需要 |
| PUBLISH | 需要（如果QoS>0） |
| PUBACK | 需要 |
| PUBREC | 需要 |
| PUBREL | 需要 |
| PUBCOMP | 需要 |
| SUBSCRIBE | 需要 |
| SUBACK | 需要 |
| UNSUBSCRIBE | 需要 |
| UNSUBACK | 需要 |
| PINGREQ | 不需要 |
| PINGRESP | 不需要 |
| DISCONNECT | 不需要 |
| AUTH | 不需要 |
（未完待續。。。）