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，訊息才能可靠的從發布客戶端發送到訂閱客戶端，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/183366.html
標籤：其他