我們今天就來詳細(xì)的說說這個 MQTT 協(xié)議，因為很多消息現(xiàn)在都是支持 MQTT 協(xié)議的，比如 RabbitMQ ，還有 Kafka 等，今天我們就來詳細(xì)的介紹 MQTT 協(xié)議到底是個什么。

什么是MQTT協(xié)議

MQTT協(xié)議是一種消息列隊傳輸協(xié)議，采用訂閱、發(fā)布機制，訂閱者只接收自己已經(jīng)訂閱的數(shù)據(jù)，非訂閱數(shù)據(jù)則不接收，既保證了必要的數(shù)據(jù)的交換，又避免了無效數(shù)據(jù)造成的儲存與處理。因此在在物聯(lián)網(wǎng)領(lǐng)域，傳感器與服務(wù)器的通信，信息的收集中得到廣泛的應(yīng)用。

既然是協(xié)議，那么如果對比 TCP/IP協(xié)議的話，它位于分層中的哪一層呢?

之前阿粉就說了 TCP/IP 參考模型可以分為四層：應(yīng)用層、運輸層、網(wǎng)絡(luò)層、網(wǎng)絡(luò)接口層。TCP和UDP位于運輸層，應(yīng)用層常見的協(xié)議有HTTP、FTP、SSH等。而 MQTT 協(xié)議運行于 TCP 之上，屬于應(yīng)用層協(xié)議，因此只要是支持TCP/IP協(xié)議棧的地方，都可以使用MQTT。

MQTT協(xié)議主要特性

1)開放消息協(xié)議，簡單易實現(xiàn)。

2)使用發(fā)布/訂閱消息模式，提供一對多的消息發(fā)布，解除應(yīng)用程序耦合。

3)對負(fù)載(協(xié)議攜帶的應(yīng)用數(shù)據(jù))內(nèi)容屏蔽的消息傳輸。

4)基于TCP/IP網(wǎng)絡(luò)連接,提供有序，無損，雙向連接。

主流的MQTT是基于TCP連接進行數(shù)據(jù)推送的，但是同樣有基于UDP的版本，叫做MQTT-SN。這兩種版本由于基于不同的連接方式，優(yōu)缺點自然也就各有不同了。

5)消息服務(wù)質(zhì)量(QoS)支持，可靠傳輸保證;有三種消息發(fā)布服務(wù)質(zhì)量：

QoS0："至多一次"，消息發(fā)布完全依賴底層TCP/IP網(wǎng)絡(luò)。會發(fā)生消息丟失或重復(fù)。這一級別可用于如下情況，環(huán)境傳感器數(shù)據(jù)，丟失一次讀記錄無所謂，因為不久后還會有第二次發(fā)送。這一種方式主要普通APP的推送，倘若你的智能設(shè)備在消息推送時未聯(lián)網(wǎng)，推送過去沒收到，再次聯(lián)網(wǎng)也就收不到了。

QoS1："至少一次"，確保消息到達(dá)，但消息重復(fù)可能會發(fā)生。

QoS2："只有一次"，確保消息到達(dá)一次。在一些要求比較嚴(yán)格的計費系統(tǒng)中，可以使用此級別。在計費系統(tǒng)中，消息重復(fù)或丟失會導(dǎo)致不正確的結(jié)果。這種最高質(zhì)量的消息發(fā)布服務(wù)還可以用于即時通訊類的APP的推送，確保用戶收到且只會收到一次。

這個 Qos0 是個什么意思呢?就是如果使用了這個 Qos0 的配置作為發(fā)布質(zhì)量，我們以客戶端和服務(wù)器為例，那就是客戶端發(fā)了一個消息給服務(wù)端，這時候服務(wù)端沒有接收到，而配置是 "至多一次",這時候，相同的消息，客戶端就不會再繼續(xù)給服務(wù)端發(fā)送了，我管你收沒收到，我配置的就是最多一次.

同理，QoS1 是至少一次，也就是說，客戶端給服務(wù)端發(fā)送消息的時候，如果沒有保證消息到達(dá)，這時候可能會繼續(xù)發(fā)送，我才不管我發(fā)幾次，只要你沒有給我說你收到消息，那我就發(fā)!

而 QoS2 相對來說就是比較嚴(yán)謹(jǐn)?shù)牧耍瑸槭裁催@么說，這就相當(dāng)于客戶端給服務(wù)端發(fā)送消息，這時候，要求保證客戶端發(fā)了一次，而服務(wù)端收到一次，這樣才是相當(dāng)于只有一次的概念。

6)小型傳輸，開銷很小(固定長度的頭部是2字節(jié))，協(xié)議交換最小化，以降低網(wǎng)絡(luò)流量。

這就是為什么在介紹里說它非常適合"在物聯(lián)網(wǎng)領(lǐng)域，傳感器與服務(wù)器的通信，信息的收集"，要知道嵌入式設(shè)備的運算能力和帶寬都相對薄弱，使用這種協(xié)議來傳遞消息再適合不過了。

MQTT 報文

• 固定報頭(fixed header) 所有報文都包含
• 可變報頭(variable header) 部分報文包含
• 荷載(payload)部分報文包含

固定報頭格式如下：

固定報頭的0-3位為標(biāo)志位，第一字節(jié)的4-7位的值指定了報文類型。

實際上 這些類型也是 MQTT協(xié)議中定義的一些方法(也被稱為動作)，來于表示對確定資源所進行操作。這個資源可以代表預(yù)先存在的數(shù)據(jù)或動態(tài)生成數(shù)據(jù)，這取決于服務(wù)器的實現(xiàn)。通常來說，資源指服務(wù)器上的文件或輸出。

MQTT協(xié)議實現(xiàn)方式

實現(xiàn)MQTT協(xié)議需要客戶端和服務(wù)器端通訊完成，在通訊過程中，MQTT協(xié)議中有三種身份：發(fā)布者(Publish)、代理(Broker)(服務(wù)器)、訂閱者(Subscribe)。其中，消息的發(fā)布者和訂閱者都是客戶端，消息代理是服務(wù)器，消息發(fā)布者可以同時是訂閱者。

MQTT傳輸?shù)南⒎譃椋褐黝}(Topic)和負(fù)載(payload)兩部分：

1)Topic，可以理解為消息的類型，訂閱者訂閱(Subscribe)后，就會收到該主題的消息內(nèi)容 (payload)

2)payload，可以理解為消息的內(nèi)容，是指訂閱者具體要使用的內(nèi)容(限制大小)。

MQTT 基于訂閱與發(fā)布的消息模型

MQTT 消息發(fā)送與接收的流程：

• ClientA 鏈接到 Broker;
• ClientB 鏈接到 Broker，并訂閱主題 Topic1;
• ClientA 發(fā)送給 Broker 一條消息，主題為 Topic1;
• Broker 收到 ClientA 的消息，發(fā)現(xiàn) ClientB 訂閱了 Topic1，而后將消息轉(zhuǎn)發(fā)到 ClientB;
• ClientB 從 Broker 接收到該消息。

和傳統(tǒng)的隊列有點不一樣，若是 ClientB 在 ClientA 發(fā)布消息以后再訂閱 Topic1，ClientB 不會收到該條消息。

關(guān)于 MQTT 的基礎(chǔ)，阿粉就了解了這么多了，等以后阿粉學(xué)習(xí)新的關(guān)于 MQTT 的，阿粉再繼續(xù)分享給大家。