物聯(lián)網(wǎng)(IoT)連接協(xié)議-MQTT

490729491

物聯(lián)網(wǎng) (IoT) 設(shè)備必須連接互聯(lián)網(wǎng)。通過(guò)連接到互聯(lián)網(wǎng)，設(shè)備就能相互協(xié)作，以及與后端服務(wù)協(xié)同工作。互聯(lián)網(wǎng)的基礎(chǔ)網(wǎng)絡(luò)協(xié)議是 TCP/IP。MQTT（消息隊(duì)列遙測(cè)傳輸） 是基于 TCP/IP 協(xié)議棧而構(gòu)建的，已成為 IoT 通信的標(biāo)準(zhǔn)。

MQTT（Message Queuing Telemetry Transport，消息隊(duì)列遙測(cè)傳輸）是IBM開(kāi)發(fā)的一個(gè)即時(shí)通訊協(xié)議，它是一種輕量級(jí)的、基于代理的“發(fā)布/訂閱”模式的消息傳輸協(xié)議。其具有協(xié)議簡(jiǎn)潔、小巧、可擴(kuò)展性強(qiáng)、省流量、省電等優(yōu)點(diǎn)，而且已經(jīng)有PHP，JAVA，Python，C，C#，Go等多個(gè)語(yǔ)言版本，基本可以使用在任何平臺(tái)上，幾乎可以把所有聯(lián)網(wǎng)物品和外部連接起來(lái)，所以特別適合用來(lái)當(dāng)做物聯(lián)網(wǎng)的通信協(xié)議。

相比HTTP協(xié)議不適合大規(guī)模的物聯(lián)網(wǎng)應(yīng)用，這是因?yàn)椋?/font>

1. HTTP 是一種同步協(xié)議。客戶端需要等待服務(wù)器響應(yīng),依賴較高的網(wǎng)絡(luò)信號(hào)質(zhì)量。

2. HTTP 是單向的。客戶端必須發(fā)起連接。在 IoT 應(yīng)用程序中，設(shè)備或傳感器通常是客戶端，這意味著它們無(wú)法被動(dòng)地接收來(lái)自網(wǎng)絡(luò)的命令。

3. HTTP 是一種 1-1 協(xié)議。客戶端發(fā)出請(qǐng)求，服務(wù)器進(jìn)行響應(yīng)。將消息傳送到網(wǎng)絡(luò)上的所有設(shè)備上，不但很困難，而且成本很高，而這是 IoT 應(yīng)用程序中的一種常見(jiàn)使用情況。

4. HTTP 是一種有許多標(biāo)頭和規(guī)則的重量級(jí)協(xié)議。它不適合受限的網(wǎng)絡(luò)。

MQTT特點(diǎn)

MQTT協(xié)議是為大量計(jì)算能力有限，且工作在低帶寬、不可靠的網(wǎng)絡(luò)的遠(yuǎn)程傳感器和控制設(shè)備通訊而設(shè)計(jì)的協(xié)議，它具有以下主要的幾項(xiàng)特性：

1.  使用發(fā)布/訂閱消息模式，一個(gè)發(fā)布者可以對(duì)應(yīng)多個(gè)訂閱者，當(dāng)發(fā)布者發(fā)生變化的時(shí)候，他可以將消息一一通知給所有的訂閱者。這種模式提供了更大的網(wǎng)絡(luò)擴(kuò)展性和更動(dòng)態(tài)的網(wǎng)絡(luò)拓?fù)洹Ｒ驗(yàn)?/font> MQTT 消息是按主題進(jìn)行組織的，所以應(yīng)用程序開(kāi)發(fā)人員能靈活地指定某些客戶端只能與某些消息交互。

根據(jù) MQTT 的基礎(chǔ)了解后并結(jié)合簡(jiǎn)單的架構(gòu)，在這里做一個(gè)簡(jiǎn)單的示例圖，可以更直觀的理解MQTT協(xié)議的通信模型。MQTT Broker 就選擇 EMQ 作為示范。比如有1個(gè)溫度傳感器（1個(gè)Machine），1個(gè)移動(dòng)設(shè)備，1個(gè)電腦，一個(gè)服務(wù)器（3個(gè)Machine)，都可以得到或者顯示溫度傳感器的溫度值，需要先通過(guò) MQTT協(xié)議subscribe（訂閱）一個(gè)比如叫 temperature 的 topic（主題）如下圖:

圖中移動(dòng)設(shè)備，服務(wù)器，電腦需要先通過(guò) EMQ subscribe 一個(gè)叫 temperature 的 topic，當(dāng)溫度傳感器 publish 溫度數(shù)據(jù)，三個(gè)設(shè)備就可以收到了。

2.對(duì)負(fù)載內(nèi)容屏蔽的消息傳輸；

3.使用 TCP/IP 提供網(wǎng)絡(luò)連接；

4.有三種消息發(fā)布服務(wù)質(zhì)量：

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

l "至少一次"，確保消息到達(dá)，但消息重復(fù)可能會(huì)發(fā)生。這一級(jí)別可用于如下情況，你需要獲得每一條消息，并且消息重復(fù)發(fā)送對(duì)你的使用場(chǎng)景無(wú)影響。

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

5.小型傳輸，開(kāi)銷很小（固定長(zhǎng)度的頭部是 2 字節(jié)），協(xié)議交換最小化，以降低網(wǎng)絡(luò)流量。它有一個(gè)用來(lái)指定消息類型的簡(jiǎn)單標(biāo)頭，有一個(gè)基于文本的主題，還有一個(gè)任意的二進(jìn)制有效負(fù)載。應(yīng)用程序可對(duì)有效負(fù)載采用任何數(shù)據(jù)格式，比如 JSON、XML、加密二進(jìn)制或 Base64，只要目標(biāo)客戶端能夠解析該有效負(fù)載；

6.使用 Last Will 和 Testament 特性通知有關(guān)各方客戶端異常中斷的機(jī)制。

奇跡物聯(lián)作為專注eSIM 技術(shù)的物聯(lián)網(wǎng)公司，發(fā)布的AM20E,AM21E,AM400E等NB/LTE模組，支持包括MQTT協(xié)議在內(nèi)的多種通信協(xié)議，客戶借助eSIM模組，可將物聯(lián)網(wǎng)終端設(shè)備部署在私有服務(wù)器上，也可在阿里云，OneNET等公有云平臺(tái)上部署，我公司提供豐富的產(chǎn)品開(kāi)發(fā)資料和程序例程，幫助用戶實(shí)現(xiàn)項(xiàng)目快速落地。