MQTT 協(xié)議是什么？

洞察基

隨著 5G 時(shí)代的來(lái)臨，萬(wàn)物互聯(lián)的偉大構(gòu)想正在成為現(xiàn)實(shí)。聯(lián)網(wǎng)的 物聯(lián)網(wǎng)設(shè)備 在 2018 年已經(jīng)達(dá)到了 70 億1，在未來(lái)兩年，僅智能水電氣表就將超過10億2。

海量的設(shè)備接入和設(shè)備管理對(duì)網(wǎng)絡(luò)帶寬、通信協(xié)議以及平臺(tái)服務(wù)架構(gòu)都帶來(lái)了很大挑戰(zhàn)。對(duì)于 物聯(lián)網(wǎng)協(xié)議 來(lái)說，必須針對(duì)性地解決物聯(lián)網(wǎng)設(shè)備通信的幾個(gè)關(guān)鍵問題：其網(wǎng)絡(luò)環(huán)境復(fù)雜而不可靠、其內(nèi)存和閃存容量小、其處理器能力有限。

MQTT 協(xié)議 是基于發(fā)布/訂閱模式的物聯(lián)網(wǎng)通信協(xié)議，憑借簡(jiǎn)單易實(shí)現(xiàn)、支持 QoS、報(bào)文小等特點(diǎn)，占據(jù)了物聯(lián)網(wǎng)協(xié)議的半壁江山：

MQTT 協(xié)議的誕生

MQTT was created by Andy Stanford-Clark of IBM, and Arlen Nipper (then of Arcom Systems, later CTO of Eurotech).3

據(jù) Arlen Nipper 在一 IBM Podcast 上的自述，MQTT 原名是 MQ TT， 注意 MQ 與 TT之間的空格，其全稱為: MQ Telemetry Transport，是九十年代早期，他在參與 Conoco Phillips 公司的一個(gè)原油管道數(shù)據(jù)采集監(jiān)控系統(tǒng)(pipeline SCADA system)時(shí)，開發(fā)的一個(gè)實(shí)時(shí)數(shù)據(jù)傳輸協(xié)議。它的目的在于讓傳感器通過帶寬有限的 VSAT ，與 IBM 的 MQ Integrator 通信。由于 Nipper 是遙感和數(shù)據(jù)采集監(jiān)控專業(yè)出身，所以按業(yè)內(nèi)慣例給了個(gè) MQ TT 的名字。

MQTT 協(xié)議設(shè)計(jì)原則

按照 Nipper 的介紹，MQTT 必須簡(jiǎn)單容易實(shí)現(xiàn)，必須支持 QoS(設(shè)備網(wǎng)絡(luò)環(huán)境復(fù)雜)，必須輕量且省帶寬(因?yàn)槟菚r(shí)候帶寬很貴)，必須數(shù)據(jù)無(wú)關(guān)(不關(guān)心 Payload 數(shù)據(jù)格式)，必須有持續(xù)地會(huì)話感知能力(時(shí)刻知道設(shè)備是否在線)。下面將介紹 MQTT (3.1.1 版本) 的幾個(gè)核心特色，分別對(duì)應(yīng)了這幾個(gè)設(shè)計(jì)原則的實(shí)現(xiàn)。

靈活的發(fā)布訂閱和主題設(shè)計(jì)

發(fā)布訂閱模式是傳統(tǒng) Client/Server 模式的一種解耦方案。發(fā)布者通過 Broker 與消費(fèi)者之間通信，Broker 的作用是將收到的消息通過某種過濾規(guī)則，正確地發(fā)送給消費(fèi)者。發(fā)布/訂閱模式 相對(duì)于 客戶端/服務(wù)器模式 的好處在于：

• 發(fā)布者和消費(fèi)者之間不必預(yù)先知道對(duì)方的存在，比如不需要預(yù)先溝通對(duì)方的 IP Address 和 Port
• 發(fā)布者和消費(fèi)者之間不必同時(shí)運(yùn)行。因?yàn)?Broker 是一直運(yùn)行的。
  

在 MQTT 協(xié)議里，上面提到的 過濾規(guī)則 是 Topic。比如：所有發(fā)布到 news 這個(gè) Topic 的消息，都會(huì)被 Broker 轉(zhuǎn)發(fā)給已經(jīng)訂閱了 news 的訂閱者:

上圖中訂閱者預(yù)先訂閱了 news，然后發(fā)布者向 Broker 發(fā)布了一條消息 "some msg" 并指定發(fā)布到 news 主題，Broker 通過 Topic 匹配，決定將這條消息轉(zhuǎn)發(fā)給訂閱者。

MQTT 的 Topic 有層級(jí)結(jié)構(gòu)，并且支持通配符 + 和 #:

• + 是匹配單層的通配符。比如 news/+ 可以匹配 news/sports，news/+/basketball 可匹配到 news/sports/basketball。
• # 是一到多層的通配符。比如 news/# 可以匹配 news、 news/sports、news/sports/basketball 以及 news/sports/basketball/x 等等。
  

MQTT 的主題是不要預(yù)先創(chuàng)建的，發(fā)布者發(fā)送消息到某個(gè)主題、或者訂閱者訂閱某個(gè)主題的時(shí)候，Broker 就會(huì)自動(dòng)創(chuàng)建這個(gè)主題。

帶寬消耗最小化

MQTT 協(xié)議將協(xié)議本身占用的額外消耗最小化，消息頭部最小只需要占用 2 個(gè)字節(jié)。

MQTT 的消息格式分三部分：

固定長(zhǎng)度頭部，2 個(gè)字節(jié)，所有消息類型里都有
可變長(zhǎng)度頭部，只有某些消息類型里有
Payload，只有某些消息類型里有

MQTT 的主要消息類型有：

• CONNECT / CONNACK
• PUBLISH / PUBACK
• SUBSCRIBE / SUBACK
• UNSUBSCRIBE / UNSUBACK
• PINGREQ / PINGRESP
• DISCONNECT
  

其中 PINGREQ / PINGRESP 和 DISCONNECT 報(bào)文是不需要可變頭部的，也沒有 Payload，也就是說它們的報(bào)文大小僅僅消耗 2 個(gè)字節(jié)。

在 CONNECT 報(bào)文的可變長(zhǎng)度頭部里，有個(gè) Protocol Version 的字段。為了節(jié)省空間，只有一個(gè)字節(jié)。所以版本號(hào)不是按照字符串 "3.1.1" 存放的，而是使用數(shù)字 4 來(lái)表示 3.1.1 版本。

三個(gè)可選的 QoS 等級(jí)

為適應(yīng)設(shè)備不同的網(wǎng)絡(luò)環(huán)境，MQTT 設(shè)計(jì)了 3 個(gè) QoS 等級(jí)，0, 1, 2:

• At most once (0)
• At least once (1)
• Exactly once (2)
  

QoS 0 是一種 "fire and forget" 的消息發(fā)送模式：Sender (可能是 Publisher 或者 Broker) 發(fā)送一條消息之后，就不再關(guān)心它有沒有發(fā)送到對(duì)方，也不設(shè)置任何重發(fā)機(jī)制。

QoS 1 包含了簡(jiǎn)單的重發(fā)機(jī)制，Sender 發(fā)送消息之后等待接收者的 ACK，如果沒收到 ACK 則重新發(fā)送消息。這種模式能保證消息至少能到達(dá)一次，但無(wú)法保證消息重復(fù)。

QoS 2 設(shè)計(jì)了略微復(fù)雜的重發(fā)和重復(fù)消息發(fā)現(xiàn)機(jī)制，保證消息到達(dá)對(duì)方并且嚴(yán)格只到達(dá)一次。

會(huì)話保持

MQTT 沒有假設(shè)設(shè)備或 Broker 使用了 TCP 的保活機(jī)制4，而是設(shè)計(jì)了協(xié)議層的保活機(jī)制：在 CONNECT 報(bào)文里可設(shè)置 Keepalive 字段，來(lái)設(shè)置保活心跳包 PINGREQ/PINGRESP 的發(fā)送時(shí)間間隔。當(dāng)長(zhǎng)時(shí)間無(wú)法收到設(shè)備的 PINGREQ 的時(shí)候，Broker 就會(huì)認(rèn)為設(shè)備已經(jīng)下線。

總的來(lái)說，Keepalive 有兩個(gè)作用：

• 發(fā)現(xiàn)對(duì)端死亡或者網(wǎng)絡(luò)中斷
• 在長(zhǎng)時(shí)間無(wú)消息交互的情況下，保持連接不被網(wǎng)絡(luò)設(shè)備斷開
  

對(duì)于那些想要在重新上線后，重新收到離線期間錯(cuò)過的消息的設(shè)備，MQTT 設(shè)計(jì)了持久化連接：在 CONNECT 報(bào)文里可設(shè)置 CleanSession 字段為 False，則 Broker 會(huì)為終端存儲(chǔ)：

• 設(shè)備所有的訂閱
• 還未被設(shè)備確認(rèn)的 QoS1 和 QoS 消息
• 設(shè)備離線時(shí)錯(cuò)過的消息
  

在線狀態(tài)感知

MQTT 設(shè)計(jì)了遺愿(Last Will) 消息，讓 Broker 在發(fā)現(xiàn)設(shè)備異常下線的情況下，幫助設(shè)備發(fā)布一條遺愿消息到指定的主題。

實(shí)際上在某些 MQTT 服務(wù)器的實(shí)現(xiàn)里 (比如 EMQX)，設(shè)備上線或下線的時(shí)候 Broker 會(huì)通過某些系統(tǒng)主題發(fā)布設(shè)備狀態(tài)更新，更符合實(shí)際應(yīng)用場(chǎng)景。

開源 MQTT 服務(wù)器如何選擇

到目前為止，比較流行的開源 MQTT 服務(wù)器有幾個(gè)：

• Eclipse Mosquitto
  使用 C 語(yǔ)言實(shí)現(xiàn)的 MQTT 服務(wù)器。Eclipse 組織還還包含了大量的 MQTT 客戶端項(xiàng)目：https://www.eclipse.org/paho/#
• EMQX
  使用 Erlang 語(yǔ)言開發(fā)的 MQTT 服務(wù)器，內(nèi)置強(qiáng)大的規(guī)則引擎，支持許多其他 IoT 協(xié)議比如 MQTT-SN、 CoAP、LwM2M 等。
• Mosca
  使用 Node.JS 開發(fā)的 MQTT 服務(wù)器，簡(jiǎn)單易用。
• VerneMQ
  同樣使用 Erlang 開發(fā)的 MQTT 服務(wù)器.
  
  

從支持 MQTT 5.0、穩(wěn)定性、擴(kuò)展性、集群能力等方面考慮，EMQX 的表現(xiàn)應(yīng)該是最好的：

• 使用 Erlang OTP 開發(fā)，容錯(cuò)能力好 (電信領(lǐng)域久經(jīng)考驗(yàn)的語(yǔ)言，曾經(jīng)做出過 99.9999999% 可用性的交換機(jī)設(shè)備5)
• 官方有大量的擴(kuò)展插件可供擴(kuò)展。有很多認(rèn)證插件，數(shù)據(jù)存儲(chǔ)(backend)插件可供選擇。可支持各種關(guān)系型數(shù)據(jù)庫(kù)，NoSQL 數(shù)據(jù)庫(kù)，以及常見消息隊(duì)列如 Kafka，RabbitMQ，Pulsar 等
• 支持集群，支持節(jié)點(diǎn)水平擴(kuò)展
• 單節(jié)點(diǎn)支持 2000K 并發(fā)連接
• 支持規(guī)則引擎和編解碼
  

MQTT 協(xié)議快速體驗(yàn)MQTT 在線服務(wù)器

EMQX MQTT 物聯(lián)網(wǎng)云服務(wù) 提供了一個(gè)在線的公共 MQTT 5.0 服務(wù)器，不需要任何安裝您就可以快速開始 MQTT 協(xié)議的學(xué)習(xí)、測(cè)試或原型制作。

該 MQTT 服務(wù)器的詳細(xì)接入信息請(qǐng)見 EMQ 官網(wǎng)頁(yè)面：免費(fèi)的在線 MQTT 服務(wù)器。

MQTT 在線客戶端

EMQ 也提供了支持瀏覽器訪問的 MQTT 在線客戶端工具，該工具支持通過普通或者加密的 WebSocket 端口連接至 MQTT 服務(wù)器，同時(shí)也支持緩存連接方便下次訪問使用。

原創(chuàng)文章，作者：EMQ，如若轉(zhuǎn)載，請(qǐng)注明出處：https://www.emqx.com/zh/blog/what-is-the-mqtt-protocol