MQTT通信協議作為目前最主流的物聯網協議，大家應該都很熟悉，包括阿里云、百度云等都是通過MQTT協議來實現通訊的，與HTTP通信協議一樣，其本身都是建立在TCP/IP協議上，本文會詳細介紹MQTT報文協議，讓大家直觀地感受到MQTT通信協議報文的結構與內容。
在探究MQTT通信協議底層的報文之前，大家還應該對于MQTT通信協議本身的工作模式有一個簡要直觀的了解。首先MQTT通信協議是一種低開銷、低帶寬占用的即時通訊協議，它本身是一種消息發(fā)布/訂閱的機制實現端與服務器通訊的協議。對于服務器而言，沒有訂閱的概念；而對于客戶端而言，既有發(fā)布概念，也有訂閱概念，客戶端通過發(fā)布主題向服務器發(fā)布信息，服務器收到信息后根據客戶端的發(fā)布主題對消息進行處理。而消息的發(fā)布又要區(qū)分QoS概念，0/1/2分別對應消息傳輸一次，保證傳輸一次以及保證僅僅傳輸一次，這些涉及到服務器與客戶端在通訊過程中是否有交互的過程。這幾個概念是MQTT通信協議主要的幾個概念，下面正式去詳解MQTT通信協議的報文內容。
首先探究MQTT協議報文內容，是直接使用TCP服務器進行通訊的(不使用MQTT服務器)，因為MQTT協議本身是基于TCP協議進行通訊的，所以只要服務器向設備發(fā)起的請求連接報文以及訂閱報文進行正確的回復，普通的TCP服務器完全可以當做MQTT服務器接收到客戶端發(fā)布的消息，并且能非常簡單地將設備發(fā)送的包抓出來，其他手段類似于抓包工具也能實現但是并不能直觀幫助我們了解這一過程。
拿一個億佰特的4G DTU設備舉例（其他設備也是一樣的），由于MQTT通信協議本身要配置三元組，我們將設備配置成標準MQTT協議工作模式，三元組按照下面的參數配置，然后目標地址與端口直接填寫我們TCP服務器的地址與端口，訂閱與發(fā)布都勾選并且都按照如下進行配置，然后觀察我們TCP服務器上交互的信息。
以下為TCP服務器端交互的信息：
連接MQTT通信協議第一步是請求TCP服務器連接，這一步由協議棧直接完成不需要管，然后客戶端會發(fā)送請求MQTT服務器連接報文，也就是上面的第一條消息：
第一個byte為0x10，其為MQTT協議固定頭部分，此byte的8個bit位分別代表了不同的意義，高四位與低四位的值分別代表的意義也貼在了下方：
高四位信息：
低四位信息：
以上就是固定頭部分的內容，常見的固定頭以及其意義如下：
這里就能直觀地理解MQTT通信協議交互過程中的幾個交互報文的頭部了，先是0x10為首的請求MQTT通信協議連接報文；其次是0x20為首的服務器響應連接的報文；然后是0x82為首的設備訂閱請求報文；接著是0x90為首的訂閱請求回復。至此完成了設備連接MQTT服務器并且訂閱成功的過程。最后是設備發(fā)布的報文，以0x30為首。
MQTT通訊報文的第二個字節(jié)指示的是剩余字段的長度，比如請求連接報文第二個字節(jié)值為0x1F代表后面的一個字節(jié)為剩余長度，這個剩余長度最大占用4個字節(jié)，每個字節(jié)的低七位是編碼數據，而最高位代表后面有沒有更多字節(jié)位，表示后續(xù)有沒有更多的字節(jié)為代表剩余字節(jié)數。而剩余的包括MQTT通信協議三元組信息，是可以在請求連接報文中看到的（0x31 0x31 0x31 就代表Client ID ，其前面的0x03代表Client ID 的長度），而發(fā)布topic，可以在客戶端發(fā)布的報文中看到。
這些就是MQTT報文的詳情，去了解底層的報文結構有助于我們更好地掌控此協議的用法以及排查問題。
文章推薦：
億佰特人每一天都致力于更好的助力物聯化、智能化、自動化的發(fā)展，提升資源利用率，更多產品更多資料，感興趣的小伙伴可以登錄我們的官網進行了解，還有客服小姐姐在線答疑哦！
