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

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

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

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

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

我們?nèi)粘５墓ぷ鳎瑠蕵分谐３龅礁鞣N各樣的應(yīng)用層協(xié)議，比如當(dāng)你打開一個網(wǎng)頁時，這個圖片顯示在那個位置，這個按鈕點下去是實現(xiàn)什么功能，這種都是由HTML超文本傳輸協(xié)議（英文：HyperTextTransferProtocol，縮寫：HTTP）所約定的。這就保證了你網(wǎng)站中某個網(wǎng)頁被任何一臺設(shè)備請求時，這臺設(shè)備可以正常的顯示出來。除了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大放異彩。其實選擇MQTT協(xié)議也不是毫無根據(jù)的，MQTT 是一種輕量級的、靈活的網(wǎng)絡(luò)協(xié)議，致力于為 IoT 開發(fā)人員實現(xiàn)適當(dāng)?shù)钠胶猓?/p>

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

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

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

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

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

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

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

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

訂閱/發(fā)布模型

有意思的是，這種MQTT協(xié)議的服務(wù)器，其實是比web服務(wù)器設(shè)計還要簡單地多，因為它追求的是一種高效性的服務(wù)。MQTT主要進(jìn)行消息收發(fā)的機制有點類似于我們公眾號和各位讀者之間的關(guān)系。

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

MQTT具體的操作步驟為：

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

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

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

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

我后面會專門整理一個文檔來給大家演示一下如何來“白嫖”一個中國移動的設(shè)備云開放接入平臺。

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

案例分析：

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

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

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

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

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