1.項(xiàng)目介紹

本項(xiàng)目基于物聯(lián)量平臺(tái)遠(yuǎn)程的視頻監(jiān)控項(xiàng)目，通過MQTT協(xié)議實(shí)現(xiàn)兩個(gè)設(shè)備間的數(shù)據(jù)上報(bào)與訂閱。通過這個(gè)項(xiàng)目來演示，兩個(gè)MQTT設(shè)備如何互相訂閱，進(jìn)行消息流轉(zhuǎn)。在阿里云服務(wù)器上創(chuàng)建2個(gè)設(shè)備，分為為設(shè)備A和設(shè)備B；設(shè)備A負(fù)責(zé)采集本地?cái)z像頭畫面上傳，設(shè)備B負(fù)責(zé)接收設(shè)備A上傳的數(shù)據(jù)然后解析顯示出來。在阿里云服務(wù)器上需要配置云產(chǎn)品流轉(zhuǎn)，讓設(shè)備A的數(shù)據(jù)上傳后自動(dòng)發(fā)送給設(shè)備B。這樣就完成了視頻畫面數(shù)據(jù)的流轉(zhuǎn)。不過因?yàn)榘⒗镌频淖畲髷?shù)據(jù)限制，每次最大發(fā)送10240字節(jié)的數(shù)據(jù)。

1.1 硬件平臺(tái)

操作系統(tǒng)：Ubuntu18.04
硬件設(shè)備：電腦自帶或USB免驅(qū)攝像頭(V4L2框架)
服務(wù)器：阿里云物聯(lián)網(wǎng)平臺(tái)(基于MQTT協(xié)議)
圖像渲染：GTK2.0

1.2 開發(fā)流程

設(shè)備A：獲取攝像頭的數(shù)據(jù)–>縮放成240*320–>編碼成JPEG格式—>base64-編碼–>組合成MQTT報(bào)文–>發(fā)布到服務(wù)器。
??設(shè)備B：訂閱設(shè)備A上傳的數(shù)據(jù)–>base64解碼–>解碼JPEG數(shù)據(jù)格式–>GTK圖像渲染。

2.MQTT協(xié)議介紹

MQTT(消息隊(duì)列遙測(cè)傳輸)是ISO 標(biāo)準(zhǔn)(ISO/IEC PRF 20922)下基于發(fā)布/訂閱范式的消息協(xié)議。它工作在 TCP/IP協(xié)議族上，是為硬件性能低下的遠(yuǎn)程設(shè)備以及網(wǎng)絡(luò)狀況糟糕的情況下而設(shè)計(jì)的發(fā)布/訂閱型消息協(xié)議，為此，它需要一個(gè)消息中間件?。

MQTT是一個(gè)基于客戶端-服務(wù)器的消息發(fā)布/訂閱傳輸協(xié)議。由IBM在1999年發(fā)布。MQTT協(xié)議是輕量、簡(jiǎn)單、開放和易于實(shí)現(xiàn)的，這些特點(diǎn)使它適用范圍非常廣泛。在很多情況下，包括受限的環(huán)境中，作為一種低開銷、低帶寬占用的即時(shí)通訊協(xié)議，使其在物聯(lián)網(wǎng)、小型設(shè)備、移動(dòng)應(yīng)用等方面有較廣泛的應(yīng)用。如：機(jī)器與機(jī)器（M2M）通信和物聯(lián)網(wǎng)（IoT）。其在通過衛(wèi)星鏈路通信傳感器、偶爾撥號(hào)的醫(yī)療設(shè)備、智能家居、及一些小型化設(shè)備中已廣泛使用。

MQTT最大優(yōu)點(diǎn)在于，用極少的代碼和有限的帶寬，為連接遠(yuǎn)程設(shè)備提供實(shí)時(shí)可靠的消息服務(wù)。

2.1 MQTT特點(diǎn)

本協(xié)議運(yùn)行在 TCP/IP，或其它提供了有序、可靠、雙向連接的網(wǎng)絡(luò)連接上。MQTT屬于應(yīng)用層協(xié)議，它有以下特點(diǎn)：

使用發(fā)布/訂閱消息模式，提供了一對(duì)多的消息分發(fā)和應(yīng)用之間的解耦。
消息傳輸不需要知道負(fù)載內(nèi)容。
提供三種等級(jí)的服務(wù)質(zhì)量： .

QS0：“最多一次”，盡操作環(huán)境所能提供的最大努力分發(fā)消息。消息可能會(huì)丟失。
例如，這個(gè)等級(jí)可用于環(huán)境傳感器數(shù)據(jù)，單次的數(shù)據(jù)丟失沒關(guān)系，因?yàn)椴痪弥髸?huì)再次發(fā)送。

QS1：“至少一次”，保證消息可以到達(dá)，但是可能會(huì)重復(fù)。

QS2：“僅一次”，保證消息只到達(dá)一次。例如，這個(gè)等級(jí)可用在一個(gè)計(jì)費(fèi)系統(tǒng)中，這里如果消息重復(fù)或丟失會(huì)導(dǎo)致不正確的收費(fèi)。很小的傳輸消耗和協(xié)議數(shù)據(jù)交換，最大限度減少網(wǎng)絡(luò)流量。

在MQTT連接建立時(shí)，客戶端需要通過TCP連接到MQTT服務(wù)器，并進(jìn)行握手協(xié)商，包括協(xié)議版本、客戶端標(biāo)識(shí)符、遺囑消息、 QoS級(jí)別等信息，以確保雙方能夠正確地交換數(shù)據(jù)。一旦握手成功，客戶端和服務(wù)器之間就建立了一個(gè)持久化的TCP連接，可以隨時(shí)進(jìn)行消息傳輸。
由于TCP協(xié)議本身已經(jīng)提供了一定程度的可靠性保證，因此MQTT協(xié)議只需要在TCP的基礎(chǔ)上實(shí)現(xiàn)發(fā)布/訂閱機(jī)制、 QoS級(jí)別控制、保留消息等特性即可，從而使得它成為一種輕量級(jí)且高效的物聯(lián)網(wǎng)通信協(xié)議。

2.2 MQTT協(xié)議數(shù)據(jù)量限制

MQTT協(xié)議本身沒有限制數(shù)據(jù)包的大小，但是它需要遵循底層傳輸協(xié)議（TCP/IP）的限制和約束。在實(shí)際應(yīng)用中，MQTT協(xié)議能夠傳輸?shù)挠行?shù)據(jù)量是受多種因素影響的，如網(wǎng)絡(luò)帶寬、QoS級(jí)別、MQTT消息頭部信息等。一般來說，在默認(rèn)情況下，MQTT協(xié)議對(duì)于單個(gè)消息的有效載荷有一個(gè)限制，即不超過256MB。這個(gè)限制主要由MQTT協(xié)議的消息長(zhǎng)度字段決定，該字段的最大值是4字節(jié)，因此最大能表示2^32-1個(gè)字節(jié)的消息長(zhǎng)度，即約為4GB。然而，在實(shí)際應(yīng)用中，由于網(wǎng)絡(luò)帶寬和設(shè)備性能等方面的限制，很難實(shí)現(xiàn)傳輸如此巨大的消息。

另外，需要注意的是，如果使用較高級(jí)別的QoS，如“至少一次”或“恰好一次”，則MQTT協(xié)議會(huì)對(duì)每條消息進(jìn)行確認(rèn)和重傳，這可能會(huì)導(dǎo)致更多的網(wǎng)絡(luò)流量和延遲。因此，在選擇QoS級(jí)別時(shí)，需要根據(jù)應(yīng)用場(chǎng)景和網(wǎng)絡(luò)環(huán)境的實(shí)際情況進(jìn)行優(yōu)化和調(diào)整，以充分利用MQTT協(xié)議的特點(diǎn)和優(yōu)勢(shì)。

3.阿里云物聯(lián)網(wǎng)平臺(tái)搭建

3.1 搭建阿里云物聯(lián)網(wǎng)平臺(tái)

2.創(chuàng)建產(chǎn)品

3.功能定義， 添加自 定義功能， 發(fā)布上線。

4.添加設(shè)備

3.2 設(shè)備登錄

MQTT 連接阿里云需要三個(gè)參數(shù)： 客戶端 id、 用戶名、 密碼。 此信息可直接在設(shè)備中獲取。

3.3 消息訂閱與消息發(fā)布

Topic 是消息發(fā)布（ Pub） 者和訂閱（ Sub） 者之間的傳輸中介。 設(shè)備可通過 Topic 實(shí)現(xiàn)消息的發(fā)送和接收， 從而實(shí)現(xiàn)服務(wù)端與設(shè)備端的通信。 為方便海量設(shè)備基于 Topic 進(jìn)行通信，簡(jiǎn)化授權(quán)操作， 物聯(lián)網(wǎng)平臺(tái)定義了產(chǎn)品 Topic 類和設(shè)備 Topic。

3.4 數(shù)據(jù)上報(bào)格式

MQTT 上報(bào)數(shù)據(jù)格式為 JSON 格式。 內(nèi)容格式如下：

發(fā)布主題： "/sys/{產(chǎn)品 ID}/{設(shè)備名 }/thing/service/property/set"
數(shù)據(jù)內(nèi)容格式： {"method":"thing.event.property.post","params":{"image":"hello,world"}}

設(shè)備端訂閱消息內(nèi)容：

訂閱主題： "/sys/{產(chǎn)品 ID}/{設(shè)備名 }/thing/event/property/post"

審核編輯黃宇