為什么在物聯(lián)網(wǎng)應(yīng)用中大多使用 MQTT？

嵌入式大雜燴

物聯(lián)網(wǎng)應(yīng)用中MQTT和HTTP都有應(yīng)用，但是應(yīng)用的場(chǎng)景不同。在物聯(lián)網(wǎng)應(yīng)用中，大多選擇使用MQTT（Message Queuing Telemetry Transport）而不是HTTP（Hypertext Transfer Protocol），主要基于以下幾個(gè)方面的優(yōu)勢(shì)：
MQTT優(yōu)勢(shì) 1. 節(jié)省網(wǎng)絡(luò)帶寬

數(shù)據(jù)包大小：MQTT使用輕量級(jí)協(xié)議，數(shù)據(jù)包大小相較于HTTP更小。MQTT的消息頭僅需2字節(jié)，而HTTP協(xié)議的消息頭部則復(fù)雜得多，即使是最簡(jiǎn)單的HTTP請(qǐng)求，消息頭部也至少幾百字節(jié)。

傳輸效率：MQTT的訂閱-發(fā)布機(jī)制意味著在一個(gè)周期內(nèi)只發(fā)送一次數(shù)據(jù)，而HTTP在每次請(qǐng)求時(shí)都要發(fā)送頭部信息，這使得MQTT在傳輸大量數(shù)據(jù)時(shí)更加節(jié)省帶寬。2. 更好的延遲

連接機(jī)制：HTTP的客戶(hù)端-服務(wù)器模式每次請(qǐng)求都需要建立連接，這帶來(lái)了較高的延遲。而MQTT中，客戶(hù)端只需要與服務(wù)器建立一次連接，隨后的請(qǐng)求只需要發(fā)送一個(gè)小的數(shù)據(jù)包以更新?tīng)顟B(tài)，因此MQTT可以更快地更新設(shè)備狀態(tài)。3. 更高的可靠性

發(fā)布訂閱模式：MQTT使用的是發(fā)布訂閱模式，即使在網(wǎng)絡(luò)連接不穩(wěn)定的情況下，也能夠?qū)崿F(xiàn)數(shù)據(jù)的可靠傳輸。當(dāng)設(shè)備離線時(shí)，MQTT會(huì)將數(shù)據(jù)存儲(chǔ)在隊(duì)列中，直到設(shè)備重新上線時(shí)再將其發(fā)送。

自動(dòng)重連機(jī)制：MQTT具有自動(dòng)重連機(jī)制，即使網(wǎng)絡(luò)斷開(kāi)，也能夠自動(dòng)恢復(fù)連接，確保消息的可靠傳輸。4. 更好的安全性

加密協(xié)議：MQTT支持TLS/SSL加密協(xié)議，可以確保數(shù)據(jù)在傳輸過(guò)程中的安全性。而HTTP在傳輸過(guò)程中需要使用更復(fù)雜的安全措施，如HTTPS協(xié)議。5. 更好的擴(kuò)展性

多對(duì)多通信：MQTT支持多對(duì)多的通信模式，可以很容易地?cái)U(kuò)展到大型系統(tǒng)中。

低成本實(shí)現(xiàn)：MQTT的輕量級(jí)協(xié)議使得實(shí)現(xiàn)MQTT庫(kù)的成本較低，易于移植到不同的平臺(tái)上。6. 適用于資源受限的設(shè)備

低功耗：MQTT協(xié)議可以保持長(zhǎng)連接，在空閑時(shí)保持低功耗狀態(tài)，節(jié)省設(shè)備能源。

數(shù)據(jù)處理：MQTT以數(shù)據(jù)為中心，將數(shù)據(jù)作為字節(jié)數(shù)組傳輸，非常適合資源受限的設(shè)備并有助于節(jié)省電池。7. 高效的消息分發(fā)

發(fā)布訂閱模式：MQTT采用的發(fā)布/訂閱模式非常適合物聯(lián)網(wǎng)應(yīng)用中設(shè)備間的消息分發(fā)。這種模式允許單一設(shè)備向多個(gè)訂閱者同時(shí)發(fā)送消息，使得信息傳遞變得既高效又靈活。應(yīng)用代碼對(duì)比 MQTT 偽代碼示例// MQTT 客戶(hù)端連接到 MQTT 服務(wù)器  
mqttClient.connect("mqtt://broker.example.com:1883", clientId)  
  
// 訂閱特定主題  
mqttClient.subscribe("sensor/data", qos=1)  
  
// 發(fā)布消息到主題  
mqttClient.publish("sensor/data", "temperature=25.5C", qos=1)  
  
// 接收并處理消息  
onMessageReceived(message) {  
    if (message.topic == "sensor/data") {  
        processSensorData(message.payload)  
    }  
}
HTTP 偽代碼示例// HTTP 客戶(hù)端發(fā)送 GET 請(qǐng)求  
response = httpClient.get("http://api.example.com/sensor/data")  
  
// 處理響應(yīng)數(shù)據(jù)  
if (response.statusCode == 200) {  
    sensorData = parseSensorDataFromResponse(response.body)  
    processSensorData(sensorData)  
}  
  
// 發(fā)送 POST 請(qǐng)求以更新傳感器數(shù)據(jù)（通常不用于實(shí)時(shí)數(shù)據(jù)傳輸）  
requestBody = "temperature=25.5C"  
response = httpClient.post("http://api.example.com/update/sensor/data", requestBody)
實(shí)際例子對(duì)比分析 假設(shè)有一個(gè)智能家居系統(tǒng)，其中包含了多個(gè)智能燈泡和溫度傳感器。

使用 MQTT：每個(gè)燈泡和傳感器都作為MQTT客戶(hù)端連接到MQTT服務(wù)器（broker）。溫度傳感器定期發(fā)布包含溫度數(shù)據(jù)的消息到“sensor/temperature”主題。燈泡訂閱了該主題，并在接收到新的溫度數(shù)據(jù)時(shí)自動(dòng)調(diào)整亮度或顏色。這種方式下，燈泡和傳感器之間的通信是實(shí)時(shí)的，且即使在網(wǎng)絡(luò)不穩(wěn)定的情況下也能保持較高的可靠性。

使用 HTTP：每個(gè)燈泡和傳感器都需要定期向中央服務(wù)器發(fā)送HTTP請(qǐng)求以獲取或更新數(shù)據(jù)。例如，溫度傳感器需要發(fā)送HTTP POST請(qǐng)求來(lái)上傳溫度數(shù)據(jù)，而燈泡則需要發(fā)送HTTP GET請(qǐng)求來(lái)獲取最新的溫度數(shù)據(jù)以調(diào)整亮度。這種方式下，每個(gè)請(qǐng)求都需要等待服務(wù)器的響應(yīng)，且在網(wǎng)絡(luò)不穩(wěn)定或延遲較高時(shí)可能會(huì)導(dǎo)致問(wèn)題。此外，由于HTTP是無(wú)狀態(tài)的，燈泡可能需要在每次需要調(diào)整亮度時(shí)都重新獲取溫度數(shù)據(jù)。MQTT在物聯(lián)網(wǎng)應(yīng)用中的使用比HTTP更加合適，因?yàn)镸QTT擁有更好的帶寬利用率、更低的延遲、更高的可靠性、更好的安全性、更好的擴(kuò)展性，以及更適用于資源受限的設(shè)備。這些優(yōu)勢(shì)使得MQTT成為物聯(lián)網(wǎng)應(yīng)用中的首選協(xié)議。
猜你喜歡：
廢舊板子再利用：搭建無(wú)線調(diào)試環(huán)境！
WiFi6+藍(lán)牙+星閃，三合一開(kāi)發(fā)板，真香！
點(diǎn)擊閱讀原文，查看更多分享。