之前有位讀者給我留言說想要了解一下什么是 MQTT 協(xié)議，順便還把我夸了一把，有點(diǎn)不好意思啦。

那么讀者的要求必須要滿足啊，所以現(xiàn)在 @一下這位小姐姐，來聽課啦！

什么是 MQTT 協(xié)議

MQTT 協(xié)議的全稱是 Message Queuing Telemetry Transport，翻譯為消息隊(duì)列傳輸探測，它是 ISO 標(biāo)準(zhǔn)下的一種基于發(fā)布 - 訂閱模式的消息協(xié)議，它是基于 TCP/IP 協(xié)議簇的，它是為了改善網(wǎng)絡(luò)設(shè)備硬件的性能和網(wǎng)絡(luò)的性能來設(shè)計(jì)的。MQTT 一般多用于 IoT 即物聯(lián)網(wǎng)上，廣泛應(yīng)用于工業(yè)級(jí)別的應(yīng)用場景，比如汽車、制造、石油、天然氣等。

在了解了 MQTT 的概念和應(yīng)用場景后，我們下來就來走進(jìn) MQTT 的學(xué)習(xí)中了，先來看一下 MQTT 有哪些概念。

MQTT 基礎(chǔ)

上面我們解釋了 MQTT 協(xié)議的基本概念，MQTT 協(xié)議總結(jié)一點(diǎn)就是一種輕量級(jí)的二進(jìn)制協(xié)議，MQTT 協(xié)議與 HTTP 相比具有一個(gè)明顯的優(yōu)勢：數(shù)據(jù)包開銷較小，數(shù)據(jù)包開銷小就意味著更容易進(jìn)行網(wǎng)絡(luò)傳輸。還有一個(gè)優(yōu)勢就是 MQTT 在客戶端容易實(shí)現(xiàn)，而且具有易用性，非常適合當(dāng)今資源有限的設(shè)備。

你可能對這些概念有些諱莫如深，為什么具有 xxx 這種特性呢？這就需要從 MQTT 的設(shè)計(jì)說起了。

MQTT 協(xié)議由 Andy Stanford-Clark (IBM) 和 Arlen Nipper（Arcom，現(xiàn)為 Cirrus Link）于 1999 年發(fā)明。 他們需要一種通過衛(wèi)星連接石油管道的協(xié)議，以最大限度地減少電池?fù)p耗和帶寬。所以他們?yōu)檫@個(gè)協(xié)議規(guī)定了幾種要求：

• 這個(gè)協(xié)議必須易于實(shí)現(xiàn)；
• 這個(gè)協(xié)議中的數(shù)據(jù)必須易于傳輸，消耗成本?。?/li>
• 這個(gè)協(xié)議必須提供服務(wù)質(zhì)量管理；
• 這個(gè)協(xié)議必須支持連續(xù)的會(huì)話控制
• 假設(shè)數(shù)據(jù)不可知，不強(qiáng)求傳輸數(shù)據(jù)的類型與格式，保持靈活性。

這些設(shè)計(jì)也是 MQTT 的精髓所在，MQTT 經(jīng)過不斷的發(fā)展，已經(jīng)成為了物聯(lián)網(wǎng) IoT 所必備的一種消息探測協(xié)議，官方強(qiáng)烈推薦使用的版本是 MQTT 5。

發(fā)布 - 訂閱模式

發(fā)布 - 訂閱模式我相信接觸消息中間件架構(gòu)的同學(xué)都聽過，這是一種傳統(tǒng)的客戶端 - 服務(wù)器架構(gòu)的替代方案，因?yàn)橐话銈鹘y(tǒng)的客戶端-服務(wù)器是客戶端能夠直接和服務(wù)器進(jìn)行通信。

但是發(fā)布 - 訂閱模式 pub/sub就不一樣了，發(fā)布訂閱模式會(huì)將發(fā)送消息的發(fā)布者 publisher與接收消息的訂閱者 subscribers進(jìn)行分離，publisher 與 subscribers 并不會(huì)直接通信，他們甚至都不清楚對方是否存在，他們之間的交流由第三方組件 broker 代理。

pub/sub 最重要的方面是 publisher 與 subscriber 的解藕，這種耦合度有下面三個(gè)維度：

• 空間解耦：publisher 與 subscriber 并不知道對方的存在，例如不會(huì)有 IP 地址和端口的交互，也更不會(huì)有消息的交互。
• 時(shí)間解藕：publisher 與 subscriber 并不一定需要同時(shí)運(yùn)行。
• 同步 Synchronization 解藕：兩個(gè)組件的操作比如 publish 和 subscribe 都不會(huì)在發(fā)布或者接收過程中產(chǎn)生中斷。

總之，發(fā)布/訂閱模式消除了傳統(tǒng)客戶-服務(wù)器之間的直接通信，把通信這個(gè)操作交給了 broker 進(jìn)行代理，并在空間、時(shí)間、同步三個(gè)維度上進(jìn)行了解藕。

可拓展性

pub/sub 比傳統(tǒng)的客戶端-服務(wù)器模式有了更好的拓展，這是由于 broker 的高度并行化，并且是基于事件驅(qū)動(dòng)的模式?？赏卣剐赃€體現(xiàn)在消息的緩存和消息的智能路由，還可以通過集群代理來實(shí)現(xiàn)數(shù)百萬的連接，使用負(fù)載均衡器將負(fù)載分配到更多的單個(gè)服務(wù)器上，這就是 MQTT 的深度應(yīng)用了。

你可能不明白什么是事件驅(qū)動(dòng)，我在這里解釋下事件驅(qū)動(dòng)的概念。

事件驅(qū)動(dòng)是一種編程范式，編程范式是軟件工程中的概念，它指的是一種編程方法或者說程序設(shè)計(jì)方式，比如說面向?qū)ο缶幊毯兔嫦蜻^程編程就是一種編程范式，事件驅(qū)動(dòng)中的程序流程會(huì)由諸如用戶操作（點(diǎn)擊鼠標(biāo)、鍵盤）、傳感器輸出或者從其他程序或傳遞的消息事件決定。事件驅(qū)動(dòng)編程是圖形用戶界面和其他應(yīng)用程序比如 Web 中使用的主要范式，這些應(yīng)用程序能夠響應(yīng)用戶輸入執(zhí)行某些操作為中心，這同時(shí)也適用于驅(qū)動(dòng)程序的編程。

消息過濾

在 pub/sub 的架構(gòu)模式中，broker 扮演著至關(guān)重要的作用，其中非常重要的一點(diǎn)就是 broker 能夠?qū)ο⑦M(jìn)行過濾，使每個(gè)訂閱者只接收自己感興趣的消息。

broker 有幾個(gè)可以過濾的選項(xiàng)

基于主題的過濾

MQTT 是基于 subject 的消息過濾的，每條消息都會(huì)有一個(gè) topic ，接收客戶端會(huì)向 borker 訂閱感興趣的 topic，訂閱后，broker 就會(huì)確?？蛻舳耸盏桨l(fā)布到 topic 中的消息。

基于內(nèi)容的過濾

在基于內(nèi)容的過濾中，broker 會(huì)根據(jù)特定的內(nèi)容過濾消息，接受客戶端會(huì)經(jīng)過過濾他們感興趣的內(nèi)容。這種方法的一個(gè)顯著的缺點(diǎn)就是必須事先知道消息的內(nèi)容，不能加密或者輕易修改。

基于類型的過濾

在使用面向?qū)ο蟮恼Z言時(shí)，基于消息（事件）的類型過濾是一種比較常見的過濾方式。

為了發(fā)布/訂閱系統(tǒng)的挑戰(zhàn)，MQTT 具有三個(gè)服務(wù)質(zhì)量級(jí)別，你可以指定消息從客戶端傳到 broker 或者從 broker 傳到客戶端，在 topic 的訂閱中，會(huì)存在 topic 沒有 subscriber 訂閱的情況，作為 broker 必須知道如何處理這種情況。

MQTT 與消息隊(duì)列的區(qū)別

我們現(xiàn)在知道，MQTT 是一種消息隊(duì)列傳輸探測協(xié)議，這種協(xié)議是看似是以消息隊(duì)列為基礎(chǔ)，但卻與消息隊(duì)列有所差別。

在傳統(tǒng)的消息隊(duì)列模式中，一條消息會(huì)存儲(chǔ)在消息隊(duì)列中等待被消費(fèi)，每個(gè)傳入的消息都存儲(chǔ)在消息隊(duì)列中，直到它被客戶端（通常稱之為消費(fèi)者）所接收，如果沒有客戶端消費(fèi)消息的話，這條消息就會(huì)存在消息隊(duì)列中等待被消費(fèi)。但是在消息隊(duì)列中，不會(huì)存在消息沒有客戶端消費(fèi)的情況，但是在 MQTT 中，確存在 topic 無 subscriber 訂閱的情況。

在傳統(tǒng)的消息隊(duì)列模式中，一條消息只能被一個(gè)客戶端所消費(fèi)，負(fù)載會(huì)分布在隊(duì)列的每個(gè)消費(fèi)者之間；而在 MQTT 中，每個(gè)訂閱者都會(huì)受到消息，每個(gè)訂閱者有相同的負(fù)載。

在傳統(tǒng)的消息隊(duì)列模式中，必須使用單獨(dú)的命令來顯式創(chuàng)建隊(duì)列，只有隊(duì)列創(chuàng)建后，才可以生產(chǎn)或者消費(fèi)消息；而在 MQTT 中，topic 比較靈活，可以即時(shí)創(chuàng)建。

HiveMQ 現(xiàn)在是開源的，HiveMQ 社區(qū)版實(shí)現(xiàn)了 MQTT broker 規(guī)范，并兼容了 MQTT 3.1、3.1.1 和 MQTT 5。HiveMQ MQTT Client 是一個(gè)基于 Java 的 MQTT 客戶端實(shí)現(xiàn)，兼容 MQTT 3.1.1 和 MQTT 5。這兩個(gè)項(xiàng)目都可以在 HiveMQ 的 github https://github.com/hivemq 上找到。

我們知道，broker 將 publisher 和 subscriber 進(jìn)行分離，因此客戶端的連接由 broker 代理，所以在我們深入理解 MQTT 之前，我們需要先知道客戶端和代理的含義。

MQTT 重要概念

MQTT client

當(dāng)我們討論關(guān)于客戶端的概念時(shí)，一般指的就是 MQTT Client，publisher 和 subscriber 都屬于 MQTT Client。之所以有發(fā)布者和訂閱者這個(gè)概念，其實(shí)是一種相對的概念，就是指當(dāng)前客戶端是在發(fā)布消息還是在接收消息，發(fā)布和訂閱的功能也可以由同一個(gè) MQTT Client 實(shí)現(xiàn)。

MQTT 客戶端是指運(yùn)行 MQTT 庫并通過網(wǎng)絡(luò)連接到 MQTT broker 的任何設(shè)備，這些設(shè)備可以從微控制器到成熟的服務(wù)器?；旧?，任何使用 TCP/IP 協(xié)議使用 MQTT 設(shè)備的都可以稱之為 MQTT Client。MQTT 協(xié)議的客戶端實(shí)現(xiàn)非常簡單直接。易于實(shí)施是 MQTT 非常適合小型設(shè)備的原因之一。 MQTT 客戶端庫可用于多種編程語言。 例如，Android、Arduino、C、C++、C#、Go、iOS、Java、JavaScript 和 .NET。

MQTT broker

與 MQTT client 對應(yīng)的就是 MQTT broker，broker 是任何發(fā)布/訂閱機(jī)構(gòu)的核心，根據(jù)實(shí)現(xiàn)的不同，代理可以處理多達(dá)數(shù)百萬連接的 MQTT client。

broker 負(fù)責(zé)接收所有消息，過濾消息，確定是哪個(gè) client 訂閱了每條消息，并將消息發(fā)送給對應(yīng)的 client，broker 還負(fù)責(zé)保存會(huì)話數(shù)據(jù)，這些數(shù)據(jù)包括訂閱的和錯(cuò)過的消息。broker 還負(fù)責(zé)客戶端的身份驗(yàn)證和授權(quán)。

MQTT Connection

MQTT 是基于 TCP/IP 協(xié)議基礎(chǔ)之上的，所以 MQTT 的 client 和 broker 都需要 TCP/IP 協(xié)議的支持。

MQTT 的連接總是在 client 和 broker 之間進(jìn)行，client 和 client 之間并不會(huì)相互連接。如果要發(fā)起連接的話，那么 client 就會(huì)向 broker 發(fā)起 CONNECT 消息，代理會(huì)使用 CONNACK 消息和狀態(tài)碼進(jìn)行響應(yīng)。一旦 client 和 broker 的連接建立后，broker 就會(huì)使客戶端的連接一直處于打開狀態(tài)，直到 client 發(fā)出斷開命令或者連接中斷。

消息報(bào)文

MQTT 的消息報(bào)文主要分為 CONNECT 和 CONNACK 消息。

CONNECT

我們上面提到了為了初始化連接，需要 client 向 broker 發(fā)送 CONNECT 消息，如果這個(gè) CONNECT 消息格式錯(cuò)誤或者打開套接字（因?yàn)榛?TCP/IP 協(xié)議棧需要初始化 Socket 連接）時(shí)間過長，亦或是發(fā)送連接消息時(shí)間過長的話，broker 就會(huì)關(guān)閉這條連接。

一個(gè) MQTT 客戶端發(fā)送一條 CONNECT 連接，這條 CONNECT 連接可能會(huì)包含下面這些信息：

我這里解釋一下這些信息都是什么概念

ClientId：顯而易見，這個(gè)就是每個(gè)客戶端的 ID 標(biāo)識(shí)，也就是連接到 MQTT broker 的每個(gè) client。這個(gè) ID 應(yīng)該是每個(gè) client 和 broker 唯一的，如果你不需要 broker 持有狀態(tài)的話，你可以發(fā)送一個(gè)空的 ClientId，空的 ClientId 會(huì)沒有任何狀態(tài)。在這種情況下，ClientSession 需要設(shè)置為 true，否則將會(huì)拒絕連接。

clientSession 是什么我們下面會(huì)說。

CleanSession：CleanSession 會(huì)話標(biāo)志會(huì)告訴 broker client 是否需要建立持久會(huì)話。在持久會(huì)話 （CleanSession = false）中，broker 存儲(chǔ) client 的所有訂閱以及服務(wù)質(zhì)量(Qos) 是 1 或 2 訂閱的 client 的所有丟失的消息。如果會(huì)話不是持久的（CleanSession = true），那么 broker 則不會(huì)為 client 存儲(chǔ)任何內(nèi)容并且會(huì)清除先前持久會(huì)話中的所有信息。

Username/Password ：MQTT 會(huì)發(fā)送 username 和 password 進(jìn)行 client 認(rèn)證和授權(quán)。如果此信息沒有經(jīng)過加密或者 hash ，那么密碼將會(huì)以純文本的形式發(fā)送。所以，一般強(qiáng)烈建議 username 和 password 要經(jīng)過加密安全傳輸。像 HiveMQ 這樣的 broker 可以與 SSL 證書進(jìn)行身份驗(yàn)證，因此不需要用戶名和密碼。LastWillxxx ：LastWillxxx 表示的是遺愿，client 在連接 broker 的時(shí)候?qū)?huì)設(shè)立一個(gè)遺愿，這個(gè)遺愿會(huì)保存在 broker 中，當(dāng) client 因?yàn)榉钦Ｔ驍嚅_與 broker 的連接時(shí)，broker 會(huì)將遺愿發(fā)送給訂閱了這個(gè) topic（訂閱遺愿的 topic）的 client。

keepAlive：keepAlive 是 client 在連接建立時(shí)與 broker 通信的時(shí)間間隔，通常以秒為單位。這個(gè)時(shí)間指的是 client 與 broker 在不發(fā)送消息下所能承受的最大時(shí)長。

在聊完 client 與 broker 之間發(fā)送建立連接的 CONNECT 消息后，我們再來聊一下 broker 需要對 CONNECT 進(jìn)行確認(rèn)的 CONNACK 消息。

CONNACK

當(dāng) broker 收到 CONNECT 消息時(shí)，它有義務(wù)回復(fù) CONNACK 消息進(jìn)行響應(yīng)。CONNACK 消息包括兩部分內(nèi)容

SessionPresent：會(huì)話當(dāng)前標(biāo)識(shí)，這個(gè)標(biāo)志會(huì)告訴 client 當(dāng)前 broker 是否有一個(gè)持久性會(huì)話與 client 進(jìn)行交互。SessionPresent 標(biāo)志和 CleanSession 標(biāo)志有關(guān)，當(dāng) client 在 CleanSession 設(shè)置為 true 的情況下連接時(shí)，SessionPresent 始終為 false，因?yàn)闆]有持久性會(huì)話可以使用。如果 CleanSession 設(shè)置為 false，則有兩種可能性，如果 ClientId 的會(huì)話信息可用，并且 broker 已經(jīng)存儲(chǔ)了會(huì)話信息，那么 SessionPresent 為 true，否則如果沒有 ClientId 的任何會(huì)話信息，那么 SessionPresent 為 false。

ReturnCode：CONNACK 消息中的第二個(gè)標(biāo)志是連接確認(rèn)標(biāo)志。這個(gè)標(biāo)志包含一個(gè)返回碼，告訴客戶端連接嘗試是否成功。連接確認(rèn)標(biāo)志有下面這些選項(xiàng)。

關(guān)于每個(gè)連接的詳細(xì)說明，可以參考

https://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html#_Toc398718035

消息類型

發(fā)布

當(dāng) MQTT client 在連接到 broker 之后就可以發(fā)送消息了，MQTT 使用的是基于 topic 主題的過濾。每條消息都應(yīng)該包含一個(gè) topic ，broker 可以使用 topic 將消息發(fā)送給感興趣的 client。除此之外，每條消息還會(huì)包含一個(gè)負(fù)載(Payload)，Payload 中包含要以字節(jié)形式發(fā)送的數(shù)據(jù)。

MQTT 是數(shù)據(jù)無關(guān)性的，也就是說數(shù)據(jù)是由發(fā)布者 - publisher 決定要發(fā)送的是 XML 、JSON 還是二進(jìn)制數(shù)據(jù)、文本數(shù)據(jù)。

MQTT 中的 PUBLISH 消息結(jié)構(gòu)如下。

Packet Identifier：這個(gè) PacketId 標(biāo)識(shí)在 client 和 broker 之間唯一的消息標(biāo)識(shí)。packetId 僅與大于零的 Qos 級(jí)別相關(guān)。

TopicName：主題名稱是一個(gè)簡單的字符串，/ 代表著分層結(jié)構(gòu)。

Qos：這個(gè)數(shù)字表示的是服務(wù)質(zhì)量水平，服務(wù)質(zhì)量水平有三個(gè)等級(jí)：0、1 和 2，服務(wù)級(jí)別決定了消息到達(dá) client 或者 broker 的保證類型，來決定消息是否丟失。

RetainFlag：這個(gè)標(biāo)志表示 broker 將最近收到的一條 RETAIN 標(biāo)志位為true的消息保存在服務(wù)器端（內(nèi)存或者文件）。

MQTT 服務(wù)器只會(huì)為每一個(gè) Topic 保存最近收到的一條 RETAIN 標(biāo)志位為true的消息。也就是說，如果MQTT 服務(wù)器上已經(jīng)為某個(gè) Topic 保存了一條 Retained 消息，當(dāng)客戶端再次發(fā)布一條新的 Retained 消息時(shí)，那么服務(wù)器上原來的那條消息會(huì)被覆蓋。

Payload：這個(gè)是每條消息的實(shí)際內(nèi)容。MQTT 是數(shù)據(jù)無關(guān)性的?？梢园l(fā)送任何文本、圖像、加密數(shù)據(jù)以及二進(jìn)制數(shù)據(jù)。

Dupflag：這個(gè)標(biāo)志表示該消息是重復(fù)的并且由于預(yù)期的 client 或者 broker 沒有確認(rèn)所以重新發(fā)送了一次。這個(gè)標(biāo)志僅僅與 Qos 大于 0 相關(guān)。

當(dāng) client 向 broker 發(fā)送消息時(shí)，broker 會(huì)讀取消息，根據(jù) Qos 的級(jí)別進(jìn)行消息確認(rèn)，然后處理消息。處理消息其實(shí)就是確定哪些 subscriber 訂閱了 topic 并將消息發(fā)送給他們。

最初發(fā)布消息的 client 只關(guān)心將 PUBLISH 消息發(fā)送給 broker，一旦 broker 收到 PUBLISH 消息，broker 就有責(zé)任將其傳遞給所有 subscriber。發(fā)布消息的 client 不會(huì)知道是否有人對發(fā)布的消息感興趣，同時(shí)也不知道多少 client 從 broker 收到了消息。

訂閱

client 會(huì)向 broker 發(fā)送 SUBSCRIBE 消息來接收有關(guān)感興趣的 topic，這個(gè) SUBSCRIBE 消息非常簡單，它包含了一個(gè)唯一的數(shù)據(jù)包標(biāo)識(shí)和一個(gè)訂閱列表。

Packet Identifier：這個(gè) PacketId 和上面的 PacketId 一樣，都表示消息的唯一標(biāo)識(shí)符。

ListOfSubscriptions：SUBSCRIBE 消息可以包含一個(gè) client 的多個(gè)訂閱，每個(gè)訂閱都會(huì)由一個(gè) topic 和一個(gè) Qos 構(gòu)成。訂閱消息中的 topic 可以包含通配符。

確認(rèn)消息

client 在向 broker 發(fā)送 SUBSCRIBE 消息后，為了確認(rèn)每個(gè)訂閱，broker 會(huì)向 client 發(fā)送 SUBACK 確認(rèn)消息。這個(gè) SUBACK 包含原始 SUBSCRIBE 消息的 packetId 和返回碼列表。

其中

Packet Identifier ：這個(gè)數(shù)據(jù)包標(biāo)識(shí)符和 SUBSCRIBE 中的相同。

ReturnCode：broker 為每個(gè)接收到的 SUBSCRIBE 消息的 topic/Qos 對發(fā)送一個(gè)返回碼。例如，如果 SUBSCRIBE 消息有五個(gè)訂閱消息，則 SUBACK 消息包含五個(gè)返回碼作為響應(yīng)。

到現(xiàn)在我們已經(jīng)探討過了三種消息類型，發(fā)布 - 訂閱 - 確認(rèn)消息，這三種消息的示意圖如下。

退訂

SUBSCRIBE 消息對應(yīng)的是 UNSUBSCRIBE 消息，這條消息發(fā)送后，broker 會(huì)刪除關(guān)于 client 的訂閱。所以，UNSUBSCRIBE 消息與 SUBSCRIBE 消息類似，都具有 packetId 和 topic 列表。

確認(rèn)退訂

取消訂閱也需要 broker 的確認(rèn)，此時(shí) broker 會(huì)向 client 發(fā)送一個(gè) UNSUBACK 消息，這個(gè) UNSUBACK 消息非常簡單，只有一個(gè) packetId 數(shù)據(jù)標(biāo)識(shí)符。

退訂和確認(rèn)退訂的流程如下。

當(dāng) client 收到來自 broker 的 UNSUBACK 消息后，就可以認(rèn)為 UNSUBSCRIBE 消息中的訂閱被刪除了。

聊聊 Topic

聊了這么多關(guān)于 MQTT 的內(nèi)容，但是我們還沒有好好聊過 Topic。在 MQTT 中，Topic 是指 broker 為每個(gè)連接的 client 過濾消息的 UTF-8 字符串。Topic 是一種分層的結(jié)構(gòu)，可以由一個(gè)或者多個(gè) Topic 組成。每個(gè) Topic 由 / 進(jìn)行分割。

與傳統(tǒng)的消息隊(duì)列相比，MQTT Topic 非常輕量級(jí)，client 在發(fā)布或訂閱之前不需要先創(chuàng)建所需要的 Topic，broker 在接收每個(gè) Topic 前不用進(jìn)行初始化操作。

通配符

當(dāng)客戶端訂閱 Topic 時(shí)，它可以訂閱已發(fā)布消息的確切 Topic，也可以使用通配符來同時(shí)訂閱多個(gè) Topic。通配符有兩種：單級(jí)和多級(jí)。

單級(jí)通配符

單級(jí)通配符可以替換 Topic 的一個(gè)級(jí)別，+ 號(hào)代表 Topic 中的單級(jí)通配符。

如果 Topic 包含任意字符串而不是通配符，則任何 Topic 都能夠和單級(jí)通配符匹配。例如

myhome/groundfloor/+/temperature 就有下面這幾種匹配方式。

多級(jí)通配符

多級(jí)通配符涵蓋多個(gè) Topic，# 代表 Topic 中的多級(jí)通配符。為了讓 broker 能夠確定和哪些 Topic 匹配，多級(jí)通配符必須作為 Topic 中的最后一個(gè)字符放置，并以 / 開頭。

下面是 myhome/groundfloor/# 的幾個(gè)例子

當(dāng) client 訂閱帶有多級(jí)通配符的 Topic 時(shí)，不論 Topic 有多長多深，它都會(huì)收到通配符之前 Topic 的所有消息。如果你只將 Topic 定義為 # 的話，那么你將會(huì)收到所有的消息。

以上就是計(jì)算機(jī)編程MQTT協(xié)議基礎(chǔ)原理詳解的詳細(xì)內(nèi)容，更多關(guān)于計(jì)算機(jī)編程MQTT協(xié)議的資料請關(guān)注腳本之家其它相關(guān)文章！

最新評論