前面討論了MQTT協議的控制報文的格式，下面分別舉例探討各個控制報文的詳細內容。
01、CONNECT – 連接服務端
客戶端到服務端的網絡連接建立后，客戶端發送給服務端的第一個報文必須是CONNECT報文。客戶端在連接成功后，不能再次發送這個報文，否則服務端應按照違規處理，斷開當前網絡連接。一個完整的CONNECT報文見下圖：
清理會話--Clean Session（1號位）
這個標志位是代表對會話狀態的處理方式。
如果設置為0，則服務端必須使用客戶端ID找到該客戶端的會話恢復通信。如果找不到這個會話則創建一個新會話，然后在斷開時，必須保存這個會話信息。
如果設置為1，則客戶端和服務端都必須丟棄之前的任何會話，全新開始一個會話。會話持續時間與網絡連接時間同樣長。這個會話關聯的狀態數據不能被任何之后的會話重用。
客戶端會話關聯的狀態數據：
◆已經發送給服務端，但是還沒有完成確認的QoS 1和QoS 2級別的消息
◆已從服務端接收，但是還沒有完成確認的QoS 2級別的消息。
服務端會話關聯的狀態數據：
◆會話是否存在，即使會話狀態的其它部分都是空。
◆客戶端的訂閱信息。
◆已經發送給客戶端，但是還沒有完成確認的QoS 1和QoS 2級別的消息。
◆即將傳輸給客戶端的QoS 1和QoS 2級別的消息。
◆已從客戶端接收，但是還沒有完成確認的QoS 2級別的消息。
◆可選，准備發送給客戶端的QoS 0級別的消息。
遺囑標志（是否有遺囑）--Will Flag（2號位）
如果設置為0，本次連接沒有遺囑。
如果設置為1，本次連接帶有遺囑，服務端必須保存遺囑消息並與這個連接關聯。本條報文中也必須包含遺囑消息。
遺囑服務質量等級--Will QoS（3、4號位）
指定遺囑消息的服務質量等級，具體可參看前面的QoS說明。
如果遺囑標志為0，那么這個等級必須設置為0。如果遺囑標志為1，這個等級可以設置0、1、2中的任何一種。
遺囑保留--Will Retain（5號位）
如果設置為0，遺囑消息作為非保留消息發布，在遺囑標志設置為0時，這里也必須設置為0。
如果設置為1，遺囑消息作為非保留消息發布。
保持連接--Keep Alive（11、12字節）
是指在客戶端傳輸完成一個控制報文的時刻到發送下一個報文的時刻，兩者之間允許空閑的最大時間間隔。客戶端負責保證控制報文發送的時間間隔不超過保持連接的值。如果沒有任何其它的控制報文可以發送，客戶端必須發送一個PINGREQ報文。
保持連接的值為零表示關閉保持連接功能。這意味着，服務端不需要因為客戶端不活躍而斷開連接。注意：不管保持連接的值是多少，任何時候，只要服務端認為客戶端是不活躍或無響應的，可以斷開客戶端的連接。
響應 Response
本報文的響應報文是：CONNACK
02、CONNACK – 確認連接請求
每次連接建立后服務端發送給客戶端的第一個報文，是響應CONNECT報文的，一個完整的CONNACK報文見下圖：
當前會話--Session Present（0號位）
如果服務端收到的連接請求中清理會話（CleanSession）標志為1，除了將本報文中的返回碼設置為0外，還必須將當前會話（Session Present）標志設置為0 。
如果服務端收到一個CleanSession為0的連接，當前會話標志的值取決於服務端是否已經保存了ClientId對應客戶端的會話狀態。如果服務端已經保存了會話狀態，它必須將本報文中的當前會話標志設置為1 。如果服務端沒有已保存的會話狀態，則必須將本報文中的當前會話設置為0。還需將返回碼設置為0 。
當前會話標志使服務端和客戶端在是否有已存儲的會話狀態上保持一致。
如果服務端發送了一個包含非零返回碼的CONNACK報文，它必須將當前會話標志設置為0。
03、PUBLISH – 發布消息
是指從客戶端向服務端或者服務端向客戶端傳輸一個應用消息。一個完整的PUBLISH報文見下圖：
保留標志--RETAIN（0號位）
如果設置為1，服務端必須存儲這個應用消息和它的服務質量等級（QoS），以便它可以被分發給后期訂閱匹配的訂閱者。如果同時QoS=0，它必須用新的消息替換掉之前為那個主題保留的所有消息。
服務端發送PUBLISH報文給客戶端時，如果消息是作為客戶端一個新訂閱的結果發送，它必須將報文的保留標志設為1。當一個PUBLISH報文發送給客戶端是因為匹配一個已建立的訂閱時，服務端必須將保留標志設為0，不管它收到的這個消息中保留標志的值是多少。
如果設置為0，服務端不能存儲這個消息也不能移除或替換任何現存的保留消息。
響應 Response
本報文的響應報文是：QoS=0時不需要響應；QoS=1時是PUBACK；QoS=2時是PUBREC。
04、PUBACK –發布確認
是對QoS 1等級的PUBLISH報文的響應。一個完整的PUBACK報文見下圖：
05、PUBREC – 發布收到（QoS=2，第一步）
是對QoS等級2的PUBLISH報文的響應。它是QoS=2等級協議交換的第二個報文。一個完整的PUBREC報文見下圖：
響應 Response
本報文的響應報文是：PUBREL。
06、PUBREL – 發布釋放（QoS 2，第二步）
是對PUBREC報文的響應。它是QoS 2等級協議交換的第三個報文。一個完整的PUBREL報文見下圖：
響應 Response
本報文的響應報文是：PUBCOMP。
07、PUBCOMP – 發布完成（QoS 2，第三步）
是對PUBREL報文的響應。它是QoS 2等級協議交換的第四個（也是最后一個）報文。一個完整的PUBCOMP報文見下圖：
08、SUBSCRIBE - 訂閱主題
由客戶端向服務端發送的，用於創建一個或多個訂閱。每個訂閱是該客戶端關注的一個或多個主題。服務端依據客戶端的訂閱來匹配主題，然后將對應的PUBLISH報文發送給客戶端。本報文也（為每個訂閱）指定了最大的QoS等級，服務端根據這個決定如何發送應用消息給客戶端。一個完整的SUBSCRIBE報文見下圖：
響應 Response
本報文的響應報文是：SUBACK。
09、SUBACK – 訂閱確認
服務端發送本報文給客戶端，用於確認它已收到並且正在處理SUBSCRIBE報文。
本報文包含一個返回碼清單，它們指定了SUBSCRIBE請求的每個訂閱被授予的最大QoS等級。一個完整的SUBACK報文見下圖：
10、UNSUBSCRIBE –取消訂閱
客戶端發送本報文給服務端，用於取消訂閱主題。一個完整的UNSUBSCRIBE報文見下圖：
響應 Response
本報文的響應報文是：UNSUBACK。
11、UNSUBACK – 取消訂閱確認
服務端發送本報文給客戶端用於確認收到UNSUBSCRIBE報文。一個完整的UNSUBACK報文見下圖：
12、PINGREQ – 心跳請求
客戶端發送本報文給服務端的。用於：
◆在沒有任何其它控制報文從客戶端發給服務的時，告知服務端客戶端還活着。
◆請求服務端發送 響應確認它還活着。
◆使用網絡以確認網絡連接沒有斷開。
保持連接（Keep Alive）處理中用到這個報文。一個完整的PINGREQ報文見下圖：
響應 Response
本報文的響應報文是：PINGRESP。
13、PINGRESP – 心跳響應
服務端發送本報文響應客戶端的PINGREQ報文。表示服務端還活着。
保持連接（Keep Alive）處理中用到這個報文。一個完整的PINGREQ報文見下圖：
14、DISCONNECT –斷開連接
是客戶端發給服務端的最后一個控制報文。表示客戶端正常斷開連接。一個完整的DISCONNECT報文見下圖：
關於MQTT控制報文的例說就到這里，希望對進一步理解MQTT協議能有很好的幫助。后面會繼續其他內容。
本節完，待續…