MQTT協(xié)議介紹之二：連接

ID:184786 · 發(fā)表于 2017-8-25 08:57

在機智云的整個架構(gòu)里面，如上圖，GAgent實現(xiàn)了從模塊到云端的數(shù)據(jù)交互，其實GAgent里面就是用MQTT協(xié)議實現(xiàn)的，可見MQTT協(xié)議的重要性。今天介紹MQTT的發(fā)布、訂閱和取消訂閱。

回顧

在上一篇文章中，我們解釋了發(fā)布/訂閱模式是如何工作的以及如何在MQTT中應(yīng)用，以下我們把要點回顧下：發(fā)布或者訂閱解耦一個客戶端，就是從另一個客戶端（或更多客戶端）發(fā)送特定消息（稱為發(fā)布者），為了確定哪個消息發(fā)送到哪個客戶端，MQTT使用了主題。主題是層次結(jié)構(gòu)的字符串，用于消息過濾和路由。

在上一章節(jié)的最后我又更具理論性的分析了，發(fā)布/訂閱是什么，以及如何從消息排隊方法中區(qū)分MQTT。這篇文章干貨將更多，主要介紹MQTT的基本知識。這一章，我們討論的主題是MQTT客戶端和代理服務(wù)器的定義以及MQTT連接的基礎(chǔ)知識，如何連接、連接需要的參數(shù)。

引言

我們已經(jīng)看看完了MQTT的發(fā)布和訂閱后，所有的設(shè)備都要和代理服務(wù)器連接的，我們在講連接之前應(yīng)該理解下客戶端和代理服務(wù)器。

客戶端

在文章中，我們討論的客戶端都是MQTT客戶端，說的發(fā)布者和訂閱者也都指的是MQTT客戶端的發(fā)布和訂閱（通常，MQTT客戶端可以同時發(fā)布和訂閱）MQTT客戶端是從微控制器到完整的服務(wù)器的任何設(shè)備，它具有運行的MQTT庫，并通過任何類型的網(wǎng)絡(luò)連接到MQTT代理。這是一個非常小且資源有限的設(shè)備它通過無線網(wǎng)絡(luò)連接，并且設(shè)定一定參數(shù)，或者運行圖形化MQTT客戶端的典型計算機用于測試目的，總的來說基本上是具有TCP / IP協(xié)議棧并在其上支持MQTT協(xié)議的任何設(shè)備。

MQTT協(xié)議的客戶端實現(xiàn)非常直觀，簡單，有人會問了，為什么MQTT非常適合小型設(shè)備呢？MQTT客戶端庫可用于各種各樣的編程語言，如Android, Arduino, C, C++, C#, Go, iOS, Java, JavaScript, .NET. 可以在維基百科上找到MQTT的完整的列表。

代理

MQTT客戶端的對應(yīng)方就是MQTT代理服務(wù)器，這是任何發(fā)布和訂閱協(xié)議的核心，根據(jù)具體實現(xiàn)情況，代理可以處理多達(dá)數(shù)千個并發(fā)連接的MQTT客戶端。代理主要負(fù)責(zé)接收所有消息，過濾它們，決定誰對其感興趣，然后將消息發(fā)送給相應(yīng)訂閱客戶端。它還擁有所有持久客戶端的會話，包括訂閱和錯過的消息。

代理的另一責(zé)任是給客戶端認(rèn)證和授權(quán)，而且在大多數(shù)時候，代理也是可擴展的，這樣可以輕松地自定義身份驗證，授權(quán)并且集成到后端系統(tǒng)中。集成是一個重要的方面，因為代理通常是直接暴露在互聯(lián)網(wǎng)上并處理大量客戶端的組件，然后將消息傳遞到下游分析和處理系統(tǒng)。

正如我們在我們早期博客中所描述的一樣，訂閱所有消息并不是一個真正的選擇，所有的代理都是中心樞紐，每個消息都需要通過它的。因此，重要的是，它具有高度可擴展性，可集成到后端系統(tǒng)中，這樣易于監(jiān)控，當(dāng)然也具有抗故障性，才能保障穩(wěn)定。例如，HiveMQ通過使用最先進的事件驅(qū)動網(wǎng)絡(luò)處理，一個開放的插件系統(tǒng)和標(biāo)準(zhǔn)的監(jiān)控為用戶提供服務(wù)。

MQTT連接

MQTT協(xié)議基于TCP / IP的，客戶端和代理都需要具有TCP / IP協(xié)議棧。

MQTT連接本身始終在一個客戶端和代理之間，沒有客戶端直接連接到另一個客戶端。通過客戶端向代理發(fā)送CONNECT消息來啟動連接。具有CONNACK的代理響應(yīng)并發(fā)送狀態(tài)代碼。建立連接后，只要客戶端沒有發(fā)送斷開連接命令或者斷開連接網(wǎng)絡(luò)，代理將一直保持打開狀態(tài)。

MQTT通過NAT連接

MQTT客戶端一般是連接路由器設(shè)備的，它們正在使用網(wǎng)絡(luò)地址轉(zhuǎn)換（NAT），以便從專用網(wǎng)絡(luò)地址（如192.168.x.x，10.0.x.x）轉(zhuǎn)換為面向公眾的公共網(wǎng)絡(luò)。如前所述，MQTT客戶端第一步就要要發(fā)送CONNECT消息。因此，NAT后面的客戶端沒有任何問題，因為代理具有公共地址，并且連接將保持打開，以允許在初始CONNECT之后雙向發(fā)送和接收消息。

客戶端發(fā)起與代理的連接消息

下面讓我們看看MQTT客戶端發(fā)送的連接信息。前面已經(jīng)提到，這是從客戶端到代理發(fā)起連接。如果CONNECT消息格式錯誤（根據(jù)MQTT規(guī)范）或打開網(wǎng)路超時，代理將關(guān)閉連接。這是合理的行為，這樣可以避免惡意客戶端攻擊，減慢代理的速度。

一個完好的客戶端將發(fā)送一個包含以下內(nèi)容的連接消息：

此外，CONNECT消息中還包含其他信息，這對MQTT庫的編寫者而言比對庫的使用者更加關(guān)心。如果您對詳細(xì)信息有興趣，請查看MQTT 3.1.1規(guī)范。

下面讓我們逐個瀏覽所有這些項目參數(shù)吧：

ClientId

客戶端標(biāo)識符（簡稱ClientId）是連接到MQTT代理的每個MQTT客戶端的標(biāo)識符。正如標(biāo)識符的含義那樣，每個代理應(yīng)該是唯一的。代理使用它來識別客戶端和客戶端的當(dāng)前狀態(tài)。如果不需要一個狀態(tài)來保持代理，在MQTT 3.1.1（當(dāng)前標(biāo)準(zhǔn)）中，也可以發(fā)送一個空的ClientId。這導(dǎo)致沒有任何狀態(tài)的連接，條件是 Clean Session是真的，否則連接將被拒絕。

Clean Session

Clean Session標(biāo)志指示代理，客戶端是否要建立持久會話。持久會話（CleanSession為假）表示代理將存儲客戶端的所有訂閱以及所有錯過的信息。當(dāng)使用服務(wù)質(zhì)量（QoS）1或2進行訂閱時。如果Clean Session設(shè)置為真，則代理不會為客戶端存儲任何東西，并且還將清除以前持續(xù)會話中的所有信息。

Username/Password

MQTT允許發(fā)送用于驗證客戶端的用戶名和密碼以及授權(quán)。然而，密碼是以明文形式發(fā)送的，如果它沒有通過實現(xiàn)加密或散列，或者使用TLS。我們強烈建議使用用戶名和密碼以及安全的傳輸，在像HiveMQ這樣的代理中，也可以使用SSL證書對客戶端進行身份驗證，因此不需要用戶名和密碼。

Will Message

Will Message是MQTT的最后一個意愿和遺囑特征的一部分。它允許通知其他客戶端，當(dāng)客戶端不正常地斷開連接。連接客戶端將在CONNECT消息中以MQTT消息和主題的形式提供他的意愿。如果客戶端不正常地斷開連接，代理客戶端會發(fā)送此消息。我們會在后面的文章中單獨介紹一下。

KeepAlive

KeepAlive是一個時間間隔，客戶端通過向代理發(fā)送常規(guī)PING請求消息。代理將與PING響應(yīng)，這種機制將確定雙方是否仍然存在和正常通信。這個我們將在以后的一篇文章中詳細(xì)介紹一下。這基本上都是從MQTT客戶端連接到MQTT代理所需的所有信息。每個MQTT庫通常都會有其他選項，可以進行具體配置。

代理回應(yīng)CONNACK消息

當(dāng)代理獲得CONNECT消息時，代理有義務(wù)使用CONNACK消息進行響應(yīng)。CONNACK只包含兩個數(shù)據(jù)條目：會話存在標(biāo)志，連接確認(rèn)標(biāo)志。

會話存在標(biāo)志

會話存在標(biāo)志指示，代理是否已經(jīng)具有來自先前交互的客戶端的持久會話。如果客戶端連接并將CleanSession設(shè)置為真，則此標(biāo)志始終為假，因為沒有會話可用。如果客戶端將CleanSession設(shè)置為假，則該標(biāo)志取決于該ClientId是否存在可用于的會話信息。如果存儲會話信息，則該標(biāo)志為真，否則為假。該標(biāo)志在MQTT 3.1.1中新添加，并幫助客戶端確定是否必須訂閱主題，或者是否仍然存儲在他的會話中。