物聯(lián)網(wǎng) （IoT） 設(shè)備需要連接到互聯(lián)網(wǎng)，聯(lián)網(wǎng)的方式有很多種，傳輸協(xié)議也有很多種，為什么MQTT才是物聯(lián)網(wǎng)的首選傳輸協(xié)議呢？

本文重點(diǎn)講述MQTT傳輸協(xié)議。

一、關(guān)于MQTTMQTT：Message Queuing Telemetry Transport，消息隊列遙測傳輸。

互聯(lián)網(wǎng)的基礎(chǔ)網(wǎng)絡(luò)協(xié)議是 TCP/IP，MQTT（消息隊列遙測傳輸） 是基于 TCP/IP 協(xié)議棧而構(gòu)建的。

MQTT由IBM在1999年發(fā)布，是一種基于發(fā)布/訂閱（publish / subscribe）模式的“輕量級”通訊協(xié)議，在 2014 年末，它正式成為了一種 OASIS 開放標(biāo)準(zhǔn)，而且在一些流行的編程語言中受到支持（通過使用多種開源實(shí)現(xiàn)）。

前面文章《http和tcp/ip的關(guān)系和區(qū)別》提及了OSI（開放式系統(tǒng)互聯(lián)），這里MQTT同HTTP屬于第七層（應(yīng)用層）。

參考網(wǎng)址：

http://mqtt.orghttp://mqtt.p2hp.comhttps://www.ibm.com/developerworks/cn/iot/https://docs.oasis-open.org/mqtt/mqtt/v5.0/mqtt-v5.0.html

二、MQTT特點(diǎn)

MQTT特點(diǎn)：

開放消息協(xié)議，簡單易實(shí)現(xiàn)

發(fā)布訂閱模式，一對多消息發(fā)布

消息QoS支持，可靠傳輸保證

基于TCP/IP網(wǎng)絡(luò)連接，提供有序，無損，雙向連接。

1字節(jié)固定報頭，2字節(jié)心跳報文，最小化傳輸開銷和協(xié)議交換，有效減少網(wǎng)絡(luò)流量。

設(shè)計規(guī)范：

由于物聯(lián)網(wǎng)的環(huán)境是非常特別的，所以MQTT遵循以下設(shè)計原則：

精簡，不添加可有可無的功能；

允許用戶動態(tài)創(chuàng)建主題，零運(yùn)維成本；

把傳輸量降到最低以提高傳輸效率；

把低帶寬、高延遲、不穩(wěn)定的網(wǎng)絡(luò)等因素考慮在內(nèi)；

支持連續(xù)的會話控制；

理解客戶端計算能力可能很低；

提供服務(wù)質(zhì)量管理；

發(fā)布/訂閱（Pub/Sub）模式，方便消息在傳感器之間傳遞；

假設(shè)數(shù)據(jù)不可知，不強(qiáng)求傳輸數(shù)據(jù)的類型與格式，保持靈活性。

三、物聯(lián)網(wǎng)為何首選MQTT

1.為何選擇 MQTT

MQTT 是一種輕量級的、靈活的網(wǎng)絡(luò)協(xié)議，致力于為 IoT 開發(fā)人員實(shí)現(xiàn)適當(dāng)?shù)钠胶猓?/p>

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

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

為了了解為什么 MQTT 如此適合 IoT 開發(fā)人員，我們首先來分析一下為什么其他流行網(wǎng)絡(luò)協(xié)議未在 IoT 中得到成功應(yīng)用。

2.為什么不選擇其他眾多網(wǎng)絡(luò)協(xié)議

大多數(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)重的局限性：

A.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ù)的最佳路線和時間。

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

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

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

出于上述原因，大部分高性能、可擴(kuò)展的系統(tǒng)都使用異步消息總線來進(jìn)行內(nèi)部數(shù)據(jù)交換，而不使用 Web 服務(wù)。事實(shí)上，企業(yè)中間件系統(tǒng)中使用的最流行的消息協(xié)議被稱為 AMQP（高級消息排隊協(xié)議）。但是，在高性能環(huán)境中，計算能力和網(wǎng)絡(luò)延遲通常不是問題。AMQP 致力于在企業(yè)應(yīng)用程序中實(shí)現(xiàn)可靠性和互操作性。它擁有龐大的特性集，但不適合資源受限的 IoT 應(yīng)用程序。

除了 AMQP 之外，還有其他流行的消息協(xié)議。例如，XMPP（Extensible Messaging and Presence Protocol，可擴(kuò)展消息和狀態(tài)協(xié)議）是一種對等即時消息 （IM） 協(xié)議。它高度依賴于支持 IM 用例的特性，比如存在狀態(tài)和介質(zhì)連接。與 MQTT 相比，它在設(shè)備和網(wǎng)絡(luò)上需要的資源都要多得多。

那么，MQTT 為什么如此輕量且靈活？因?yàn)镸QTT 協(xié)議的一個關(guān)鍵特性是發(fā)布和訂閱模型。與所有消息協(xié)議一樣，它將數(shù)據(jù)的發(fā)布者與使用者分離。