2020-10-15 MQTT基礎知識

MQTT同HTTP屬於第七層（應用層:面向使用者的一層，為使用者提供常用的應用程式）

 

1.機器之間的大規模溝通:釋出/訂閱（Publish/Subscribe）模式

它使傳送訊息的使用者端（釋出者）與接收訊息的使用者端（訂閱者）分離，釋出者與訂閱者不需要建立直接聯絡，中間代理根據主題負責所有訊息路由和分發的工作

物品則通過各種感測器進行資訊採集，然後通過計算裝置進行網路資訊交換與通訊

增強了整個系統的可靠性，當一個使用者端出現故障時，整個系統可以繼續正常工作。

 

2.MQTT是基於二進位制訊息的釋出/訂閱程式設計模式的訊息協定

基於TCP/IP協定棧

通俗來說是一個類似新浪微博的自動轉發伺服器

 

3.MQTT與HTTP比較

 

	HTTP	MQTT
相同點	都是應用層協定，都運用了底層協定TCP（三次握手） TCP/IP協定棧
	使用者端和伺服器之間是請求/應答模式，使用者端請求時，會建立一個HTTP連線，然後傳送請求訊息，伺服器端給出應答訊息，開銷大	釋出/訂閱模式 釋出者與訂閱者不需要建立直接聯絡，簡單、輕量、易於實現
	HTTP 是一種同步協定，使用者端需要等待伺服器響應	非同步訊息協定更適合 IoT 應用程式，因為大量裝置以及很可能不可靠或高延遲的網路使得同步通訊成為問題
	HTTP 是單向的,使用者端必須發起連線,才能得到響應	在 IoT 應用程式中，裝置或感測器通常是使用者端，這意味著它們無法被動地接收來自網路的命令

網路介面層——接受網路上的資料，抽出IP資料包，交給網路層

網路層——處理傳輸層請求，發往適當介面/接受輸入資料包

傳輸層——應用程式間通訊

應用層——給使用者提供服務

3.原理

MQTT協定中有三種身份：

伺服器 代理（Broker）

使用者端 釋出者（Publish）、訂閱者（Subscribe）

訊息釋出者可以同時是訂閱者

 

MQTT傳輸的訊息分為：

主題（Topic） 訊息的型別，訂閱者訂閱（Subscribe）後，就會收到該主題的訊息內容

負載（payload） 訊息的內容

 

完整流程

• 1） 啟動伺服器代理。

• 2） 訂閱者向伺服器代理訂閱相關主題。

• 3） 釋出者向伺服器代理髮布主題資訊。

• 4） 伺服器代理向所有訂閱該主題的訂閱者推播訊息。

 

有三種訊息釋出服務品質：

"至多一次"（Qos=0），訊息釋出完全依賴底層TCP/IP網路。會發生訊息丟失或重複。這一級別可用於如下情況，環境感測器資料，丟失一次讀記錄無所謂，因為不久後還會有第二次傳送。這一種方式主要普通APP的推播，倘若你的智慧裝置在訊息推播時未聯網，推播過去沒收到，再次聯網也就收不到了。

"至少一次"（Qos=1），確保訊息到達，但訊息重複可能會發生。

"只有一次"（Qos=2），確保訊息到達一次。在一些要求比較嚴格的計費系統中，可以使用此級別。在計費系統中，訊息重複或丟失會導致不正確的結果。這種最高品質的訊息釋出服務還可以用於即時通訊類的APP的推播，確保使用者收到且只會收到一次。

 

傳送訊息時，可以指定QoS，如果QoS>0，那麼訊息一定會發到Broker。訂閱主題時，也可以指定QoS，如果QoS>0，那麼Broker一定會將訊息發給訂閱者，不會丟失。這裡要要注意，訊息從釋出者到訂閱者，是分兩步走的，第一步有釋出者釋出到MQTT Broker，第二步是MQTT Broker轉發訊息到訂閱者。所以只有當釋出訊息時，指定QoS>0，並且訂閱主題時，QoS>0，訊息才能可靠的從釋出使用者端傳送到訂閱使用者端。