原理简介_消息通信的利器MQTT协议简介及协议原理
- 沒用過但是必須得知道系列 -
前言：
相比于 XMPP， MQTT 的簡單輕量受到了不少工程師的喜愛，從物聯(lián)網(wǎng)到傳統(tǒng)的消息服務(wù)，簡單可依賴的 MQTT 到底為何讓人如此著迷呢？
MQTT 協(xié)議－MQTT 協(xié)議簡介及協(xié)議原理
MQTT(Message Queuing Telemetry Transport，消息隊列遙測傳輸協(xié)議)，是一種基于發(fā)布/訂閱( publish/subscribe )模式的“輕量級”通訊協(xié)議，該協(xié)議構(gòu)建于TCP/IP協(xié)議上，由IBM在1999年發(fā)布。MQTT最大優(yōu)點在于，可以以極少的代碼和有限的帶寬，為連接遠程設(shè)備提供實時可靠的消息服務(wù)。作為一種低開銷、低帶寬占用的即時通訊協(xié)議，使其在物聯(lián)網(wǎng)、小型設(shè)備、移動應用等方面有較廣泛的應用。
1. MQTT協(xié)議特點
MQTT是一個基于客戶端-服務(wù)器的消息發(fā)布/訂閱傳輸協(xié)議。MQTT協(xié)議是輕量、簡單、開放和易于實現(xiàn)的，這些特點使它適用范圍非常廣泛。在很多情況下，包括受限的環(huán)境中，如：機器與機器(M2M)通信和物聯(lián)網(wǎng)(IoT)。其在，通過衛(wèi)星鏈路通信傳感器、偶爾撥號的醫(yī)療設(shè)備、智能家居、及一些小型化設(shè)備中已廣泛使用。
MQTT協(xié)議當前版本為，2014年發(fā)布的MQTT v3.1.1。除標準版外，還有一個簡化版MQTT-SN，該協(xié)議主要針對嵌入式設(shè)備，這些設(shè)備一般工作于TCP/IP網(wǎng)絡(luò)，如：ZigBee。
MQTT協(xié)議運行在TCP/IP或其他網(wǎng)絡(luò)協(xié)議，提供有序、無損、雙向連接。其特點包括：
使用的發(fā)布/訂閱消息模式，它提供了一對多消息分發(fā)，以實現(xiàn)與應用程序的解耦。
對負載內(nèi)容屏蔽的消息傳輸機制。
對傳輸消息有三種服務(wù)質(zhì)量(QoS)：
最多一次，這一級別會發(fā)生消息丟失或重復，消息發(fā)布依賴于底層TCP/IP網(wǎng)絡(luò)。即：<=1
至多一次，這一級別會確保消息到達，但消息可能會重復。即：>=1
只有一次，確保消息只有一次到達。即：＝1。在一些要求比較嚴格的計費系統(tǒng)中，可以使用此級別
數(shù)據(jù)傳輸和協(xié)議交換的最小化(協(xié)議頭部只有2字節(jié))，以減少網(wǎng)絡(luò)流量
通知機制，異常中斷時通知傳輸雙方
2. MQTT協(xié)議原理
2.1 MQTT協(xié)議實現(xiàn)方式
實現(xiàn)MQTT協(xié)議需要：客戶端和服務(wù)器端
MQTT協(xié)議中有三種身份：發(fā)布者(Publish)、代理(Broker)(服務(wù)器)、訂閱者(Subscribe)。其中，消息的發(fā)布者和訂閱者都是客戶端，消息代理是服務(wù)器，消息發(fā)布者可以同時是訂閱者。
MQTT傳輸?shù)南⒎譃?#xff1a;主題(Topic)和負載(payload)兩部分
Topic，可以理解為消息的類型，訂閱者訂閱(Subscribe)后，就會收到該主題的消息內(nèi)容(payload)
payload，可以理解為消息的內(nèi)容，是指訂閱者具體要使用的內(nèi)容
2.2 網(wǎng)絡(luò)傳輸與應用消息
MQTT會構(gòu)建底層網(wǎng)絡(luò)傳輸：它將建立客戶端到服務(wù)器的連接，提供兩者之間的一個有序的、無損的、基于字節(jié)流的雙向傳輸。
當應用數(shù)據(jù)通過MQTT網(wǎng)絡(luò)發(fā)送時，MQTT會把與之相關(guān)的服務(wù)質(zhì)量(QoS)和主題名(Topic)相關(guān)聯(lián)。
2.3 MQTT客戶端
一個使用MQTT協(xié)議的應用程序或者設(shè)備，它總是建立到服務(wù)器的網(wǎng)絡(luò)連接?？蛻舳丝梢?#xff1a;
發(fā)布其他客戶端可能會訂閱的信息
訂閱其它客戶端發(fā)布的消息
退訂或刪除應用程序的消息
斷開與服務(wù)器連接
2.4 MQTT服務(wù)器
MQTT服務(wù)器稱為“消息代理”(Broker)，可以是一個應用程序或一臺設(shè)備。它是位于消息發(fā)布者和訂閱者之間，它可以：
接受來自客戶的網(wǎng)絡(luò)連接
接受客戶發(fā)布的應用信息
處理來自客戶端的訂閱和退訂請求
向訂閱的客戶轉(zhuǎn)發(fā)應用程序消息
2.5 MQTT協(xié)議中的訂閱、主題、會話
訂閱(Subscription)
訂閱包含主題篩選器(Topic Filter)和最大服務(wù)質(zhì)量(QoS)。訂閱會與一個會話(Session)關(guān)聯(lián)。一個會話可以包含多個訂閱。每一個會話中的每個訂閱都有一個不同的主題篩選器。
會話(Session)
每個客戶端與服務(wù)器建立連接后就是一個會話，客戶端和服務(wù)器之間有狀態(tài)交互。會話存在于一個網(wǎng)絡(luò)之間，也可能在客戶端和服務(wù)器之間跨越多個連續(xù)的網(wǎng)絡(luò)連接。
主題名(Topic Name)
連接到一個應用程序消息的標簽，該標簽與服務(wù)器的訂閱相匹配。服務(wù)器會將消息發(fā)送給訂閱所匹配標簽的每個客戶端。
主題篩選器(Topic Filter)
一個對主題名通配符篩選器，在訂閱表達式中使用，表示訂閱所匹配到的多個主題。
負載(Payload)
消息訂閱者所具體接收的內(nèi)容
2.6 MQTT協(xié)議中的方法
MQTT協(xié)議中定義了一些方法(也被稱為動作)， 來表示對確定資源所進行操作。這個資源可以代表預先存在的數(shù)據(jù)或動態(tài)生成數(shù)據(jù)，這取決于服務(wù)器的實現(xiàn)。通常來說，資源指服務(wù)器上的文件或輸出。
Connect，等待與服務(wù)器建立連接
Disconnect，等待MQTT客戶端完成所做的工作，并與服務(wù)器斷開TCP/IP會話
Subscribe，等待完成訂閱
UnSubscribe，等待服務(wù)器取消客戶端的一個或多個topics訂閱
Publish，MQTT客戶端發(fā)送消息請求，發(fā)送完成后返回應用程序線程
3.?MQTT數(shù)據(jù)結(jié)構(gòu)
MQTT 數(shù)據(jù)包結(jié)構(gòu)
固定頭(Fixed header)，存在于所有MQTT數(shù)據(jù)包中，表示數(shù)據(jù)包類型及數(shù)據(jù)包的分組類標識
可變頭(Variable header)，存在于部分MQTT數(shù)據(jù)包中，數(shù)據(jù)包類型決定了可變頭是否存在及其具體內(nèi)容
消息體(Payload)，存在于部分MQTT數(shù)據(jù)包中，表示客戶端收到的具體內(nèi)容
3.1 MQTT固定頭
固定頭存在于所有MQTT數(shù)據(jù)包中，其結(jié)構(gòu)如下：
| byte 1 | MQTT數(shù)據(jù)包類型 | 不同類型MQTT數(shù)據(jù)包的具體標識 | ||||||
| byte 2… | 剩余長度 | |||||||
3.1.1?MQTT數(shù)據(jù)包類型
位置：byte 1, bits 7-4。
相于一個4位的無符號值，類型如下：
| Reserved | 0 | 不可用 | 保留位 |
| CONNECT | 1 | 客戶端到服務(wù)器 | 客戶端請求連接到服務(wù)器 |
| CONNACK | 2 | 服務(wù)器到客戶端 | 連接確認 |
| PUBLISH | 3 | 雙向 | 發(fā)布消息 |
| PUBACK | 4 | 雙向 | 發(fā)布確認 |
| PUBREC | 5 | 雙向 | 發(fā)布收到(保證第1部分到達) |
| PUBREL | 6 | 雙向 | 發(fā)布釋放(保證第2部分到達) |
| PUBCOMP | 7 | 雙向 | 發(fā)布完成(保證第3部分到達) |
| SUBSCRIBE | 8 | 客戶端到服務(wù)器 | 客戶端請求訂閱 |
| SUBACK | 9 | 服務(wù)器到客戶端 | 訂閱確認 |
| UNSUBSCRIBE | 10 | 客戶端到服務(wù)器 | 請求取消訂閱 |
| UNSUBACK | 11 | 服務(wù)器到客戶端 | 取消訂閱確認 |
| PINGREQ | 12 | 客戶端到服務(wù)器 | PING請求 |
| PINGRESP | 13 | 服務(wù)器到客戶端 | PING應答 |
| DISCONNECT | 14 | 客戶端到服務(wù)器 | 中斷連接 |
| Reserved | 15 | 不可用 | 保留位 |
3.1.2?標識位
位置：byte 1, bits 3-0。
在不使用標識位的消息類型中，標識位被作為保留位。如果收到無效的標志時，接收端必須關(guān)閉網(wǎng)絡(luò)連接：
| CONNECT | 保留位 | 0 | 0 | 0 | 0 |
| CONNACK | 保留位 | 0 | 0 | 0 | 0 |
| PUBLISH | MQTT 3.1.1使用 | DUP1 | QoS2 | QoS2 | RETAIN3 |
| PUBACK | 保留位 | 0 | 0 | 0 | 0 |
| PUBREC | 保留位 | 0 | 0 | 0 | 0 |
| PUBREL | 保留位 | 0 | 0 | 0 | 0 |
| PUBCOMP | 保留位 | 0 | 0 | 0 | 0 |
| SUBSCRIBE | 保留位 | 0 | 0 | 0 | 0 |
| SUBACK | 保留位 | 0 | 0 | 0 | 0 |
| UNSUBSCRIBE | 保留位 | 0 | 0 | 0 | 0 |
| UNSUBACK | 保留位 | 0 | 0 | 0 | 0 |
| PINGREQ | 保留位 | 0 | 0 | 0 | 0 |
| PINGRESP | 保留位 | 0 | 0 | 0 | 0 |
| DISCONNECT | 保留位 | 0 | 0 | 0 | 0 |
DUP：發(fā)布消息的副本。用來在保證消息的可靠傳輸，如果設(shè)置為 1，則在下面的變長中增加MessageId，并且需要回復確認，以保證消息傳輸完成，但不能用于檢測消息重復發(fā)送。
QoS：發(fā)布消息的服務(wù)質(zhì)量，即：保證消息傳遞的次數(shù)
00：最多一次，即：<=1
01：至少一次，即：>=1
10：一次，即：=1
11：預留
RETAIN：發(fā)布保留標識，表示服務(wù)器要保留這次推送的信息，如果有新的訂閱者出現(xiàn)，就把這消息推送給它，如果設(shè)有那么推送至當前訂閱者后釋放。
3.1.3?剩余長度(Remaining Length)
位置：byte 1。
固定頭的第二字節(jié)用來保存變長頭部和消息體的總大小的，但不是直接保存的。這一字節(jié)是可以擴展，其保存機制，前7位用于保存長度，后一部用做標識。當最后一位為 1時，表示長度不足，需要使用二個字節(jié)繼續(xù)保存。例如：計算出后面的大小為 0
3. 2 MQTT可變頭
MQTT數(shù)據(jù)包中包含一個可變頭，它駐位于固定的頭和負載之間。可變頭的內(nèi)容因數(shù)據(jù)包類型而不同，較常的應用是做為包的標識：
| byte 1 | 包標簽符(MSB) | |||||||
| byte 2… | 包標簽符(LSB) | |||||||
很多類型數(shù)據(jù)包中都包括一個2字節(jié)的數(shù)據(jù)包標識字段，這些類型的包有：PUBLISH (QoS > 0)、PUBACK、PUBREC、PUBREL、PUBCOMP、SUBSCRIBE、SUBACK、UNSUBSCRIBE、UNSUBACK
3. 3 Payload 消息體
Payload 消息體位于 MQTT 數(shù)據(jù)包的第三部分，CONNECT、SUBSCRIBE、SUBACK、UNSUBSCRIBE四種類型的消息 有消息體：
CONNECT，消息體內(nèi)容主要是：客戶端的ClientID、訂閱的Topic、Message 以及用戶名和密碼。
SUBSCRIBE，消息體內(nèi)容是一系列的要訂閱的主題以及QoS。
SUBACK，消息體內(nèi)容是服務(wù)器對于?SUBSCRIBE?所申請的主題及?QoS?進行確認和回復。
UNSUBSCRIBE，消息體內(nèi)容是要訂閱的主題。
更多請查看
MQTT 3.1.1 規(guī)范?http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/mqtt-v3.1.1.htmlMQTT 3.1.1 規(guī)范中文版?https://mcxiaoke.gitbooks.io/mqtt-cn/content/
總結(jié)
以上是生活随笔為你收集整理的原理简介_消息通信的利器MQTT协议简介及协议原理的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 国外知名度比较高的短视频社交软件有哪些
- 下一篇： protect 继承_(转)public