MQTT 5協(xié)議中的基礎(chǔ)更改（二）

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

虹 科 干 貨

01

干凈啟動

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

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

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

新的Clean Start功能簡化了 MQTT 的會話處理，因為它提供了更大的靈活性，并且比 cleanSession/持久會話概念更易于實現(xiàn)。使用 MQTT 5，除非“會話到期間隔”為 0，否則所有會話都是持久的。在超時后或客戶端使用干凈啟動重新連接時，將刪除會話。

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

02

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

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

03

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

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

有了這種新的數(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 庫的 API 中使用二進制數(shù)據(jù)和 UTF-8 編碼字符串。在 MQTT 5 中，UTF-8 字符串對也經(jīng)常被使用。所有其他數(shù)據(jù)類型對用戶是隱藏的，但會被MQTT客戶端和代理制作成網(wǎng)絡(luò)上有效的MQTT數(shù)據(jù)包。

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

04

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

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

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

05

對QoS 1和2的消息不進行重試

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

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

使用沒有用戶名的密碼

06

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

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

07

虹科HiveMQ MQTT解決方案

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

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

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

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

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

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

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