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

網絡的傳輸層和應用層

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

TCP/IP四層網絡模型的第三層傳輸層就是大名鼎鼎的TCP/IP協議了，這一層協議的主要目的是用來將網絡上一臺計算機發出的通信數據傳輸到指定IP地址的另一臺機器上面，比如一個IP地址為“192.168.137.19”的機器要發給IP地址為“192.168.137.10”的機器16字節的二進制數據包，那么使用TCP/IP協議傳輸即可以。而是用TCP傳輸數據時，我們常用的方式就是用socket。

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

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

為何物聯網傾向于MQTT

既然我們既有的應用中已經有了那么多優秀的應用層協議，為何在物聯網領域中偏偏MQTT大放異彩。其實選擇MQTT協議也不是毫無根據的，MQTT 是一種輕量級的、靈活的網絡協議，致力于為 IoT 開發人員實現適當的平衡：

這個輕量級協議可在嚴重受限的設備硬件和高延遲/帶寬有限的網絡上實現。

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

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

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

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

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

HTTP 是一種有許多標頭和規則的重量級協議。它不適合受限的網絡。

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

訂閱/發布模型

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

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

MQTT具體的操作步驟為：

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

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

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

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

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

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

案例分析：

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

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

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

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

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