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

網(wǎng)絡的傳輸層和應用層

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

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

但當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é)議來解決了，這就是應用層協(xié)議。當然，如果你的協(xié)議不想給普通的網(wǎng)絡上的計算機解析時，你也可以自己去制定一些應用層的協(xié)議，這個無關緊要，傳輸層的目的只是把數(shù)據(jù)傳達到目標機器上面就可以了。

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

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

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

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

它的靈活性使得為 IoT 設備和服務的多樣化應用場景提供支持成為可能。

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

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

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

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

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

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

訂閱/發(fā)布模型

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

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

MQTT具體的操作步驟為：

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

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

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

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

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

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

案例分析：

遠程控制燈和獲取當前房間溫度。

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

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

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

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