為何物聯(lián)網(wǎng)傾向于MQTT？

MQTT（Message Queuing Telemetry Transport），說(shuō)人話的意思就是消息隊(duì)列遙測(cè)傳輸。早些年的PC端盛行的時(shí)候，很多工程師壓根就沒有聽過(guò)個(gè)繞口的名詞，但是隨著物聯(lián)網(wǎng)（IoT）技術(shù)的逐步發(fā)展，這個(gè)協(xié)議越來(lái)越頻繁的出現(xiàn)在各大工程師的眼前。這也就造成了很多工程師只知其名不知其意，甚至很多人都還以為這是一種隨著IoT發(fā)展而被開發(fā)出來(lái)的協(xié)議。其實(shí)不然，MQTT協(xié)議最早在二十幾年前就被發(fā)明出來(lái)，到了1999年IBM公司的安迪·斯坦福-克拉克及Cirrus Link公司的阿蘭·尼普撰寫了該協(xié)議的第一個(gè)版本。后來(lái)這個(gè)協(xié)議也被國(guó)際標(biāo)準(zhǔn)化了，成為了ISO 標(biāo)準(zhǔn)（ISO/IEC PRF 20922）下基于發(fā)布/訂閱方式的消息協(xié)議。IBM公司在2013年就向結(jié)構(gòu)化資訊標(biāo)準(zhǔn)促進(jìn)組織提交了 MQTT 3.1 版規(guī)范，并附有相關(guān)章程，以確保只能對(duì)規(guī)范進(jìn)行少量更改，此后MQTT協(xié)議一直在一些小眾領(lǐng)域中使用。而到了物聯(lián)網(wǎng)技術(shù)基礎(chǔ)設(shè)施架構(gòu)完成之后，這種古老的協(xié)議開始煥發(fā)出它的第一個(gè)春天。

網(wǎng)絡(luò)的傳輸層和應(yīng)用層

眾所周知，物聯(lián)網(wǎng)至今的高速發(fā)展離開不了通訊網(wǎng)絡(luò)的基礎(chǔ)建設(shè)，你現(xiàn)在可以在全世界的任何一個(gè)角落控制家里某個(gè)房間燈光的開關(guān)，或者做工業(yè)控制的時(shí)候，你也可以遠(yuǎn)程操控某個(gè)機(jī)器人的運(yùn)動(dòng)，這種技術(shù)的成熟都是基于網(wǎng)絡(luò)通訊為基礎(chǔ)的。而目前網(wǎng)絡(luò)技術(shù)的主要技術(shù)就是OSI七層模型，當(dāng)然實(shí)際應(yīng)用中其實(shí)使用的是TCP/IP四層網(wǎng)絡(luò)模型。

TCP/IP四層網(wǎng)絡(luò)模型的第三層傳輸層就是大名鼎鼎的TCP/IP協(xié)議了，這一層協(xié)議的主要目的是用來(lái)將網(wǎng)絡(luò)上一臺(tái)計(jì)算機(jī)發(fā)出的通信數(shù)據(jù)傳輸?shù)街付↖P地址的另一臺(tái)機(jī)器上面，比如一個(gè)IP地址為“192.168.137.19”的機(jī)器要發(fā)給IP地址為“192.168.137.10”的機(jī)器16字節(jié)的二進(jìn)制數(shù)據(jù)包，那么使用TCP/IP協(xié)議傳輸即可以。而是用TCP傳輸數(shù)據(jù)時(shí)，我們常用的方式就是用socket。

但當(dāng)IP地址為“192.168.137.19”的機(jī)器發(fā)送數(shù)據(jù)給“192.168.137.10”的機(jī)器時(shí)，這一包TCP數(shù)據(jù)包里面的數(shù)據(jù)究竟是代表什么意思，接收端的IP地址為“192.168.137.10”的機(jī)器該如何其解析這一個(gè)包的數(shù)據(jù)，這個(gè)問題就是交由傳輸層上面一層的協(xié)議來(lái)解決了，這就是應(yīng)用層協(xié)議。當(dāng)然，如果你的協(xié)議不想給普通的網(wǎng)絡(luò)上的計(jì)算機(jī)解析時(shí)，你也可以自己去制定一些應(yīng)用層的協(xié)議，這個(gè)無(wú)關(guān)緊要，傳輸層的目的只是把數(shù)據(jù)傳達(dá)到目標(biāo)機(jī)器上面就可以了。

我們?nèi)粘５墓ぷ?，娛樂中常常?huì)碰到各種各樣的應(yīng)用層協(xié)議，比如當(dāng)你打開一個(gè)網(wǎng)頁(yè)時(shí)，這個(gè)圖片顯示在那個(gè)位置，這個(gè)按鈕點(diǎn)下去是實(shí)現(xiàn)什么功能，這種都是由HTML超文本傳輸協(xié)議（英文：HyperTextTransferProtocol，縮寫：HTTP）所約定的。這就保證了你網(wǎng)站中某個(gè)網(wǎng)頁(yè)被任何一臺(tái)設(shè)備請(qǐng)求時(shí)，這臺(tái)設(shè)備可以正常的顯示出來(lái)。除了HTTP，應(yīng)用層協(xié)議還有很多，如DNS，F(xiàn)TP等，而我們今天的主角MQTT協(xié)議也是其中的一員。

為何物聯(lián)網(wǎng)傾向于MQTT

既然我們既有的應(yīng)用中已經(jīng)有了那么多優(yōu)秀的應(yīng)用層協(xié)議，為何在物聯(lián)網(wǎng)領(lǐng)域中偏偏MQTT大放異彩。其實(shí)選擇MQTT協(xié)議也不是毫無(wú)根據(jù)的，MQTT 是一種輕量級(jí)的、靈活的網(wǎng)絡(luò)協(xié)議，致力于為 IoT 開發(fā)人員實(shí)現(xiàn)適當(dāng)?shù)钠胶猓?/p>

這個(gè)輕量級(jí)協(xié)議可在嚴(yán)重受限的設(shè)備硬件和高延遲/帶寬有限的網(wǎng)絡(luò)上實(shí)現(xiàn)。

它的靈活性使得為 IoT 設(shè)備和服務(wù)的多樣化應(yīng)用場(chǎng)景提供支持成為可能。

大多數(shù)開發(fā)人員已經(jīng)熟悉 HTTP Web 服務(wù)。那么為什么不讓 IoT 設(shè)備連接到 Web 服務(wù)？設(shè)備可采用 HTTP 請(qǐng)求的形式發(fā)送其數(shù)據(jù)，并采用 HTTP 響應(yīng)的形式從系統(tǒng)接收更新。這種請(qǐng)求和響應(yīng)模式存在一些嚴(yán)重的局限性：

HTTP 是一種同步協(xié)議?？蛻舳诵枰却?wù)器響應(yīng)。Web 瀏覽器具有這樣的要求，但它的代價(jià)是犧牲了可伸縮性。在 IoT 領(lǐng)域，大量設(shè)備以及很可能不可靠或高延遲的網(wǎng)絡(luò)使得同步通信成為問題。異步消息協(xié)議更適合 IoT 應(yīng)用程序。傳感器發(fā)送讀數(shù)，讓網(wǎng)絡(luò)確定將其傳送到目標(biāo)設(shè)備和服務(wù)的最佳路線和時(shí)間。

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

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

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

出于上述原因，大部分高性能、可擴(kuò)展的系統(tǒng)都使用異步消息總線來(lái)進(jìn)行內(nèi)部數(shù)據(jù)交換，而不使用 Web 服務(wù)。

訂閱/發(fā)布模型

有意思的是，這種MQTT協(xié)議的服務(wù)器，其實(shí)是比web服務(wù)器設(shè)計(jì)還要簡(jiǎn)單地多，因?yàn)樗非蟮氖且环N高效性的服務(wù)。MQTT主要進(jìn)行消息收發(fā)的機(jī)制有點(diǎn)類似于我們公眾號(hào)和各位讀者之間的關(guān)系。

在現(xiàn)實(shí)的世界中，我和大家一樣都類似于一個(gè)有一個(gè)的MQTT設(shè)備掛接在統(tǒng)一的一個(gè)服務(wù)器上面，大家出于對(duì)我們公眾號(hào)的興趣或者某種感情訂閱了我們，而當(dāng)每天我發(fā)文推送的時(shí)候，大家的手機(jī)里就會(huì)出現(xiàn)我推送的消息了，這個(gè)過(guò)程中，你獲取我信息的方式被稱為“訂閱”，而我向這個(gè)公眾號(hào)發(fā)布消息的行為就是“發(fā)布”。而大家可到我文章的時(shí)候，可以隨意地向我留言，這個(gè)行為就是大家地“發(fā)布”行為，而我無(wú)時(shí)無(wú)刻守在某一篇推送面前看大家的留言，這就是一種“訂閱”行為。在這個(gè)過(guò)程中，外部的所有信息都與我們無(wú)關(guān)，我們只是簡(jiǎn)單地以兩個(gè)方向的信息流溝通著。MQTT中的消息傳遞機(jī)制也是基于“發(fā)布（Publish）”-“訂閱（Subscribe）”的模型的。

MQTT具體的操作步驟為：

第一步：使用先獲得一個(gè)MQTT服務(wù)器，然后新建一個(gè)MQTT通訊產(chǎn)品。

第二步：接著去連接這個(gè)服務(wù)器，連接服務(wù)器的兩個(gè)重要的參數(shù)就是主機(jī)號(hào)（域名或者IP地址）和端口號(hào)。

第三步：如果使用的是第三方云服務(wù)器平臺(tái)，它可能需要你使用產(chǎn)品ID和鑒權(quán)信息去登錄這個(gè)設(shè)備，這兩個(gè)在設(shè)備云的后臺(tái)都能找到。

這三個(gè)步驟做完之后，你就可以對(duì)對(duì)應(yīng)的主題訂閱或者發(fā)布消息了。

我后面會(huì)專門整理一個(gè)文檔來(lái)給大家演示一下如何來(lái)“白嫖”一個(gè)中國(guó)移動(dòng)的設(shè)備云開放接入平臺(tái)。

這三個(gè)步驟既適用于應(yīng)用軟件開發(fā)，也適用于單片機(jī)開發(fā)。在單片機(jī)開發(fā)時(shí)，如果你用AT指令和外部的WIFI模塊通訊，那么一般模塊都可以自帶AT＋MQTT命令，這是最好的辦法，可以極大地減少單片機(jī)的壓力。或者你也可以直接獲取TCP/IP傳輸層的數(shù)據(jù)，然后自己去解析這個(gè)MQTT，這就需要用戶對(duì)MQTT協(xié)議要有一個(gè)很深的理解還要自己去解析Json數(shù)據(jù)，所以一般在做嵌入式設(shè)備時(shí)，一般推薦大家直接用現(xiàn)成帶MQTT協(xié)議的模塊，直接解析AT指令是比較方便的。

案例分析：

遠(yuǎn)程控制燈和獲取當(dāng)前房間溫度。

關(guān)于這個(gè)案例，其實(shí)是MQTT最簡(jiǎn)單的一個(gè)應(yīng)用，首先房間的嵌入式控制板主要通過(guò)WIFI連接到服務(wù)器，它既可以控制燈的開關(guān)，也可以采集溫度。遠(yuǎn)在天邊的終端設(shè)備是一臺(tái)手機(jī)。

要保持通信正常，首先它們需要接入同一個(gè)MQTT服務(wù)器。

設(shè)備端的溫度信息，是設(shè)備采集的，因此需要將采集來(lái)的數(shù)據(jù)發(fā)布到“溫度”主題，而手機(jī)是獲取這個(gè)溫度信息的，因此需要來(lái)訂閱這個(gè)“溫度”主題。一旦設(shè)備端發(fā)送溫度信息到“溫度主題”，這個(gè)主題就會(huì)被手機(jī)所接收。

設(shè)備端的燈控，是設(shè)備執(zhí)行的，因此需要訂閱“燈開關(guān)”主題，而手機(jī)是控制燈的開關(guān)的，因此需要來(lái)對(duì)這個(gè)“燈開關(guān)”主題發(fā)布控制信息。一旦手機(jī)發(fā)送開燈信息到“燈開”關(guān)主題，這個(gè)主題就會(huì)被終端所接收，再去執(zhí)行開燈命令。
責(zé)任編輯:pj