工業物聯網核心技術——MQTT（一）
一、MQTT初探
1. MQTT是什么?
MQTT(Message Queuing Telemetry Transport，消息隊列遙測傳輸協議)，是一種基于發布/訂閱(Publish/Subscribe)模式的輕量級通訊協議，該協議構建于TCP/IP協議上，由IBM在1999年發布，目前***版本為v3.1.1。MQTT***的優點在于可以以極少的代碼和有限的帶寬，為遠程設備提供實時可靠的消息服務。做為一種低開銷、低帶寬占用的即時通訊協議，MQTT在物聯網、小型設備、移動應用等方面有廣泛的應用。
當然，在物聯網開發中，MQTT不是唯一的選擇，與MQTT互相競爭的協議有XMPP和CoAP協議等，文章末尾會有一個比較和說明。
2. MQTT是哪一層的協議?
眾所周知，TCP/IP參考模型可以分為四層：應用層、傳輸層、網絡層、鏈路層。TCP和UDP位于傳輸層，應用層常見的協議有HTTP、FTP、SSH等。MQTT協議運行于TCP之上，屬于應用層協議，因此只要是支持TCP/IP協議棧的地方，都可以使用MQTT。
3. MQTT消息格式
每條MQTT命令消息的消息頭都包含一個固定的報頭，有些消息會攜帶一個可變報文頭和一個負荷。消息格式如下：
- 固定報文頭 | 可變報文頭 | 負荷
4. 固定報文頭(Fixed Header)
MQTT固定報文頭最少有兩個字節，***字節包含消息類型(Message Type)和QoS級別等標志位。第二字節開始是剩余長度字段，該長度是后面的可變報文頭加消息負載的總長度，該字段最多允許四個字節。
剩余長度字段單個字節***值為二進制0b0111 1111，16進制0x7F。也就是說，單個字節可以描述的***長度是127字節。為什么不是256字節呢?因為MQTT協議規定，單個字節第八位(***位)若為1，則表示后續還有字節存在，第八位起“延續位”的作用。
例如，數字64，編碼為一個字節，十進制表示為64，十六進制表示為0×40。數字321(65+2*128)編碼為兩個字節，重要性***的放在前面，***個字節為65+128=193(0xC1)，第二個字節是2(0x02)，表示2×128。
由于MQTT協議最多只允許使用四個字節表示剩余長度(如表1)，并且***一字節***值只能是0x7F不能是0xFF，所以能發送的***消息長度是256MB，而不是512MB。
表1
5. 可變報文頭(Variable Header)
可變報文頭主要包含協議名、協議版本、連接標志(Connect Flags)、心跳間隔時間(Keep Alive timer)、連接返回碼(Connect Return Code)、主題名(Topic Name)等，后面會針對主要部分進行講解。
6. 有效負荷(Payload)
Payload直譯為負荷，可能讓人摸不著頭腦，實際上可以理解為消息主體(body)。
當MQTT發送的消息類型是CONNECT(連接)、PUBLISH(發布)、SUBSCRIBE(訂閱)、SUBACK(訂閱確認)、UNSUBSCRIBE(取消訂閱)時，則會帶有負荷。
二、MQTT的主要特性
1. MQTT的消息類型(Message Type)
固定報文頭中的***個字節包含連接標志(Connect Flags)，連接標志用來區分MQTT的消息類型。MQTT協議擁有14種不同的消息類型(如表2)，可簡單分為連接及終止、發布和訂閱、QoS 2消息的機制以及各種確認ACK。至于每一個消息類型會攜帶什么內容，這里不多闡述。
表2
2. 消息質量(QoS)
MQTT消息質量有三個等級，QoS 0，QoS 1和 QoS 2。
- QoS 0：最多分發一次。消息的傳遞完全依賴底層的TCP/IP網絡，協議里沒有定義應答和重試，消息要么只會到達服務端一次，要么根本沒有到達。
- QoS 1：至少分發一次。服務器的消息接收由PUBACK消息進行確認，如果通信鏈路或發送設備異常，或者指定時間內沒有收到確認消息，發送端會重發這條在消息頭中設置了DUP位的消息。
- QoS 2：只分發一次。這是***級別的消息傳遞，消息丟失和重復都是不可接受的，使用這個服務質量等級會有額外的開銷。
通過下面的例子可以更深刻的理解上面三個傳輸質量等級。
比如目前流行的共享單車智能鎖，智能鎖可以定時使用QoS level 0質量消息請求服務器，發送單車的當前位置，如果服務器沒收到也沒關系，反正過一段時間又會再發送一次。之后用戶可以通過App查詢周圍單車位置，找到單車后需要進行解鎖，這時候可以使用QoS level 1質量消息，手機App不斷的發送解鎖消息給單車鎖，確保有一次消息能達到以解鎖單車。***用戶用完單車后，需要提交付款表單，可以使用QoS level 2質量消息，這樣確保只傳遞一次數據，否則用戶就會多付錢了。
3. 遺愿標志(Will Flag)
在可變報文頭的連接標志位字段(Connect Flags)里有三個Will標志位：Will Flag、Will QoS和Will Retain Flag，這些Will字段用于監控客戶端與服務器之間的連接狀況。如果設置了Will Flag，就必須設置Will QoS和Will Retain標志位，消息主體中也必須有Will Topic和Will Message字段。
那遺愿消息是怎么回事呢?服務器與客戶端通信時，當遇到異常或客戶端心跳超時的情況，MQTT服務器會替客戶端發布一個Will消息。當然如果服務器收到來自客戶端的DISCONNECT消息，則不會觸發Will消息的發送。
因此，Will字段可以應用于設備掉線后需要通知用戶的場景。
4. 連接保活心跳機制(Keep Alive Timer)
MQTT客戶端可以設置一個心跳間隔時間(Keep Alive Timer)，表示在每個心跳間隔時間內發送一條消息。如果在這個時間周期內，沒有業務數據相關的消息，客戶端會發一個PINGREQ消息，相應的，服務器會返回一個PINGRESP消息進行確認。如果服務器在一個半(1.5)心跳間隔時間周期內沒有收到來自客戶端的消息，就會斷開與客戶端的連接。心跳間隔時間***值大約可以設置為18個小時，0值意味著客戶端不斷開。
5. MQTT其他特點
(1) 異步發布/訂閱實現
發布/訂閱模式解耦了發布消息的客戶(發布者)與訂閱消息的客戶(訂閱者)之間的關系，這意味著發布者和訂閱者之間并不需要直接建立聯系。
這個模式有以下好處：
- 發布者與訂閱者只需要知道同一個消息代理即可;
- 發布者和訂閱者不需要直接交互;
- 發布者和訂閱者不需要同時在線。
由于采用了發布/訂閱實現，MQTT可以雙向通信。也就是說MQTT支持服務端反向控制設備，設備可以訂閱某個主題，然后發布者對該主題發布消息，設備收到消息后即可進行一系列操作。
(2) 二進制格式實現
MQTT基于二進制實現而不是字符串，比如HTTP和XMPP都是基于字符串實現。由于HTTP和XMPP擁有冗長的協議頭部，而MQTT固定報文頭僅有兩字節，所以相比其他協議，發送一條消息最省流量。
接下篇《工業物聯網核心技術——MQTT(二)》
