上期文章中給大家介紹了MQTT規(guī)范版本5中基礎(chǔ)更改的信息和CONNACK返回碼，本篇文章我們繼續(xù)介紹MQTT5協(xié)議中的基礎(chǔ)更改中其他新功能的細(xì)節(jié)描述。

01 干凈啟動(dòng)

MQTT 3.1.1的其中一個(gè)主流功能是MQTT客戶端使用清除會(huì)話（cleanSession），即這些客戶端可以通過臨時(shí)連接的方式訂閱消息或根本不訂閱消息。當(dāng)連接到MQTT代理時(shí)，客戶端必須選擇發(fā)送一個(gè)標(biāo)注啟用或禁用清除會(huì)話的CONNECT數(shù)據(jù)包。

在MQTT客戶端使用清除會(huì)話后，一旦出現(xiàn)底層TCP連接斷開、或客戶端決定斷開與代理的連接的情況，代理將會(huì)丟棄MQTT客戶端的所有數(shù)據(jù)。此外，如果在代理上存在與客戶端標(biāo)識(shí)符關(guān)聯(lián)的先前會(huì)話，清除會(huì)話CONNECT數(shù)據(jù)包將強(qiáng)制MQTT代理刪除歷史數(shù)據(jù)。

在MQTT v5中，客戶端可以選擇使用干凈啟動(dòng)（Clean Start）（由 CONNECT 消息中的“干凈啟動(dòng)”標(biāo)志指示）。使用這個(gè)標(biāo)志時(shí)，代理會(huì)丟棄任何以前的會(huì)話數(shù)據(jù)，客戶端則會(huì)開啟新的會(huì)話。關(guān)閉客戶端和服務(wù)器之間的 TCP 連接后，會(huì)話不會(huì)被自動(dòng)清理。要在客戶端斷開連接后觸發(fā)會(huì)話刪除，必須將“會(huì)話到期間隔”的新頭字段設(shè)置為值 0。

新的Clean Start功能簡(jiǎn)化了 MQTT 的會(huì)話處理，因?yàn)樗峁┝烁蟮撵`活性，并且比 cleanSession/持久會(huì)話概念更易于實(shí)現(xiàn)。使用 MQTT 5，除非“會(huì)話到期間隔”為 0，否則所有會(huì)話都是持久的。在超時(shí)后或客戶端使用干凈啟動(dòng)重新連接時(shí)，將刪除會(huì)話。

02 額外的MQTT數(shù)據(jù)包

MQTT 5引入了一個(gè)新的MQTT數(shù)據(jù)包：AUTH數(shù)據(jù)包。這個(gè)新的數(shù)據(jù)包對(duì)于實(shí)現(xiàn)非簡(jiǎn)單的認(rèn)證機(jī)制非常有用。

AUTH數(shù)據(jù)包可以在建立連接后由MQTT代理和客戶端發(fā)送，以使用復(fù)雜的質(zhì)詢/響應(yīng)認(rèn)證方法（如SASL框架中定義的SCRAM或Kerberos）。也可以用于物聯(lián)網(wǎng)的最先進(jìn)的認(rèn)證方法，如OAuth。這個(gè)數(shù)據(jù)包還允許在不關(guān)閉連接的情況下對(duì)MQTT客戶端進(jìn)行重新認(rèn)證。

03 新的數(shù)據(jù)類型: UTF-8字符串對(duì)

自定義報(bào)頭的出現(xiàn)也需要引入一種新的數(shù)據(jù)類型：UTF-8字符串對(duì)。這種字符串對(duì)本質(zhì)上是一個(gè)鍵-值結(jié)構(gòu)，鍵和值都是字符串?dāng)?shù)據(jù)類型，這種數(shù)據(jù)類型目前只用于自定義報(bào)頭。

有了這種新的數(shù)據(jù)類型，MQTT在網(wǎng)絡(luò)上共有7種不同的數(shù)據(jù)類型可以使用：

Bit

Two Byte Integer

Four Byte Integer

UTF-8 Encoded String

Variable Byte Integer

Binary Data

UTF-8 String Pair

大多數(shù)用戶通常在其 MQTT 庫(kù)的 API 中使用二進(jìn)制數(shù)據(jù)和 UTF-8 編碼字符串。在 MQTT 5 中，UTF-8 字符串對(duì)也經(jīng)常被使用。所有其他數(shù)據(jù)類型對(duì)用戶是隱藏的，但會(huì)被MQTT客戶端和代理制作成網(wǎng)絡(luò)上有效的MQTT數(shù)據(jù)包。

04 雙向的DISCONNECT數(shù)據(jù)包

在MQTT 3.1.1中，客戶端可以通過在關(guān)閉底層TCP連接之前，發(fā)送一個(gè)DISCONNECT數(shù)據(jù)包來表明它想斷開連接。MQTT代理沒有辦法通知MQTT客戶端發(fā)生了什么，并且代理將關(guān)閉TCP連接。

這一點(diǎn)在新的MQTT5中有所改變，現(xiàn)在允許代理在關(guān)閉套接字之前發(fā)送一個(gè)“MQTT DISCONNECT”包。客戶端現(xiàn)在能夠解釋它被斷開連接的原因并采取相應(yīng)的行動(dòng)，代理不需要指出確切的原因（例如出于安全原因）。但至少對(duì)于開發(fā)中的應(yīng)用來說，這有助于找出代理關(guān)閉連接的原因。

當(dāng)然，DISCONNECT數(shù)據(jù)包可以攜帶Reason Codes，所以很容易指出斷開連接的原因（例如在無效權(quán)限的情況下）。

05 對(duì)QoS 1和2的消息不進(jìn)行重試

MQTT客戶端使用常設(shè)的TCP（或具有相同保證的類似協(xié)議）連接作為基礎(chǔ)傳輸。TCP連接正常時(shí)提供雙向連接，并且能保證消息符合恰好一次和按順序傳輸，因此所有客戶端或代理發(fā)送的MQTT數(shù)據(jù)包都會(huì)到達(dá)另一端。如果TCP連接中斷，而消息正在進(jìn)行時(shí)，QoS 1和2會(huì)通過多個(gè)TCP 連接提供消息傳遞保證。

MQTT 3.1.1允許在TCP連接正常時(shí)重新交付MQTT消息。實(shí)際上，這可能會(huì)導(dǎo)致過載的MQTT客戶端得到更多的過載。試想一下，一個(gè)MQTT客戶端從MQTT代理處收到一個(gè)消息，需要11秒來處理這個(gè)消息（并且在處理后會(huì)確認(rèn)數(shù)據(jù)包）?，F(xiàn)在假設(shè)，代理會(huì)在10秒的超時(shí)后重新發(fā)送消息。這種方法沒有任何優(yōu)勢(shì)，它只是占用了帶寬，并加重了MQTT客戶端的負(fù)荷。

06 使用沒有用戶名的密碼

MQTT 3.1.1要求MQTT客戶端在CONNECT數(shù)據(jù)包中使用密碼時(shí)要發(fā)送一個(gè)用戶名。對(duì)于某些用例來說，如果沒有用戶名是非常不方便的。使用 OAuth就是一個(gè)很好的例子，它使用 JSON Web 令牌作為唯一的身份驗(yàn)證和授權(quán)信息。在 MQTT 3.1.1 中使用此類令牌時(shí)，經(jīng)常使用靜態(tài)用戶名，因?yàn)槲ㄒ坏南嚓P(guān)信息在密碼字段中。

雖然MQTT 5 中有更簡(jiǎn)便的方式來攜帶令牌（例如通過 AUTH 數(shù)據(jù)包），但仍然可以使用 CONNECT 數(shù)據(jù)包的密碼字段。現(xiàn)在，用戶只需使用密碼字段，不再需要填寫用戶名。

07 虹科HiveMQ MQTT解決方案

虹科HiveMQ 是一個(gè)基于 MQTT 數(shù)據(jù)傳輸?shù)?a href="http://m.makelele.cn/v/tag/1301/" target="_blank">通信平臺(tái)，旨在將數(shù)據(jù)快速、高效、可靠地傳遞給連接的物聯(lián)網(wǎng)設(shè)備，HiveMQ 使用 MQTT 協(xié)議在設(shè)備和企業(yè)平臺(tái)之間進(jìn)行實(shí)時(shí)、雙向的數(shù)據(jù)推送。

虹科HiveMQ 的建立是為了解決企業(yè)在構(gòu)建新的物聯(lián)網(wǎng)應(yīng)用時(shí)面臨的一些關(guān)鍵技術(shù)挑戰(zhàn)，包括：

構(gòu)建可靠、可擴(kuò)展的關(guān)鍵業(yè)務(wù)物聯(lián)網(wǎng)應(yīng)用

快速的數(shù)據(jù)交付，以滿足終端用戶對(duì)響應(yīng)式物聯(lián)網(wǎng)產(chǎn)品的期望

通過有效利用硬件、網(wǎng)絡(luò)和云資源降低運(yùn)營(yíng)成本

將物聯(lián)網(wǎng)數(shù)據(jù)整合到現(xiàn)有的企業(yè)系統(tǒng)中

虹科HiveMQ 提供免費(fèi)版、專業(yè)版、企業(yè)版 MQTT Broker 產(chǎn)品，并提供 Kafka、企業(yè)安全及 MQTT Broker 橋接三種企業(yè)級(jí)擴(kuò)展套件，HiveMQ 還提供高效的 MQTT 客戶端及云平臺(tái)，多方位滿足用戶需求。

更多精彩資訊 歡迎關(guān)注博主

審核編輯黃宇