初識MQTT

物聯(lián)網(wǎng)（Internet of Things），顧名思義就是物物相連的互聯(lián)網(wǎng)。它可以將物體之間通過互聯(lián)網(wǎng)進行鏈接，這些物體便能夠互相協(xié)作，而MQTT就是這些物體之間數(shù)據(jù)通信的一個基于TCP/IP的協(xié)議。

每個終端都和實現(xiàn)了MQTT協(xié)議的代理/服務(wù)器相連。

通過published MQTT代理服務(wù)器的某個主題 發(fā)送數(shù)據(jù)。

通過subscription從MQTT代理服務(wù)器獲取自己訂閱的主題數(shù)據(jù)。

代理服務(wù)器本身不產(chǎn)生數(shù)據(jù)，數(shù)據(jù)全是由鏈接到這個代理服務(wù)器的終端產(chǎn)生。

終端往服務(wù)器發(fā)送數(shù)據(jù)，在服務(wù)器訂閱了主題的終端，接受另外一個終端發(fā)送到服務(wù)器，并通過服務(wù)器轉(zhuǎn)發(fā)到自己。

為何選擇MQTT協(xié)議？

MQTT協(xié)議是一種輕量級的、靈活的網(wǎng)絡(luò)協(xié)議。并且非常適合IOT的場景。

首先IOT協(xié)議的定義非常小巧，不會像HTTP、HTTPS那么重量級。

一般支持IOT的設(shè)備的網(wǎng)絡(luò)傳輸環(huán)境和自身的計算能力都比價薄弱，正好合適MQTT對網(wǎng)絡(luò)和數(shù)據(jù)要求不高的輕量級協(xié)議。

那么，MQTT為什么如此輕便且靈活？MQTT協(xié)議的一個關(guān)鍵的特性是發(fā)布/訂閱模型。它將數(shù)據(jù)的發(fā)布者和接受者分離。

一個設(shè)備終端既可以是數(shù)據(jù)的發(fā)布者(published) 也可以是數(shù)據(jù)的訂閱者(subscription)。

一個設(shè)備如果要發(fā)布數(shù)據(jù)，只需要往代理服務(wù)器中相應(yīng)的主題發(fā)布數(shù)據(jù)內(nèi)容即可。

一個設(shè)備如果需要接受到數(shù)據(jù)，只需要在代理服務(wù)器中，提前訂閱自己需要關(guān)注的主題即可。

為什么不選擇其他的網(wǎng)絡(luò)協(xié)議？

大多數(shù)開發(fā)人員已經(jīng)熟悉了HTTP WEB協(xié)議。那么為什么不讓IOT設(shè)置鏈接到WEB服務(wù)？

設(shè)備可以采用HTTP請求的形式發(fā)送數(shù)據(jù)，并采用HTTP響應(yīng)的形式從服務(wù)器獲取數(shù)據(jù)，接受更新。

因為對于IOT的設(shè)備來說，這種主動請求–>被動等待應(yīng)答的數(shù)據(jù)傳輸模型存在嚴(yán)重的局限性：

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

HTTP是單向的?？蛻舳吮仨氈鲃拥陌l(fā)起請求。在IoT應(yīng)用程序中，設(shè)備或傳感器通常是客戶端，這就意味著，除非用戶或應(yīng)用程序主動請求，否則無法接受來自服務(wù)器的數(shù)據(jù)。

HTTP是一個1-1的協(xié)議?？蛻舳税l(fā)出請求，服務(wù)器進行相應(yīng)。它們是一對一的對應(yīng)關(guān)系。但是需要把HTTP這種1-1的關(guān)系，改進程IOT中很常見的一對多的關(guān)系，實現(xiàn)起來很困難，而且成本也很高。而一對多在IoT中很常見。

HTTP相對于MQTT來說，是一個比較重的協(xié)議，它不適合IOT終端設(shè)備受限的網(wǎng)絡(luò)和較差的計算能力。