MQTT介紹（1）簡單介紹

---

MQTT目錄：

1. 　　MQTT簡單介紹

2.       window安裝MQTT服務器和client

3.       java模擬MQTT的發布，訂閱

---

 

 

 

 MQTT：

　　MQTT（Message Queuing Telemetry Transport，消息隊列遙測傳輸協議），是一種基於發布/訂閱（publish/subscribe）模式的“輕量級”通訊協議，該協議構建於TCP/IP協議上，由IBM在1999年發布。MQTT最大優點在於，可以以極少的代碼和有限的帶寬，為連接遠程設備提供實時可靠的消息服務。做為一種低開銷、低帶寬占用的即時通訊協議，使其在物聯網、小型設備、移動應用等方面有較廣泛的應用。

　　MQTT和CoAP是物聯網最常用的兩個協議。區別是：MQTT是基於TCP協議，CoAP是基於UDP協議

---

MQTT的特點：

　　MQTT是一個基於客戶端-服務器的消息發布/訂閱傳輸協議。MQTT協議是輕量、簡單、開放和易於實現的，這些特點使它適用范圍非常廣泛。在很多情況下，包括受限的環境中，如：機器與機器（M2M）通信和物聯網（IoT）。其在，通過衛星鏈路通信傳感器、偶爾撥號的醫療設備、智能家居（曾出現過安全問題，在后面會介紹到）、及一些小型化設備中已廣泛使用。

　　當期的發布最新版本還是14年發布的3.1.1，除標准版外，還有一個簡化版MQTT-SN，該協議主要針對嵌入式設備，這些設備一般工作於百TCP/IP網絡，如：ZigBee。

　　　　想學習的可以嗎參考　　

1. 1. 　　MQTTv3.1中文版.pdf,  
   2.       http://mqtt.org/

　　

　　MQTT協議運行在TCP/IP或其他網絡協議，提供有序、無損、雙向連接。其特點包括：

1. 1. 　使用的發布/訂閱消息模式，它提供了一對多消息分發，以實現與應用程序的解耦。
   2. 　對負載內容屏蔽的消息傳輸機制。
   3. 　對傳輸消息有三種服務質量（QoS）：
      • • 級別0：盡力而為(   <=1)。消息發送者會想盡辦法發送消息，但是遇到意外並不會重試。　　  
        • 級別1：至少一次(   >=1)。消息接收者如果沒有知會或者知會本身丟失，消息發送者會再次發送以保證消息接收者至少會收到一次，當然可能造成重復消息。 
        • 級別2：恰好一次(     =1)。保證這種語義肯定會減少並發或者增加延時，不過丟失或者重復消息是不可接受的時候，級別2是最合適的。 
   4. 　數據傳輸和協議交換的最小化（協議頭部只有2字節），以減少網絡流量
   5. 　通知機制，異常中斷時通知傳輸雙方

補充：QOS(服務質量)

為了滿足不同的場景，MQTT支持三種不同級別的服務質量（Quality of Service，QoS）為不同場景提供消息可靠性：

• 級別0：盡力而為。消息發送者會想盡辦法發送消息，但是遇到意外並不會重試。
• 級別1：至少一次。消息接收者如果沒有知會或者知會本身丟失，消息發送者會再次發送以保證消息接收者至少會收到一次，當然可能造成重復消息。
• 級別2：恰好一次。保證這種語義肯定會減少並發或者增加延時，不過丟失或者重復消息是不可接受的時候，級別2是最合適的。

服務質量是個老話題了。級別2所提供的不重不丟很多情況下是最理想的，不過往返多次的確認一定對並發和延遲帶來影響。級別1提供的至少一次語義在日志處理這種場景下是完全OK的，所以像Kafka這類的系統利用這一特點減少確認從而大大提高了並發。級別0適合雞肋數據場景，食之無味棄之可惜

 

　　

---

MQTT協議原理：

　　

　　　　

• • 　實現MQTT協議需要：客戶端和服務器端
  • 　MQTT協議中有三種身份：發布者（Publish）、代理（Broker）（服務器）、訂閱者（Subscribe）。其中，消息的發布者和訂閱者都是客戶端，消息代理是服務器，消息發布者可以同時是訂閱者。
  • 　MQTT傳輸的消息分為：主題（Topic）和負載（payload）兩部分
    • 　Topic，可以理解為消息的類型，訂閱者訂閱（Subscribe）后，就會收到該主題的消息內容（payload）
    • 　payload，可以理解為消息的內容，是指訂閱者具體要使用的內容

　　注：這種訂閱模式我會在下節搭建的時詳細說明

 

---

網絡傳輸與應用消息

　　MQTT會構建底層網絡傳輸：它將建立客戶端到服務器的連接，提供兩者之間的一個有序的、無損的、基於字節流的雙向傳輸。

　　當應用數據通過MQTT網絡發送時，MQTT會把與之相關的服務質量（QoS）和主題名（Topic）相關連。

 

MQTT的客戶端和服務器端，協議等簡單介紹：

　　　　客戶端：

　　　　一個使用MQTT協議的應用程序或者設備，它總是建立到服務器的網絡連接。客戶端可以：

• • • 發布其他客戶端可能會訂閱的信息
    • 訂閱其它客戶端發布的消息
    • 退訂或刪除應用程序的消息
    • 斷開與服務器連接

　　　　服務器端：

　　　　MQTT服務器以稱為“消息代理”（Broker），可以是一個應用程序或一台設備。它是位於消息發布者和訂閱者之間，它可以：

• • • 接受來自客戶的網絡連接
    • 接受客戶發布的應用信息
    • 處理來自客戶端的訂閱和退訂請求
    • 向訂閱的客戶轉發應用程序消息

　　　　MQTT協議中的訂閱、主題、會話

　　　　訂閱（Subscription）

　　　　　　訂閱包含主題篩選器（Topic Filter）和最大服務質量（QoS）。訂閱會與一個會話（Session）關聯。一個會話可以包含多個訂閱。每一個會話中的每個訂閱都有一個不同的主題篩選器。

　　　　會話（Session）

　　　　　　每個客戶端與服務器建立連接后就是一個會話，客戶端和服務器之間有狀態交互。會話存在於一個網絡之間，也可能在客戶端和服務器之間跨越多個連續的網絡連接。

　　　　主題名（Topic Name）

　　　　　　連接到一個應用程序消息的標簽，該標簽與服務器的訂閱相匹配。服務器會將消息發送給訂閱所匹配標簽的每個客戶端。

　　　　主題篩選器（Topic Filter）

　　　　　　一個對主題名通配符篩選器，在訂閱表達式中使用，表示訂閱所匹配到的多個主題。

　　　　負載（Payload）

　　　　　　消息訂閱者所具體接收的內容

　　　　

　　　　MQTT協議中的方法：

　　　　MQTT協議中定義了一些方法（也被稱為動作）， 來於表示對確定資源所進行操作。 這個資源可以代表預先存在的數據或動態生成數據，這取決於服務器的實現。通常來說，資源指服務器上的文件或輸出。

　　　　Connect，等待與服務器建立連接

　　　　Disconnect，等待MQTT客戶端完成所做的工作，並與服務器斷開TCP/IP會話

　　　　Subscribe，等待完成訂閱

　　　　UnSubscribe，等待服務器取消客戶端的一個或多個topics訂閱

　　　　Publish，MQTT客戶端發送消息請求，發送完成后返回應用程序線程

　　　　

　　　　

MQTT協議消息類型：(數據工會上給的另一種說法)
　MQTT擁有14種不同的消息類型：

CONNECT：客戶端連接到MQTT代理
CONNACK：連接確認
PUBLISH：新發布消息
PUBACK：新發布消息確認，是QoS 1給PUBLISH消息的回復
PUBREC：QoS 2消息流的第一部分，表示消息發布已記錄
PUBREL：QoS 2消息流的第二部分，表示消息發布已釋放
PUBCOMP：QoS 2消息流的第三部分，表示消息發布完成
SUBSCRIBE：客戶端訂閱某個主題
SUBACK：對於SUBSCRIBE消息的確認
UNSUBSCRIBE：客戶端終止訂閱的消息
UNSUBACK：對於UNSUBSCRIBE消息的確認
PINGREQ：心跳
PINGRESP：確認心跳
DISCONNECT：客戶端終止連接前優雅地通知MQTT代理