物聯網 (IoT) 裝置必須連接配接網際網路。通過連接配接到網際網路，裝置就能互相協作，以及與後端服務協同工作。網際網路的基礎網絡協定是 TCP/IP。MQTT(消息隊列遙測傳輸) 是基于 TCP/IP 協定棧而建構的，已成為 IoT 通信的标準。
MQTT 最初由 IBM 于上世紀 90 年代晚期發明和開發。它最初的用途是将石油管道上的傳感器與衛星相連結。顧名思義，它是一種支援在各方之間異步通信的消息協定。異步消息協定在空間和時間上将消息發送者與接收者分離，是以可以在不可靠的網絡環境中進行擴充。雖然叫做消息隊列遙測傳輸，但它與消息隊列毫無關系，而是使用了一個釋出和訂閱的模型。在 2014 年末，它正式成為了一種 OASIS 開放标準，而且在一些流行的程式設計語言中受到支援(通過使用多種開源實作)。
為何選擇 MQTT
MQTT 是一種輕量級的、靈活的網絡協定，緻力于為 IoT 開發人員實作适當的平衡：
- 這個輕量級協定可在嚴重受限的裝置硬體和高延遲/帶寬有限的網絡上實作。
- 它的靈活性使得為 IoT 裝置和服務的多樣化應用場景提供支援成為可能。
為了了解為什麼 MQTT 如此适合 IoT 開發人員，我們首先來分析一下為什麼其他流行網絡協定未在 IoT 中得到成功應用。
為什麼不選擇HTTP
大多數開發人員已經熟悉 HTTP Web 服務。那麼為什麼不讓 IoT 裝置連接配接到 Web 服務？裝置可采用 HTTP 請求的形式發送其資料，并采用 HTTP 響應的形式從系統接收更新。這種請求和響應模式存在一些嚴重的局限性：
- HTTP 是一種同步協定。用戶端需要等待伺服器響應。Web 浏覽器具有這樣的要求，但它的代價是犧牲了可伸縮性。在 IoT 領域，大量裝置以及很可能不可靠或高延遲的網絡使得同步通信成為問題。異步消息協定更适合 IoT 應用程式。傳感器發送讀數，讓網絡确定将其傳送到目标裝置和服務的最佳路線和時間。
- HTTP 是單向的。用戶端必須發起連接配接。在 IoT 應用程式中，裝置或傳感器通常是用戶端，這意味着它們無法被動地接收來自網絡的指令。
- HTTP 是一種 1-1 協定。用戶端送出請求，伺服器進行響應。将消息傳送到網絡上的所有裝置上，不但很困難，而且成本很高，而這是 IoT 應用程式中的一種常見使用情況。
- HTTP 是一種有許多标頭和規則的重量級協定。它不适合受限的網絡。
HTTP協定的兩個過程，Request和Response，兩個都有各自的語言格式，我們看下是什麼。
請求封包格式：(注意這裡有個換行)
響應封包格式：(注意這裡有個換行)
方法method：
這個很重要，比如說GET和POST方法，這兩個是很常用的，GET就是擷取什麼内容，而POST就是向伺服器發送什麼資料。當然還有其他的，比如HTTP 1.1中還有：DELETE、PUT、CONNECT、HEAD、OPTIONS、TRACE等一共8個方法(HTTP Method曆史：HTTP 0.9 隻有GET方法；HTTP 1.0 有GET、POST、HEAD三個方法)。
請求URL:
這裡填寫的URL是不包含IP位址或者域名的，是主機本地檔案對應的目錄位址，是以我們一般看到的就是“/”。
版本version：
格式是HTTP/.這樣的格式，比如說HTTP/1.1.這個版本代表的就是我們使用的HTTP協定的版本，現在使用的一般是HTTP/1.1
狀态碼status:
狀态碼是三個數字，代表的是請求過程中所發生的情況，比如說200代表的是成功，404代表的是找不到檔案。
原因短語reason-phrase：
是狀态碼的可讀版本，狀态碼就是一個數字，如果你事先不知道這個數字什麼意思，可以先檢視一下原因短語。
首部header：
注意這裡的header我們不是叫做頭，而是叫做首部。可能有零個首部也可能有多個首部，每個首部包含一個名字後面跟着一個冒号，然後是一個可選的空格，接着是一個值，然後換行。
實體的主體部分entity-body：
實體的主體部分包含一個任意資料組成的資料塊，并不是所有的封包都包含實體的主體部分，有時候隻是一個空行加換行就結束了。
下面我們舉個簡單的例子：
請求封包：
GET /index.html HTTP/1.1
Accept: text/*
Host: www.myweb.com
響應封包：
HTTP/1.1 200 OK
Content-type: text/plain
Content-length: 3
出于上述原因，大部分高性能、可擴充的系統都使用異步消息總線來進行内部資料交換，而不使用 Web 服務。事實上，企業中間件系統中使用的最流行的消息協定被稱為 AMQP(進階消息排隊協定)。但是，在高性能環境中，計算能力和網絡延遲通常不是問題。AMQP 緻力于在企業應用程式中實作可靠性和互操作性。它擁有龐大的特性集，但不适合資源受限的 IoT 應用程式。
除了 AMQP 之外，還有其他流行的消息協定。例如，XMPP(Extensible Messaging and Presence Protocol，可擴充消息和狀态協定)是一種對等即時消息 (IM) 協定。它高度依賴于支援 IM 用例的特性，比如存在狀态和媒體連接配接。與 MQTT 相比，它在裝置和網絡上需要的資源都要多得多。
那麼，MQTT 為什麼如此輕量且靈活？MQTT 協定的一個關鍵特性是釋出和訂閱模型。與所有消息協定一樣，它将資料的釋出者與使用者分離。
它具有以下主要的幾項特性：
1、使用釋出/訂閱消息模式，提供一對多的消息釋出和應用程式之間的解耦；
2、消息傳輸不需要知道負載内容；
3、使用 TCP/IP 提供網絡連接配接；
4、有三種消息釋出的服務品質：
QoS 0：“最多一次”，消息釋出完全依賴底層 TCP/IP 網絡。分發的消息可能丢失或重複。例如，這個等級可用于環境傳感器資料，單次的資料丢失沒關系，因為不久後還會有第二次發送。
QoS 1：“至少一次”，確定消息可以到達，但消息可能會重複。
QoS 2：“隻有一次”，確定消息隻到達一次。例如，這個等級可用在一個計費系統中，這裡如果消息重複或丢失會導緻不正确的收費。
5、小型傳輸，開銷很小(固定長度的頭部是 2 位元組)，協定交換最小化，以降低網絡流量；
6、使用 Last Will 和 Testament 特性通知有關各方用戶端異常中斷的機制；
在MQTT協定中，一個MQTT資料包由：固定頭(Fixed header)、 可變頭(Variable header)、 消息體(payload)三部分構成。MQTT的傳輸格式非常精小，最小的資料包隻有2個bit，且無應用消息頭。
釋出和訂閱模型
MQTT 協定在網絡中定義了兩種實體類型：一個消息代理和一些用戶端。代理是一個伺服器，它從用戶端接收所有消息，然後将這些消息路由到相關的目标用戶端。用戶端是能夠與代理互動來發送和接收消息的任何事物。用戶端可以是現場的 IoT 傳感器，或者是資料中心内處理 IoT 資料的應用程式。
- 用戶端連接配接到代理。它可以訂閱代理中的任何消息 “主題”。此連接配接可以是簡單的 TCP/IP 連接配接，也可以是用于發送敏感消息的加密 TLS 連接配接。
- 用戶端通過将消息和主題發送給代理，釋出某個主題範圍内的消息。
- 代理然後将消息轉發給所有訂閱該主題的用戶端。
因為 MQTT 消息是按主題進行組織的，是以應用程式開發人員能靈活地指定某些用戶端隻能與某些消息互動。例如，傳感器将在 “sensor_data” 主題範圍内釋出讀數，并訂閱 “config_change” 主題。将傳感器資料儲存到後端資料庫中的資料處理應用程式會訂閱 “sensor_data” 主題。管理控制台應用程式能接收系統管理者的指令來調整傳感器的配置，比如靈敏度和采樣頻率，并将這些更改釋出到 “config_change” 主題。
IoT 傳感器的 MQTT 釋出和訂閱模型
同時，MQTT 是輕量級的。它有一個用來指定消息類型的簡單标頭，有一個基于文本的主題，還有一個任意的二進制有效負載。應用程式可對有效負載采用任何資料格式，比如 JSON、XML、加密二進制或 Base64，隻要目标用戶端能夠解析該有效負載。
MQTT 開發入門
- 阿裡loT平台添加産品裝置——下面我們介紹一下如何用一個MQTT的工具接入阿裡IoT平台：
lot平台建立産品裝置：
1.先注冊登入阿裡雲，再開通阿裡雲物聯網平台
https://dev.iot.aliyun.com/sale?source=deveco_partner_chenlin
複制連結到浏覽器(如果沒有阿裡雲賬号，注冊後再次複制進入，點選“開通”)
掃碼也可以開通
注冊：單擊免費注冊或者使用第三方淘寶、支付寶、釘釘、1688、微網誌授權登入，但是第三方登入也需要進行再次注冊，并且進行實名認證。
2.開通後，進入管理控制台，若回到首頁面，可重新複制平台連結進入或從首頁右上角的側邊菜單欄—産品—物聯網—物聯網裝置接入/物聯網裝置管理進入管理控制台
左側導航欄選擇裝置管理—産品，單擊建立産品
3.建立産品，第一步：選擇版本類型，這裡我們選擇基礎版作為示範，單擊下一步
4.建立産品，第二步：填寫産品資訊，完成要建立的産品參數設定，單擊完成。
頁面參數設定如下：
| 參數 | 描述 |
| 産品名稱 | 為産品命名。産品名稱在賬号内具有唯一性。例如，可以填寫為産品型号。支援中文、英文字母、數字和下劃線，長度限制4~30，一個中文漢字算2位。 |
| 節點類型 | 裝置或網關。 o 裝置：指不能挂載子裝置的裝置。這種裝置可以直連物聯網平台，也可以作為網關的子裝置連接配接物聯網平台。 o 網關：指可以挂載子裝置的直連裝置。網關具有子裝置管理子產品，維持子裝置的拓撲關系，并且可以将拓撲關系同步到雲端。 |
| 産品描述 | 輸入文字，用以描述産品。字數限制為100。 |
建立成功後如圖：
5.在左側導航欄選擇裝置管理—裝置中選擇剛建立好的産品。然後，點選添加裝置選擇後，新建立的裝置将繼承該産品定義好的功能和特性。(可選)填入DeviceName，如果不填，系統将自動生成一個DeviceName，用以辨別裝置。
6.單擊确認，完成裝置建立。
裝置建立完成後，将自動彈出 檢視裝置證書彈框。您可以檢視、複制裝置證書資訊。裝置證書又名 裝置三元組，由裝置 ProductKey、DeviceName、和 DeviceSecret組成，是裝置與物聯網平台進行通信的重要身份認證，建議您妥善保管。
ProductKey：物聯網平台為您建立的産品頒發的全局唯一辨別符。
DeviceName：裝置在産品内的唯一辨別符，用于裝置認證和通信。(使用者自定義，或系統自動頒發)
DeviceSecret：物聯網平台為裝置頒發的裝置秘鑰，用于認證加密，需與DeviceName成對使用。
7.單擊已建立裝置對應操作欄中的檢視，進入裝置詳情頁面，檢視裝置詳情。在 裝置資訊頁簽下，單擊實時延遲後的 測試，檢視您裝置的網絡延遲情況。
使用MQTTfx工具連接配接
下載下傳mqttfx工具
http://mqttfx.bceapp.com/
- 輕按兩下打開mqttfx.exe
2.單擊Extras，選擇Edit Connection Profies
3.打開後，設定詳細參數
(1)Proflie Name:是已建立産品的DeviceName(直接複制)
(2)BrokerAddress：
YourProductKey.iot-as-mqtt.cn-shanghai.aliyuncs.com，
”YourProductKey”請替換為您的ProductKey(直接複制)
(3)BrokerPort:設定為1883
(4)Client ID(mqtt):
ClientID(mqtt)=clientId(sn)+"|securemode=3,signmethod=hmacsha1,timestamp=12345|"
clientId：表示用戶端ID，建議mac或sn，64字元内。(使用者自定義，需要唯一性)
timestamp：表示目前時間毫秒值，可選。
mqttClientId：格式中||内為擴充參數。
signmethod：表示簽名算法類型。(阿裡雲平台的加簽方式是hmacsha1)
securemode：表示目前安全模式，可選值有2 (wss協定)和3(ws協定)。
例子：
ClientID(mqtt)為
121212|securemode=3,signmethod=hmacsha1,timestamp=12345|
(5)User Name：User Name =DeviceName+"&"+ProductKey
例子：DAJTve67hNZPrOWMiyBb&a1umjZBeOYM
(6)Password：http://tool.oschina.net/encrypt?type=2
打開連結，Password加簽過程見下圖，最終在mqttfx的Password填入下圖加簽後的password
明文：clinetId+Id值+deviceName+Name名+productKey+Key值+timestamp+time值；
選擇HmacSHA1的加簽方式，在密鑰中輸入DeviceSecret的值，單擊哈希/散列獲得的哈希值即使用者密碼Password。
4.設定完畢，單擊Apply
5.單擊Connect，綠色圓圈代表連接配接成功，紅色圓圈代表連接配接失敗，使用者名或者密碼有錯誤
6.傳回管理控制台，可檢視裝置管理—裝置清單—目前裝置狀态(是否線上)，線上說明裝置接入成功，未激活說明裝置接入還未成功
三、訂閱
1.選擇裝置管理—裝置—裝置清單—檢視，進入裝置詳情頁
2.進入到Topic清單界面，會自動生成這幾個Topic
釋出指的是裝置發送到平台；
訂閱是平台發送給裝置。
四、建立或者編輯Topic
1.選擇裝置管理—産品—産品清單—檢視，進入産品詳情頁
2.在産品詳情頁中，進入到Topic類清單界面
3.單擊定義Topic類，建立Topic類，自定義名字
4.單擊确認後，進入産品Topic類清單，能看到剛剛建立的Topic類(test)
5.選擇裝置管理—裝置—裝置清單—檢視—Topic清單，在mqtt用戶端訂閱Topic
五、mqtt用戶端訂閱iot平台Topic
1.輕按兩下打開mqtt用戶端，單擊Connect連接配接平台
2.連接配接成功後，在Subscribe中輸入訂閱的topic，單擊Subscribe，确認訂閱
3.回到裝置的Topic清單，選擇釋出消息
4.選擇釋出消息，輸入消息内容(自定義)
*Quality of Service等級是發送與接收端的一種關于保證傳遞資訊的協定。一共有3 個QoS 等級：
1.最多一次(0)
2.最少一次(1)
3.隻一次(2)
這裡使用0或者1都可以
5.單擊确認後，在mqtt用戶端收到平台下發的消息
六、mqtt用戶端發資訊到iot平台
選擇Publish,輸入在iot平台上建立的釋出消息的Topic,因為平台暫時隻支援檢視qos為1時候的資料，這裡選擇1,然後輸入要發送給iot平台的資訊，點選Publish發送
MQTT 協定
MQTT 是一種連接配接協定，它指定了如何組織資料位元組并通過 TCP/IP 網絡傳輸它們。但實際上，開發人員并不需要了解這個連接配接協定。我們隻需要知道，每條消息有一個指令和資料有效負載。該指令定義消息類型(例如 CONNECT 消息或 SUBSCRIBE 消息)。所有 MQTT 庫和工具都提供了直接處理這些消息的簡單方法，并能自動填充一些必需的字段，比如消息和用戶端 ID。
首先，用戶端發送一條 CONNECT 消息來連接配接代理。CONNECT 消息要求建立從用戶端到代理的連接配接。CONNECT 消息包含以下内容參數。
表 1. CONNECT 消息參數
| 參數 | 說明 |
| cleanSession | 此标志指定連接配接是否是持久性的。持久會話會将所有訂閱和可能丢失的消息(具體取決于 QoS) 都存儲在代理中。(請參閱 表 3 擷取 QoS 的描述。) |
| username | 代理的身份驗證和授權憑證。 |
| password | 代理的身份驗證和授權憑證。 |
| lastWillTopic | 連接配接意外中斷時，代理會自動向某個主題發送一條 “last will” 消息。 |
| lastWillQos | “last will” 消息的 QoS。(請參閱 表 3 來檢視 QoS 的描述。) |
| lastWillMessage | “last will” 消息本身。 |
| keepAlive | 這是用戶端通過 ping 代理來保持連接配接有效所需的時間間隔。 |
用戶端收到來自代理的一條 CONNACK 消息。CONNACK 消息包含以下内容參數。
表 2. CONNACK 消息參數
| 參數 | 說明 |
| sessionPresent | 此參數表明連接配接是否已有一個持久會話。也就是說，連接配接已訂閱了主題，而且會接收丢失的消息。 |
| returnCode | 0 表示成功。其他值指出了失敗的原因。 |
建立連接配接後，用戶端然後會向代理發送一條或多條 SUBSCRIBE 消息，表明它會從代理接收針對某些主題的消息。消息可以包含一個或多個重複的參數。如表 3。
表 3. SUBSCRIBE 消息參數
| 參數 | 說明 |
| qos | qos(服務品質或 QoS)标志表明此主題範圍内的消息傳送到用戶端所需的一緻程度。
|
| topic | 要訂閱的主題。一個主題可以有多個級别，級别之間用斜杠字元分隔。例如，“dw/demo” 和 “ibm/bluemix/mqtt” 是有效的主題。 |
用戶端成功訂閱某個主題後，代理會傳回一條 SUBACK 消息，其中包含一個或多個 returnCode 參數。
表 4. SUBACK 消息參數
| 參數 | 說明 |
| returnCode | SUBCRIBE 指令中的每個主題都有一個傳回代碼。傳回值如下所示。
|
與 SUBSCRIBE 消息對應，用戶端也可以通過 UNSUBSCRIBE 消息取消訂閱一個或多個主題。
表 5. UNSUBSCRIBE 消息參數
| 參數 | 說明 |
| topic | 此參數可重複用于多個主題。 |
用戶端可向代理發送 PUBLISH 消息。該消息包含一個主題和資料有效負載。代理然後将消息轉發給所有訂閱該主題的用戶端。
表 6. PUBLISH 消息參數
| 參數 | 說明 |
| topicName | 釋出的消息的相關主題。 |
| qos | 消息傳遞的服務品質水準。(請參閱 表 3 來檢視 QoS 的描述。) |
| retainFlag | 此标志表明代理是否保留該消息作為針對此主題的最後一條已知消息。 |
| payload | 消息中的實際資料。它可以是文本字元串或二進制大對象資料。 |
技巧和解決方法
MQTT 的優勢在于它的簡單性。在可以使用的主題類型或消息有效負載上沒有任何限制。這支援一些有趣的用例。例如，請考慮以下問題：
如何使用 MQTT 發送 1-1 消息？雙方可以協商使用一個特定于它們的主題。例如，主題名稱可以包含兩個用戶端的 ID，以確定它的唯一性。
用戶端如何傳輸它的存在狀态？系統可以為 “presence” 主題協商一個命名約定。例如，“presence/client-id” 主題可以擁有用戶端的存在狀态資訊。當用戶端建立連接配接時，将該消息被設定為 true，在斷開連接配接時，該消息被設定為 false。用戶端也可以将一條 last will 消息設定為 false，以便在連接配接丢失時設定該消息。代理可以保留該消息，讓新用戶端能夠讀取該主題并找到存在狀态。
如何保護通信？用戶端與代理的連接配接可以采用加密 TLS 連接配接，以保護傳輸中的資料。此外，因為 MQTT 協定對有效負載資料格式沒有任何限制，是以系統可以協商一種加密方法和密鑰更新機制。在這之後，有效負載中的所有内容可以是實際 JSON 或 XML 消息的加密二進制資料。
MQTT協定講解
MQTT VS CoAP
【視訊教程】手把手帶你搭建 物聯網伺服器(基于MQTT)
我眼中的“物聯網”
點選 閱讀原文，開通阿裡雲IoT平台，每個月免費使用100萬條消息