淺談张足，實(shí)例mqtt；

簡(jiǎn)介

MQTT 全稱為 Message Queuing Telemetry Transport（消息隊(duì)列遙測(cè)傳輸）是一種基于發(fā)布/訂閱范式的“輕量級(jí)”消息協(xié)議瘟滨，由 IBM 發(fā)布候醒。

  • MQTT 可以被解釋為一種低開銷，低帶寬占用的即時(shí)通訊協(xié)議杂瘸，可以用極少的代碼和帶寬的為連接遠(yuǎn)程設(shè)備提供實(shí)時(shí)可靠的消息服務(wù)倒淫，它適用于硬件性能低下的遠(yuǎn)程設(shè)備以及網(wǎng)絡(luò)狀況糟糕的環(huán)境下，因此 MQTT 協(xié)議在 IoT（Internet of things败玉，物聯(lián)網(wǎng)）敌土，小型設(shè)備應(yīng)用，移動(dòng)應(yīng)用等方面有較廣泛的應(yīng)用运翼。
  • IoT 設(shè)備要運(yùn)作纯赎，就必須連接到互聯(lián)網(wǎng)，設(shè)備才能相互協(xié)作南蹂，以及與后端服務(wù)協(xié)同工作。而互聯(lián)網(wǎng)的基礎(chǔ)網(wǎng)絡(luò)協(xié)議是 TCP/IP念恍，MQTT 協(xié)議是基于 TCP/IP 協(xié)議棧而構(gòu)建的六剥，因此它已經(jīng)慢慢的已經(jīng)成為了 IoT 通訊的標(biāo)準(zhǔn)。

在簡(jiǎn)介完 MQTT 協(xié)議后峰伙，EMQ君將從其一些基本特點(diǎn)和基本概念為兩部分疗疟，介紹 MQTT 協(xié)議。

基本特點(diǎn)

  1. MQTT是一種發(fā)布/訂閱傳輸協(xié)議瞳氓，基本原理和實(shí)現(xiàn)如下策彤；
image

MQTT 協(xié)議提供一對(duì)多的消息發(fā)布，可以解除應(yīng)用程序耦合匣摘，信息冗余小店诗。該協(xié)議需要客戶端和服務(wù)端，而協(xié)議中主要有三種身份：發(fā)布者（Publisher）音榜、代理（Broker庞瘸，服務(wù)器）、訂閱者（Subscriber）赠叼。其中擦囊，消息的發(fā)布者和訂閱者都是客戶端，消息代理是服務(wù)器嘴办，而消息發(fā)布者可以同時(shí)是訂閱者瞬场，實(shí)現(xiàn)了生產(chǎn)者與消費(fèi)者的脫耦。

  1. 使用 TCP/IP 提供網(wǎng)絡(luò)連接涧郊，提供有序贯被、無損、雙向連接；

    MQTT 是一種連接協(xié)議刃榨，它指定了如何組織數(shù)據(jù)字節(jié)并通過 TCP/IP 網(wǎng)絡(luò)傳輸它們弹砚。設(shè)備聯(lián)網(wǎng)，也需要連接到互聯(lián)網(wǎng)中枢希，在大萬維的世界中桌吃，TCP 如同汽車，有輪子就能用來運(yùn)輸數(shù)據(jù)苞轿，MQTT 就像是交通規(guī)則茅诱。在網(wǎng)絡(luò)模型中，TCP是傳輸層協(xié)議搬卒，而 MQTT是在應(yīng)用層瑟俭，在 TCP 的上層，因此MQTT 也是基于這個(gè)而構(gòu)建的契邀，提高了可靠性摆寄。

  2. 對(duì)負(fù)載內(nèi)容屏蔽的消息傳輸；

    可以對(duì)消息訂閱者所接受到的內(nèi)容有所屏蔽坯门。

  3. 具體有三種消息發(fā)布的服務(wù)質(zhì)量：

    • 至多一次微饥，消息發(fā)布完全依賴底層 TCP/IP 網(wǎng)絡(luò)。會(huì)發(fā)生消息丟失或重復(fù)古戴。這一級(jí)別可用于如下情況欠橘，環(huán)境傳感器數(shù)據(jù)，丟失一次讀記錄無所謂现恼，因?yàn)椴痪煤筮€會(huì)有第二次發(fā)送肃续。
    • 至少一次，確保消息到達(dá)叉袍，但消息重復(fù)可能會(huì)發(fā)生始锚。
    • 只有一次，確保消息到達(dá)一次喳逛。這一級(jí)別可用于如下情況疼蛾，在計(jì)費(fèi)系統(tǒng)中，消息重復(fù)或丟失會(huì)導(dǎo)致不正確的結(jié)果艺配。

  4. 小型傳輸察郁，開銷小，固定長(zhǎng)度的頭部是 2 字節(jié)转唉，協(xié)議交換最小化皮钠，以降低網(wǎng)絡(luò)流量；

    整體上協(xié)議可拆分為：固定頭部+可變頭部+消息體赠法，這就是為什么在介紹里說它非常適合"在物聯(lián)網(wǎng)領(lǐng)域麦轰，傳感器與服務(wù)器的通信乔夯，信息的收集"。

  5. 使用Last Will和Testament特性通知有關(guān)各方客戶端異常中斷的機(jī)制款侵；

    Last Will：即遺言機(jī)制末荐，用于通知同一主題下的其他設(shè)備發(fā)送遺言的設(shè)備已經(jīng)斷開了連接。

    Testament：遺囑機(jī)制新锈，功能類似于Last Will甲脏。

基本概念

  1. MQTT 客戶端

    一個(gè)使用 MQTT 協(xié)議的設(shè)備、應(yīng)用程序等妹笆，它總是建立到服務(wù)器的網(wǎng)絡(luò)連接块请。

    • 可以發(fā)布信息，其他客戶端可以訂閱該信息

    • 訂閱其它客戶端發(fā)布的消息

    • 退訂或刪除應(yīng)用程序的消息

    • 斷開與服務(wù)器連接

  2. MQTT 服務(wù)器

    MQTT 服務(wù)器以稱為 Broker（消息代理）拳缠，以是一個(gè)應(yīng)用程序或一臺(tái)設(shè)備墩新。它是位于消息發(fā)布者 和訂閱者之間

    • 接受來自客戶端的網(wǎng)絡(luò)連接
    • 接受客戶端發(fā)布的應(yīng)用信息
    • 處理來自客戶端的訂閱和退訂請(qǐng)求
    • 向訂閱的客戶轉(zhuǎn)發(fā)應(yīng)用程序消息

  3. 主題（Topic）

    連接到一個(gè)應(yīng)用程序消息的標(biāo)簽，該標(biāo)簽與服務(wù)器的訂閱相匹配窟坐。服務(wù)器會(huì)將消息發(fā)送給訂閱所匹配標(biāo)簽的每個(gè)客戶端海渊。

    • 要訂閱的主題。一個(gè)主題可以有多個(gè)級(jí)別哲鸳，級(jí)別之間用斜杠字符分隔切省。例如，/world 和 emq/emqtt/emqx 是有效的主題帕胆。

    • 訂閱者的Topic name支持通配符#和+ ：

      • 支持一個(gè)主題內(nèi)任意級(jí)別話題

      • +只匹配一個(gè)主題級(jí)別的通配符

    • 客戶端成功訂閱某個(gè)主題后，代理會(huì)返回一條 SUBACK 消息般渡，其中包含一個(gè)或多個(gè) returnCode 參數(shù)

  4. 主題篩選器（Topic Filter）

    一個(gè)對(duì)主題名通配符篩選器懒豹，在訂閱表達(dá)式中使用，表示訂閱所匹配到的多個(gè)主題驯用。

  5. QoS（消息傳遞的服務(wù)質(zhì)量水平）

    服務(wù)質(zhì)量脸秽，標(biāo)志表明此主題范圍內(nèi)的消息傳送到客戶端所需的一致程度。

    • 值 0：不可靠蝴乔，消息基本上僅傳送一次记餐，如果當(dāng)時(shí)客戶端不可用，則會(huì)丟失該消息薇正。
    • 值 1：消息應(yīng)傳送至少 1 次片酝。
    • 值 2：消息僅傳送一次。

  6. 會(huì)話（Session）

    每個(gè)客戶端與服務(wù)器建立連接后就是一個(gè)會(huì)話挖腰，客戶端和服務(wù)器之間有狀態(tài)交互雕沿。會(huì)話存在于一個(gè)網(wǎng)絡(luò)之間，也可能在客戶端和服務(wù)器之間跨越多個(gè)連續(xù)的網(wǎng)絡(luò)連接猴仑。

  7. 訂閱（Subscription）

    訂閱包含主題篩選器（Topic Filter）和最大服務(wù)質(zhì)量（QoS）审轮。訂閱會(huì)與一個(gè)會(huì)話（Session）關(guān)聯(lián)。一個(gè)會(huì)話可以包含多個(gè)訂閱。每一個(gè)會(huì)話中的每個(gè)訂閱都有一個(gè)不同的主題篩選器疾渣。

    • 客戶端在成功建立TCP連接之后篡诽，發(fā)送CONNECT消息，在得到服務(wù)器端授權(quán)允許建立彼此連接的CONNACK消息之后榴捡，客戶端會(huì)發(fā)送SUBSCRIBE消息杈女，訂閱感興趣的Topic主題列表（至少一個(gè)主題）
    • 訂閱的主題名稱采用UTF-8編碼，然后緊跟著對(duì)應(yīng)的QoS值

  8. 發(fā)布（publish）

    控制報(bào)文是指從客戶端向服務(wù)端或者服務(wù)端向客戶端傳輸一個(gè)應(yīng)用消息薄疚，MQTT 客戶端發(fā)送消息請(qǐng)求碧信，發(fā)送完成后返回應(yīng)用程序線程

    • 比如安卓的推送服務(wù)，還有一些即時(shí)通信軟件如微信等也是采用的推送技術(shù)街夭。

  9. 負(fù)載（Payload）

    消息訂閱者所具體接收的內(nèi)容

簡(jiǎn)單示例

MQTT 協(xié)議主要是根據(jù)以下情況設(shè)計(jì)的：

  • M2M（Machine to Machine）砰碴，機(jī)器或設(shè)備間端到端通信，比如傳感器之間的數(shù)據(jù)通訊板丽。
  • 設(shè)備（Machine）中呈枉，例如傳感器，硬件能力很弱埃碱，協(xié)議要考慮盡量小的資源消耗猖辫，比如計(jì)算能力和存儲(chǔ)等。

根據(jù) MQTT 的基礎(chǔ)了解后并結(jié)合簡(jiǎn)單的架構(gòu)砚殿，在這里做一個(gè)簡(jiǎn)單的示例圖啃憎，可以更直觀的理解MQTT協(xié)議的通信模型。MQTT Broker 就選擇 EMQ 作為示范似炎。比如有1個(gè)溫度傳感器（1個(gè)Machine）辛萍，1個(gè)移動(dòng)設(shè)備，1個(gè)電腦羡藐，一個(gè)服務(wù)器（3個(gè)Machine)贩毕，都可以得到或者顯示溫度傳感器的溫度值，需要先通過 MQTT 協(xié)議subscribe（訂閱）一個(gè)比如叫 temperature 的 topic（主題）如下：

image

圖中移動(dòng)設(shè)備仆嗦，服務(wù)器辉阶，電腦需要先通過 EMQ subscribe 一個(gè)叫 temperature 的 topic，當(dāng)溫度傳感器 publish 溫度數(shù)據(jù)瘩扼，三個(gè)設(shè)備就可以收到了谆甜。

進(jìn)一步了解MQTT 3

MQTT 3 （當(dāng)前版本3.1.1）是目前使用的最為廣泛的MQTT協(xié)議標(biāo)準(zhǔn)。盡管MQTT5標(biāo)準(zhǔn)已經(jīng)發(fā)布集绰，并且?guī)砹艘恍┝钊苏駣^的新特性店印，但是在整個(gè)應(yīng)用場(chǎng)景上，從后臺(tái)服務(wù)到消息中間件再到客戶端SDK等環(huán)節(jié)上的產(chǎn)品升級(jí)并沒有都完成倒慧，再加上既有部署的維護(hù)按摘，業(yè)界從版本3到5的過渡可能會(huì)持續(xù)相當(dāng)長(zhǎng)一段時(shí)間包券，所以，對(duì)于剛加入物聯(lián)網(wǎng)行業(yè)的生力軍來說炫贤，現(xiàn)在來學(xué)習(xí)MQTT 3依然是一件很有意義的事情溅固。

MQTT協(xié)議的工作方式

前面簡(jiǎn)介中講到，在一個(gè)QMTT協(xié)議中有三個(gè)角色會(huì)參與到整個(gè)通信過程兰珍，發(fā)布者（publisher）侍郭、代理（broker）和訂閱者（subscriber）。有別于傳統(tǒng)的客戶端/服務(wù)器通訊協(xié)議掠河，MQTT協(xié)議并不是端到端的亮元，消息傳遞通過代理，包括會(huì)話（session）也不是建立在發(fā)布者和訂閱者之間唠摹，而是建立在端和代理之間爆捞。代理解除了發(fā)布者和訂閱者之間的耦合。

除了發(fā)布者和訂閱者之間傳遞普通消息勾拉，代理還可以為發(fā)布者處理保留消息和遺愿消息煮甥，并可以更改服務(wù)質(zhì)量（QoS）等級(jí)。

MQTT控制報(bào)文

MQTT協(xié)議工作在TCP之上藕赞，端和代理之間通過交換預(yù)先定義的控制報(bào)文來完成通信成肘。MQTT報(bào)文有3個(gè)部分組成，并按下表順序出現(xiàn)：

固定報(bào)頭（fixed header） 可變報(bào)頭（variable header） 荷載（payload）
所有報(bào)文都包含 部分報(bào)文包含 部分報(bào)文包含

所有的MQTT控制報(bào)文都有一個(gè)固定報(bào)頭斧蜕，期格式如下：

image

協(xié)議版本3定義了14種MQTT報(bào)文双霍，用于建立/斷開連接、發(fā)布消息批销、訂閱消息和維護(hù)連接洒闸。固定報(bào)頭的第一字節(jié)的4-7位的值指定了報(bào)文類型，其取值如下表风钻。0和15為系統(tǒng)保留值；0-3位為標(biāo)志位酒请，依照?qǐng)?bào)文類型有不同的含義骡技，事實(shí)上，除了PUBLISH報(bào)文以外羞反，其他報(bào)文的標(biāo)志位均為系統(tǒng)保留布朦。如果收到報(bào)文的標(biāo)志位無效，代理應(yīng)斷開連接昼窗。

報(bào)文類型 值 描述
CONNECT 1 客戶端向代理發(fā)起連接請(qǐng)求
CONNACK 2 連接確認(rèn)
PUBLISH 3 發(fā)布消息
PUBACK 4 發(fā)布確認(rèn)
PUBREC 5 發(fā)布收到（QoS2）
PUBREL 6 發(fā)布釋放（QoS2）
PUBCOMP 7 發(fā)布完成（QoS2）
SUBSCRIBE 8 客戶端向代理發(fā)起訂閱請(qǐng)求
SUBACK 9 訂閱確認(rèn)
UNSUBSCRIBE 10 取消訂閱
UNSUBACK 11 取消訂閱確認(rèn)
PINGREQ 12 PING請(qǐng)求
PINGRESP 13 PING響應(yīng)
DISCONNECT 14 斷開連接

固定報(bào)頭的第二字節(jié)起表示報(bào)文的剩余長(zhǎng)度是趴。最大4個(gè)字節(jié)，每字節(jié)可以編碼至127澄惊，并含有一位繼續(xù)位唆途，如繼續(xù)位非0富雅，則下一字節(jié)依然為剩余長(zhǎng)度。由此肛搬，理論上一個(gè)控制報(bào)文最長(zhǎng)可以到256MB没佑。

一些報(bào)文在固定報(bào)頭和荷載之間可以有一個(gè)可變報(bào)頭∥屡猓可變報(bào)頭的內(nèi)容根據(jù)報(bào)文類型不同而不同蛤奢。最常見的可變報(bào)頭是報(bào)文標(biāo)識(shí)符（PacketIdentifier）。

一些報(bào)文可以在最后攜帶一個(gè)荷載陶贼。不同的報(bào)文可以無荷載啤贩，可選荷載，或必須帶有荷載拜秧。

限于篇幅痹屹，在這里我們僅以CONNECT和CONNACK為例解釋一下MQTT報(bào)文的構(gòu)成和報(bào)文響應(yīng)行為。其他報(bào)文請(qǐng)查閱MQTT標(biāo)準(zhǔn)文檔腹纳。

CONNECT報(bào)文

限于篇幅痢掠，在這里我們僅以CONNECT為例解釋一下MQTT報(bào)文的構(gòu)成。其他報(bào)文請(qǐng)查閱MQTT標(biāo)準(zhǔn)文檔嘲恍。
CONNECT是客戶端連接到代理的第一個(gè)報(bào)文足画，如果在連接已經(jīng)存在，代理收到該報(bào)文將會(huì)斷開現(xiàn)有連接佃牛。

CONNECT報(bào)文的固定報(bào)頭

image

CONNECT報(bào)文的可變報(bào)頭

CONNECT報(bào)文的可變報(bào)頭由4部分組成：

  • 協(xié)議名淹辞。協(xié)議名是UTF-8編碼的大寫的MQTT。
  • 協(xié)議級(jí)別俘侠。MQTT 3.1.1的協(xié)議級(jí)別為4.
  • 連接標(biāo)志位象缀。定義連接行為的參數(shù)。見下表爷速。
  • Keep Alive央星。2字節(jié)，客戶端和代理之間的無活動(dòng)時(shí)間超過該值后惫东，應(yīng)關(guān)閉連接莉给。如果該值置0表示客戶端不要求代理啟用KEEPALIVE功能。

連接標(biāo)志位：

位 7 6 5 4 3 2 1 0
用戶名 密碼 保留遺愿 遺愿QoS 遺愿QoS 遺愿 清除會(huì)話 保留（0）

清除會(huì)話標(biāo)志位：
這個(gè)標(biāo)志位定義了如何處理會(huì)話狀態(tài)廉沮。如果設(shè)置為0颓遏，客戶端和代理可以恢復(fù)上一次連接時(shí)的會(huì)話狀態(tài)，如果上一次連接的會(huì)話狀態(tài)不存在滞时，代理將會(huì)為客戶端建立一個(gè)新的會(huì)話叁幢。如果該位設(shè)置為1，則雙方將清除掉上一次連接的會(huì)話狀態(tài)并建立一個(gè)新的會(huì)話坪稽。

遺愿標(biāo)志位：
如果遺愿標(biāo)志為1曼玩，則遺愿消息會(huì)被存儲(chǔ)在代理上鳞骤，當(dāng)連接關(guān)閉時(shí)，代理將發(fā)布這個(gè)消息演训，除非在客戶端斷開連接時(shí)把遺愿消息清除了弟孟。

遺愿QoS標(biāo)志位：
指定了遺愿消息的服務(wù)質(zhì)量等級(jí)。

保留遺愿消息標(biāo)志位：
指定在發(fā)布遺愿消息的時(shí)候样悟，是否把該消息作為保留消息存儲(chǔ)在代理拂募。

用戶名標(biāo)志位：
如果設(shè)置為1，則用戶名必須出現(xiàn)在荷載中窟她，反之陈症，用戶名不允許出現(xiàn)在荷載中。

密碼標(biāo)志位：
如果該位為1震糖，則密碼必須出現(xiàn)在荷載中录肯；如果該位為0，則密碼不允許出現(xiàn)在荷載中吊说。如果用戶名標(biāo)志位為0论咏，則該位必須也為0。

CONNECT報(bào)文的荷載

CONNECT報(bào)文的荷載由一個(gè)或者多個(gè)字段組成颁井，這些字段是否出現(xiàn)由可變報(bào)頭中的標(biāo)志位決定厅贪。字段總是以長(zhǎng)度開始。字段出現(xiàn)的順序必須是：客戶端標(biāo)識(shí)符雅宾，遺愿主題养涮，遺愿消息，用戶名眉抬，密碼贯吓。

CONNECT報(bào)文的響應(yīng)

在代理在為MQTT協(xié)議開放的端口上接收到TCP連接請(qǐng)求并建立連接后應(yīng)該會(huì)收到CONNECT報(bào)文，如果在一定時(shí)間內(nèi)代理沒有收到CONNECT報(bào)文蜀变，則應(yīng)該關(guān)閉這個(gè)TCP連接悄谐。
在收到CONNECT報(bào)文后，代理應(yīng)該檢查報(bào)文格式是否符合協(xié)議標(biāo)準(zhǔn)库北。如果不符合協(xié)議標(biāo)準(zhǔn)爬舰，代理應(yīng)關(guān)閉連接，且不發(fā)送CONNACK報(bào)文給客戶端贤惯。
代理可以檢查CONNECT報(bào)文的內(nèi)容并執(zhí)行響應(yīng)的認(rèn)證和鑒權(quán)赦肃。如果這些檢查沒有通過裙戏，代理應(yīng)該向客戶端發(fā)送一個(gè)帶有非0返回碼的CONNACK報(bào)文。

CONNACK報(bào)文

CONNACK是代理用來響應(yīng)客戶端CONNECT的報(bào)文绢彤。代理向客戶端發(fā)送的第一個(gè)報(bào)文必須是CONNACT烟很。CONNACK有一個(gè)固定報(bào)頭颈墅，一個(gè)可變報(bào)頭蜡镶，但是不帶有荷載。

CONNACK的固定報(bào)頭

image

CONNACT報(bào)文只有固定報(bào)頭和一個(gè)2字節(jié)的可變報(bào)頭恤筛，所以它的剩余長(zhǎng)度總是2官还。

CONNACK報(bào)文的可變報(bào)頭

CONNACK報(bào)文的可變報(bào)頭為定長(zhǎng)2字節(jié)。第一字節(jié)的0位表示是否有會(huì)話存在毒坛。如果代理上已經(jīng)有請(qǐng)求連接的客戶端的會(huì)話望伦，且連接請(qǐng)求的清除會(huì)話標(biāo)識(shí)為0，則該位為1煎殷，否則該位為0屯伞。客戶端可以根據(jù)這一位的值采取響應(yīng)行為豪直，比如（重新）訂閱主題等劣摇。

CONNACK報(bào)文的可變報(bào)頭的第二字節(jié)為返回碼。如果CONNECT請(qǐng)求的格式正確弓乙，但是代理依然不能允許客戶端連接末融，則返回碼為一個(gè)非零值。如果連接成功暇韧，則返回0勾习。

返回碼的定義：

值 返回碼含義
0 成功，連接請(qǐng)求被接受锨咙。
1 拒絕連接语卤，不可接受的協(xié)議版本。
2 拒絕連接酪刀，不被允許的身份識(shí)別符（Client Identifier）粹舵。
3 拒絕連接，服務(wù)器不可用骂倘。
4 拒絕連接眼滤，無效的用戶名和密碼。
5 拒絕連接历涝，客戶端無授權(quán)诅需。
6-255 系統(tǒng)保留。

客戶端接受到代理的CONNACK的返回碼為0荧库，則連接建立完成堰塌，雙方可以開始通信。

清除會(huì)話分衫、保留消息和QoS的組合

清除會(huì)話场刑、保留消息等概念，在傳統(tǒng)的客戶端/服務(wù)器方式的通信中不一定會(huì)出現(xiàn)蚪战，這些概念有時(shí)候不太容易理解牵现，特別是當(dāng)他們被組合起來用的時(shí)候铐懊。

下面的表格匯總了當(dāng)一個(gè)客戶端連接上來時(shí)，它能收到消息的各種情況瞎疼。

清除會(huì)話位 保留位 訂閱QoS 發(fā)布QoS 可收到的消息
Y N 0 0 N
Y N 0 1 N
Y N 1 0 N
Y N 1 1 N
N N 0 0 N
N N 0 1 N
N N 1 0 N
N N 1 1 Y科乎，會(huì)話全部消息
Y Y 0 0 Y，最后一條消息
Y Y 0 1 Y贼急，最后一條消息
Y Y 1 0 Y茅茂，最后一條消息
Y Y 1 1 Y，最后一條消息
N Y 0 0 Y太抓，最后一條消息
N Y 0 1 Y玉吁，最后一條消息
N Y 1 0 Y，最后一條消息
N Y 1 1 Y腻异，會(huì)話全部消息

MQTT 5.0 協(xié)議新增介紹

MQTT 5.0 協(xié)議相比 MQTT 3.1.1 協(xié)議新增了許多內(nèi)容进副， 比如說屬性，AUTH 包悔常，還有對(duì)一些字段做了修改影斑，比如將 Clean Session 修改成 Clean Start 配合 Session Expiry Internal 去實(shí)現(xiàn)更靈活的會(huì)話控制。

這里就簡(jiǎn)單羅列一下 5.0 協(xié)議新增的內(nèi)容机打。

設(shè)計(jì)目標(biāo)

  • 增強(qiáng)了擴(kuò)展性
  • 改善了錯(cuò)誤報(bào)告的方式
  • 定型了一些通用范式矫户，例如能力發(fā)現(xiàn)和請(qǐng)求、響應(yīng)
  • 擴(kuò)展機(jī)制包括用戶屬性(user properties)
  • 性能改善残邀，并且添加了對(duì)小客戶端（small clients） 的支持

讀者可以參考MQTT5.0協(xié)議規(guī)范的附錄C來了解協(xié)議變更皆辽。

屬性

為了達(dá)成新協(xié)議的設(shè)計(jì)目標(biāo)，MQTT 5.0 協(xié)議中新增了許多屬性芥挣，以下是新添加的屬性列表驱闷。

標(biāo)識(shí)符 Identifier(十進(jìn)制) 標(biāo)識(shí)符 Identifier(十六進(jìn)制) 名稱（用法）Name(usage) 類型 Type 報(bào)文/遺囑屬性 Packet/Will Properties
1 0x01 有效載荷格式指示器 Payload Format Indicator 字節(jié) PUBLISH, 遺囑屬性 Will Properties
2 0x02 消息到期間隔 Message Exipiry Interval 四字節(jié)整形 PUBLISH，遺囑屬性
3 0x03 內(nèi)容類型 Content Type UTF-8 編碼字符串 PUBLISH空免，遺囑屬性
8 0x08 響應(yīng)主題 Response Topic UTF-8 編碼字符串 PUBLISH空另，遺囑屬性
9 0x09 關(guān)聯(lián)數(shù)據(jù) Correlation Data 二進(jìn)制數(shù)據(jù) Binary Data PUBLISH，遺囑屬性
11 0x0B 訂閱標(biāo)識(shí)符 Subscription Identifier 可變字節(jié)整形 PUBLISH, SUBSCRIBE
17 0x11 會(huì)話到期間隔 Session Expiry Interval 四字節(jié)整形 CONNECT, CONNACK, DISCONNECT
18 0x12 已分配客戶端標(biāo)識(shí)符 Assigned Client Identifier UTF-8 編碼字符串 CONNACK
19 0x13 服務(wù)器碧Ｑ猓活 Server Keep Alive 兩字節(jié)整形 CONNACK
21 0x15 認(rèn)證方法 Authentication Method UTF-8 編碼字符串 CONNECT, CONNACK, AUTH
22 0x16 認(rèn)證數(shù)據(jù) Authentication Data 二進(jìn)制數(shù)據(jù) CONNECT, CONNACK, AUTH
23 0x17 請(qǐng)求響應(yīng)信息 Request Response Information 字節(jié) CONNECT
24 0x18 遺囑延遲間隔 Will Delay Interval 四字節(jié)整形 遺囑屬性 Will Properties
25 0x19 請(qǐng)求響應(yīng)信息 Request Response Information 字節(jié) CONNECT
26 0x1A 響應(yīng)信息 Response Information UTF-8 編碼字符串 CONNACK, DISCONNECT
28 0x1C 服務(wù)器引用 Server Reference UTF-8 編碼字符串 CONNACK, DISCONNECT
31 0x1F 原因字符串 Reason String UTF-8 編碼字符串 CONNACK, PUBACK, PUBREC, PUBREL, PUBCOMP, SUBACK,UNSUBACK, DISCONNECT, AUTH
33 0x21 接收最大值 Receive Maximum 兩字節(jié)整形 CONNECT, CONNACK
34 0x22 主題別名最大值 Topic Alias Maximum 兩字節(jié)整形 CONNECT, CONNACK
35 0x23 主題別名 Topic Alias 兩字節(jié)整形 PUBLISH
36 0x24 服務(wù)質(zhì)量最大值 Maximum QoS 字節(jié) CONNACK
37 0x25 保留可用 Retain Available 字節(jié) CONNACK
38 0x26 用戶屬性 User Property UTF-8 字符串對(duì) UTF-8 String Pair CONNECT, CONNACK, PUBLISH, PUBACK, PUBREC, PUBREL, PUBCOMP, SUBACK, UNSUBACK, DISCONNECT, AUTH
39 0x27 最大報(bào)文大小 Maximum Packet Size 四字節(jié)整形 CONNECT, CONNACK
40 0x28 可用通配符訂閱 Wildcard Subscription Available 字節(jié) CONNACK
41 0x29 可用訂閱標(biāo)識(shí)符 Subscription Identifier Available Byte CONNACK
42 0x2A 可用共享訂閱 Shared Subscription Available 字節(jié) CONNACK

原因碼

MQTT v3.1.1 只有寥寥 6 個(gè)返回碼扼菠，用來表示網(wǎng)絡(luò)連接時(shí)可能會(huì)出現(xiàn)的異常行為，在引入屬性后的 MQTT 5.0 協(xié)議中坝咐，僅僅這 6 個(gè)返回碼顯然已經(jīng)不足以用來描述各種異常行為循榆，因此MQTT 5.0 協(xié)議中將返回碼改成了原因碼，用來實(shí)現(xiàn)改善錯(cuò)誤報(bào)告的目的墨坚。

原因碼（十進(jìn)制） 原因碼（十六進(jìn)制） 名稱 報(bào)文
0 0x00 成功 Success CONNACK, PUBACK, PUBREC, PUBREL, PUBCOMP, UNSUBACK, AUTH
0 0x00 正常斷連 Normal disconnection DISCONNECT
0 0x00 準(zhǔn)許 QoS 0 Granted QoS 0 SUBACK
1 0x01 準(zhǔn)許 QoS 1 Granted QoS 1 SUBACK
2 0x02 準(zhǔn)許 QoS 2 Granted QoS 2 SUBACK
4 0x04 以遺囑消息斷開連接 Disconnect with Will Message DISCONNECT
16 0x10 沒有匹配的訂閱者 No matching subscribers PUBACK, PUBREC
17 0x11 沒有訂閱 No subscription existed UNSUBACK
24 0x18 繼續(xù)認(rèn)證 Continue authentication AUTH
25 0x19 重新認(rèn)證 Re-authenticate AUTH
128 0x80 未指定錯(cuò)誤 Unspecified error CONNACK, PUBACK, PUBREC, SUBACK, UNSUBACK, DISCONNECT
129 0x81 畸形報(bào)文 Malformed Packet CONNACK, DISCONNECT
130 0x82 協(xié)議錯(cuò)誤 Protocol Error CONNACK, DISCONNECT
131 0x83 實(shí)現(xiàn)特有錯(cuò)誤 Implementation specific error CONNACK, PUBACK, PUBREC, SUBACK, UNSUBACK, DISCONNECT
132 0x84 不支持的協(xié)議版本 Unsupported Protocol Version CONNACK
133 0x85 客戶端標(biāo)識(shí)符無效 Client Identifier not valid CONNACK
134 0x86 錯(cuò)誤的用戶名和密碼 Bad User Name or Password CONNACK
135 0x87 未授權(quán) Not authorized CONNACK, PUBACK, PUBREC, SUBACK, UNSUBACK, DISCONNECT
136 0x88 服務(wù)器不可用 Server unavailable CONNACK
137 0x89 服務(wù)器繁忙 Server busy CONNACK, DISCONNECT
138 0x8A 禁止訪問 Banned CONNACK
139 0x8B 服務(wù)器關(guān)機(jī)中 Server shutting down DISCONNECT
140 0x8C 錯(cuò)誤驗(yàn)證方法 Bad authentication method CONNACK, DISCONNECT
141 0x8D 毖硪活超時(shí) Keep Alive timeout DISCONNECT
142 0x8E 會(huì)話被接管 Session taken over DISCONNECT
143 0x8F 主題過濾器無效 Topic Filter invalid SUBACK, UNSUBACK, DISCONNECT
144 0x90 主題名無效 Topic Name invalid CONNACK, PUBACK, PUBREC, DISCONNECT
145 0x91 報(bào)文標(biāo)識(shí)符在使用中 Packet Identifier in use PUBACK, PUBREC, SUBACK, UNSUBACK=
146 0x92 沒有發(fā)現(xiàn)報(bào)文標(biāo)識(shí)符 Packet Identifier not found PUBREL, PUBCOMP
147 0x93 超出接收最大值 Receive Maximum exceeded DISCONNECT
148 0x94 主題別名無效 Topic Alias invalid DISCONNECT
149 0x95 報(bào)文太大 Packet too large CONNACK, DISCONNECT
150 0x96 消息傳輸速率太高 Message rate too high DISCONNECT
151 0x97 超出限額 Quota exceeded CONNACK, PUBACK, PUBREC, SUBACK, DISCONNECT
152 0x98 管理行為 Administrative action DISCONNECT
153 0x99 有效載荷格式無效 Payload format invalid PUBACK, PUBREC, DISCONNECT
154 0x9A 不支持消息保留 Retain not supported CONNACK, DISCONNECT
155 0x9B 不支持的QoS QoS not supported CONNACK, DISCONNECT
156 0x9C 使用另一臺(tái)服務(wù)器 Use another server CONNACK, DISCONNECT
157 0x9D 服務(wù)器被移除 Server moved CONNACK, DISCONNECT
158 0x9E 不支持的共享訂閱 Shared Subscription not supported SUBACK, DISCONNECT
159 0x9F 超出連接速率 Connection rate exceeded CONNACK, DISCONNECT
160 0xA0 最大連接時(shí)間 Maximum connect time DISCONNECT
161 0xA1 不支持的訂閱標(biāo)識(shí)符 Subscription Identifiers not supported SUBACK, DISCONNECT
162 0xA2 不支持的通配符訂閱 Wildcard Subscription not supported SUBACK, DISCONNECT

實(shí)際應(yīng)用

1.　由于主題別名（Topic Alias）的引入，使 MQTT PUBLISH 控制報(bào)文的體積更小，更便于在帶寬和網(wǎng)絡(luò)受限的物聯(lián)網(wǎng)環(huán)境下傳輸消息浦楣。

2.　AUTH 包的引入使 MQTT 協(xié)議擴(kuò)展了認(rèn)證方式，增加了詢問/響應(yīng)式的認(rèn)證方式咪辱，服務(wù)器或客戶端在發(fā)送 CONNECT 與接收 CONNACK 包之間交換 AUTH 報(bào)文來完成身份驗(yàn)證的流程振劳。

3.　由于很多嵌入式設(shè)備的 CPU 并沒有對(duì) AES 加密標(biāo)準(zhǔn)下的加密算法提供硬件級(jí)的支持，因此油狂，使用 AES 加密對(duì)嵌入式設(shè)備的硬件開銷是非常大的历恐，所以 MQTT 5.0 協(xié)議提供了新的加密算法 ChaCha20 ，ChaCha20 在軟件層面做加密和解密處理要比 AES 快得多专筷。因此也算是一大進(jìn)步弱贼，不過本人更希望 MQTT 下一版協(xié)議能夠增加對(duì) AEAD 加密算的支持。

總的來說磷蛹，MQTT 5.0 協(xié)議的內(nèi)容增加了很多吮旅，協(xié)議書的內(nèi)容幾乎是 MQTT 3.1.1 協(xié)議的兩倍，除了本文上述提到的這些新的變化味咳，還有很多非常細(xì)節(jié)的東西沒有在這里做詳細(xì)的介紹庇勃。基于 MQTT 5.0 協(xié)議現(xiàn)有的很多屬性槽驶，在實(shí)現(xiàn) MQTT 5.0 協(xié)議的時(shí)說不定還能挖掘出更多的有意思的新用法责嚷，不過這需要開發(fā)人員去多讀協(xié)議的具體細(xì)節(jié)，去更深入地理解 MQTT 5.0 協(xié)議掂铐。

EMQ作為在github中最流行的MQTT中間件罕拂，開始全面支持MQTT 5.0協(xié)議，讀者有興趣的話全陨，趕緊下載試用吧爆班。

下一步

讀完本文之后，不能光做不練啊辱姨，想試用一下MQTT嗎蛋济？請(qǐng)參考EMQ君的文章常見MQTT服務(wù)器搭建與試用。

參考信息

作者：轉(zhuǎn)自 EMQ

最后編輯于 ：
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請(qǐng)聯(lián)系作者
  • 人面猴
    序言：七十年代末炮叶，一起剝皮案震驚了整個(gè)濱河市碗旅，隨后出現(xiàn)的幾起案子，更是在濱河造成了極大的恐慌镜悉，老刑警劉巖祟辟，帶你破解...
    沈念sama閱讀 206,214評(píng)論 6贊 481
  • 死咒
    序言：濱河連續(xù)發(fā)生了三起死亡事件，死亡現(xiàn)場(chǎng)離奇詭異侣肄，居然都是意外死亡旧困，警方通過查閱死者的電腦和手機(jī)，發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 88,307評(píng)論 2贊 382
  • 救了他兩次的神仙讓他今天三更去死
    文/潘曉璐 我一進(jìn)店門，熙熙樓的掌柜王于貴愁眉苦臉地迎上來吼具，“玉大人僚纷，你說我怎么就攤上這事∞趾校” “怎么了怖竭？”我有些...
    開封第一講書人閱讀 152,543評(píng)論 0贊 341
  • 道士緝兇錄：失蹤的賣姜人
    文/不壞的土叔 我叫張陵，是天一觀的道長(zhǎng)陡蝇。 經(jīng)常有香客問我痊臭，道長(zhǎng)，這世上最難降的妖魔是什么登夫？ 我笑而不...
    開封第一講書人閱讀 55,221評(píng)論 1贊 279
  • ?港島之戀（遺憾婚禮）
    正文 為了忘掉前任广匙，我火速辦了婚禮，結(jié)果婚禮上恼策，老公的妹妹穿的比我還像新娘鸦致。我一直安慰自己，他們只是感情好涣楷，可當(dāng)我...
    茶點(diǎn)故事閱讀 64,224評(píng)論 5贊 371
  • 惡毒庶女頂嫁案：這布局不是一般人想出來的
    文/花漫 我一把揭開白布蹋凝。 她就那樣靜靜地躺著，像睡著了一般总棵。 火紅的嫁衣襯著肌膚如雪鳍寂。 梳的紋絲不亂的頭發(fā)上，一...
    開封第一講書人閱讀 49,007評(píng)論 1贊 284
  • 城市分裂傳說
    那天情龄，我揣著相機(jī)與錄音迄汛，去河邊找鬼。 笑死骤视，一個(gè)胖子當(dāng)著我的面吹牛鞍爱，可吹牛的內(nèi)容都是我干的。 我是一名探鬼主播专酗，決...
    沈念sama閱讀 38,313評(píng)論 3贊 399
  • 雙鴛鴦連環(huán)套：你想象不到人心有多黑
    文/蒼蘭香墨 我猛地睜開眼睹逃，長(zhǎng)吁一口氣：“原來是場(chǎng)噩夢(mèng)啊……” “哼！你這毒婦竟也來了祷肯？” 一聲冷哼從身側(cè)響起沉填，我...
    開封第一講書人閱讀 36,956評(píng)論 0贊 259
  • 萬榮殺人案實(shí)錄
    序言：老撾萬榮一對(duì)情侶失蹤，失蹤者是張志新（化名）和其女友劉穎佑笋，沒想到半個(gè)月后翼闹，有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體，經(jīng)...
    沈念sama閱讀 43,441評(píng)論 1贊 300
  • ?護(hù)林員之死
    正文 獨(dú)居荒郊野嶺守林人離奇死亡蒋纬，尸身上長(zhǎng)有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點(diǎn)故事閱讀 35,925評(píng)論 2贊 323
  • ?白月光啟示錄
    正文 我和宋清朗相戀三年猎荠，在試婚紗的時(shí)候發(fā)現(xiàn)自己被綠了坚弱。 大學(xué)時(shí)的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片。...
    茶點(diǎn)故事閱讀 38,018評(píng)論 1贊 333
  • 活死人
    序言：一個(gè)原本活蹦亂跳的男人離奇死亡关摇，死狀恐怖荒叶，靈堂內(nèi)的尸體忽然破棺而出，到底是詐尸還是另有隱情输虱，我是刑警寧澤些楣，帶...
    沈念sama閱讀 33,685評(píng)論 4贊 322
  • ?日本核電站爆炸內(nèi)幕
    正文 年R本政府宣布，位于F島的核電站悼瓮，受9級(jí)特大地震影響，放射性物質(zhì)發(fā)生泄漏艰猬。R本人自食惡果不足惜横堡，卻給世界環(huán)境...
    茶點(diǎn)故事閱讀 39,234評(píng)論 3贊 307
  • 男人毒藥：我在死后第九天來索命
    文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望冠桃。 院中可真熱鬧命贴，春花似錦、人聲如沸食听。這莊子的主人今日做“春日...
    開封第一講書人閱讀 30,240評(píng)論 0贊 19
  • 一樁弒父案，背后竟有這般陰謀
    文/蒼蘭香墨 我抬頭看了看天上的太陽樱报。三九已至葬项，卻和暖如春，著一層夾襖步出監(jiān)牢的瞬間迹蛤，已是汗流浹背民珍。 一陣腳步聲響...
    開封第一講書人閱讀 31,464評(píng)論 1贊 261
  • 情欲美人皮
    我被黑心中介騙來泰國(guó)打工， 沒想到剛下飛機(jī)就差點(diǎn)兒被人妖公主榨干…… 1. 我叫王不留盗飒，地道東北人嚷量。 一個(gè)月前我還...
    沈念sama閱讀 45,467評(píng)論 2贊 352
  • 代替公主和親
    正文 我出身青樓，卻偏偏與公主長(zhǎng)得像逆趣，于是被迫代替她去往敵國(guó)和親蝶溶。 傳聞我的和親對(duì)象是個(gè)殘疾皇子，可洞房花燭夜當(dāng)晚...
    茶點(diǎn)故事閱讀 42,762評(píng)論 2贊 345

推薦閱讀更多精彩內(nèi)容