什么是物联网协议MQTT

物联网
MQTT是一个基于客户端-服务器的消息发布/订阅传输协议。由IBM在1999年发布。MQTT协议是轻量、简单、开放和易于实现的,这些特点使它适用范围非常广泛。

想了解更多关于开源的内容,请访问:

​51CTO 开源基础软件社区​

​https://ost.51cto.com​

1、MQTT简介

MQTT(消息队列遥测传输)是ISO 标准(ISO/IEC PRF 20922)下基于发布/订阅范式的消息协议。它工作在 TCP/IP协议族上,是为硬件性能低下的远程设备以及网络状况糟糕的情况下而设计的发布/订阅型消息协议,为此,它需要一个消息中间件 。

MQTT是一个基于客户端-服务器的消息发布/订阅传输协议。由IBM在1999年发布。MQTT协议是轻量、简单、开放和易于实现的,这些特点使它适用范围非常广泛。在很多情况下,包括受限的环境中,作为一种低开销、低带宽占用的即时通讯协议,使其在物联网、小型设备、移动应用等方面有较广泛的应用。如:机器与机器(M2M)通信和物联网(IoT)。其在通过链路通信传感器、偶尔拨号的医疗设备、智能家居、及一些小型化设备中已广泛使用。

MQTT最大优点在于,用极少的代码和有限的带宽,为连接远程设备提供实时可靠的消息服务。

#创作者激励#物联网协议MQTT-开源基础软件社区

2、MQTT特点

本协议运行在 TCP/IP,或其它提供了有序、可靠、 双向连接的网络连接上。MQTT属于应用层协议,它有以下特点:使用发布/订阅消息模式,提供了一对多的消息分发和应用之间的解耦。消息传输不需要知道负载内容。

提供三种等级的服务质量: .

  • QS0:“最多一次”,尽操作环境所能提供的最大努力分发消息。 消息可能会丢失。   例如, 这个等级可用于环境传感器数据,单次的数据丢失没关系, 因为不久之后会再次发送。
  • QS1:“至少一次”,保证消息可以到达, 但是可能会重复。
  • QS2: “仅一次”, 保证消息只到达一次。 例如, 这个等级可用在一个计费系统中, 这里如果消息重复或丢失会导致不正确的收费。很小的传输消耗和协议数据交换,最大限度减少网络流量。  

在MQTT连接建立时,客户端需要通过TCP连接到MQTT服务器,并进行握手协商,包括协议版本、客户端标识符、遗嘱消息、 QoS级别等信息,以确保双方能够正确地交换数据。一旦握手成功,客户端和服务器之间就建立了一个持久化的TCP连接,可以随时进行消息传输。
由于TCP协议本身已经提供了一定程度的可靠性保证,因此MQTT协议只需要在TCP的基础上实现发布/订阅机制、 QoS级别控制、保留消息等特性即可,从而使得它成为一种轻量级且高效的物联网通信协议。

3、MQTT协议数据量限制

MQTT协议本身没有限制数据包的大小,但是它需要遵循底层传输协议(TCP/IP)的限制和约束。在实际应用中,MQTT协议能够传输的有效数据量是受多种因素影响的,如网络带宽、QoS级别、MQTT消息头部信息等。一般来说,在默认情况下,MQTT协议对于单个消息的有效载荷有一个限制,即不超过256MB。这个限制主要由MQTT协议的消息长度字段决定,该字段的最大值是4字节,因此最大能表示2^32-1个字节的消息长度,即约为4GB。然而,在实际应用中,由于网络带宽和设备性能等方面的限制,很难实现传输如此巨大的消息。另外,需要注意的是,如果使用较高级别的QoS,如“至少一次”或“恰好一次”,则MQTT协议会对每条消息进行确认和重传,这可能会导致更多的网络流量和延迟。因此,在选择QoS级别时,需要根据应用场景和网络环境的实际情况进行优化和调整,以充分利用MQTT协议的特点和优势。

4、MQTT控制报文

MQTT协议通过交换预定义的 MQTT 控制报文来通信。MQTT 控制报文由三部分组成:固定报头(Fixed header)、可变报头(Variable header)、有效载荷(Payload)。

Fixed header 固定报头,所有控制报文都包含

Variable header 可变报头, 部分控制报文包含

Payload 有效载荷, 部分控制报文包含

(1)固定报头格式

#创作者激励#物联网协议MQTT-开源基础软件社区

控制报文类型

#创作者激励#物联网协议MQTT-开源基础软件社区

(2)MQTT控制报文类型集标志

固定报头第1个字节高4位(47)为控制报文类型,一共14个,低4位(03)包含每个 MQTT 控制报文类型特定的标志,见下表。表中任何标记为“保留”的标志位,都是保留给以后使用的,必须设置为表格中列出的值。如果收到非法的标志,接收者必须关闭网络连接。

#创作者激励#物联网协议MQTT-开源基础软件社区

DUP1 =控制报文的重复分发标志。

QoS2 = PUBLISH 报文的服务质量等级。

RETAIN3 = PUBLISH 报文的保留标志。

详情参考MQTT3.1协议。

(3)剩余长度计算

剩余长度(Remaining Length) 表示当前报文剩余部分的字节数,包括可变报头和负载的数据。 剩余长度不包括用于编码剩余长度字段本身的字节数。

剩余长度字段使用一个可变长度编码方案,对小于128的值它使用单字节编码。 更大的值按下面的方式处理。低7位有效位用于编码数据,最高有效位用于指示是否有更多的字节。 即剩余长度安装128进制进行计数,剩余长度字段最大 4 个字节。

剩余长度字段取值如下:

#创作者激励#物联网协议MQTT-开源基础软件社区

剩余长度按128进制计数,采用16进制方式表示,低字节在前。剩余长度编码示例:

①例如64:(64/128)取整=0,说明64不需要进位,1个字节即可表示,即:0x40。

②例如456:(456/128)取整=3,(3/128)取整=0,说明456需要2个字节表示。

第一个字节bit7=1,(bit0~bit6)=456%128=72=0x48,即第一个字节表示为:0xc8。

第二个字节bit7=3/128=0,(bit0~bit6)=3%128=3,即第二个字节表示位:0x3。

综上,456采用2个字节表示为:0xc8 0x3。

③例如100000:(100000/128)=781,(781/128)=6,说明100000需要3字节表示。

第一个字节bit7=1,(bit0~bit6)=100000%128=0x20,即第一个字节为0xa0。

第二个字节bit7=1,(bit0~bit6)=781%128=0x0d,即第二个字节为0x8d。

第三个字节bit7=0,(bit0~bit6)=6%128=6,即第三个字节为0x6。

综上,100000采用3字节表示为:0xa0 0x8d 0x6。

(4)剩余长度计算C语言实现示例

剩余长度编码

int MQTT_RemainSum(int data,u8 buff[])
{
int cnt=0;//记录编码的字节数
do
{
u8 encodedByte = data % 128;
data/=128;
if(data>0)
{
//若data超过128,则将最最高位置1
encodedByte=encodedByte|=0x80;
}
buff[cnt++]=encodedByte;

}while(data>0);
return cnt;//返回需要编码的字节数个数
}

剩余长度解码

int MQTT_remainGet(u8 buff[],int cnt)
{
int data=0;
int i=0;
int count=1;
for(;i<cnt;i++)
{
data+=(buff[i]&0x7f)*count;
count<<=7;
}
return data;
}

测试示例:

int main(int argc,char *argv[])
{
if(argc!=2)
{
printf("格式:./a.out <剩余长度>\n");
return 0;
}
int data=atoi(argv[1]);
u8 buff[4];
int cnt=MQTT_RemainSum(data,buff);
for(int i=0;i<cnt;i++)
{
printf("%#x ",buff[i]);
}
printf("\n");
printf("data=%d\n", MQTT_remainGet(buff,cnt));
}
[wbyq@wbyq work]$ ./a.out 64
0x40
data=64
[wbyq@wbyq work]$ ./a.out 456
0xc8 0x3
data=456
[wbyq@wbyq work]$ ./a.out 100000
0xa0 0x8d 0x6
data=100000
[wbyq@wbyq work]$ ./a.out 268435455
0xff 0xff 0xff 0x7f
data=268435455

5、MQTT消息等级

MQTT提供三种等级的服务质量。

  • QS0:“最多一次”,尽操作环境所能提供的最大努力分发消息。 消息可能会丢失。 例如,这个等级可用于环境传感器数据,  单次的数据丢失没关系, 因为不久之后会再次发送。
  • QS1:“至少一次”,保证消息可以到达, 但是可能会重复。
  • QS2: “仅一次”, 保证消息只到达一次。 例如, 这个等级可用在一个计费系统中,这里如果消息重复或丢失会导致不正确的收费。很小的传输消耗和协议数据交换,最大限度减少网络流量。

#创作者激励#物联网协议MQTT-开源基础软件社区

PUBLISH报文不能将 QoS所有的位设置为1。如果服务端或客户端收到QoS所有位都为 1的PUBLISH报文,它必须关闭网络连接。Qos0最多一次。

只发送一次消息,不进行重试。在协议中也没有定义重传的语义。消息可能到达服务器1次,也可能根本不会到达。

#创作者激励#物联网协议MQTT-开源基础软件社区

Qos1至少一次


服务器接收到消息会被确认,通过传输一个PUBACK信息。如果有一个可以辨认的传输失败,无论是通讯连接还是发送设备,还是过了一段时间确认信息没有收到,发送方都会将消息头的DUP位置1,然后再次发送消息。消息最少一次到达服务器。

如果客户端没有接收到PUBACK信息(无论是应用定义的超时,还是检测到失败然后通讯session重启),客户端都会再次发送PUBLISH信息,并且将DUP位置1。

它从客户端接收到重复的数据,服务器重新发送消息给订阅者,并且发送另一个PUBACK消息。

#创作者激励#物联网协议MQTT-开源基础软件社区


如上图所示, Qos1消息等级为了保证至少传达一次,发布方会将发送的消息本地暂存,并且会每隔一段时间重发一次,直到接收方返回应答为止。当我们收到应答后即可将暂存消息删除,停止重传。

对应接收方,则需要在每次收到消息后都要回复应答。在上图中publisher(发布方)到broker(代理方,服务器)和broker(代理方,服务器)到subscriber(订阅方)是同等的,两段通信都应按以上讨论的进行实现。

Qos2仅一次

#创作者激励#物联网协议MQTT-开源基础软件社区

QS2消息等级保证消息一定可以到达一次,publisher(发布方)到broker(代理方,服务器)和broker(代理方,服务器)到subscriber(订阅方)是同等的,两段通信都是相同等级。具体消息传输过程如下:

1.发布方发送消息,并将消息内容本地暂存。

2.接收方接收到消息内容后,将消息内容暂存本地,并给发送方回复一个应答(PUBREC),发布方在没有收到PUBREC之前会隔一段时间进行消息重发一次,以确保消息一定可以送达。

3.当发布方收到PUBREC后,则停止消息重发,并给接收方发送释放(PUBREL)消息内容,接收方收到PUBREL后即可确定消息传输成功。

4.删除暂存的消息,之后发送端每次收到PUBREC都直接发送一个PUBREL消息给接收端。

5.接收端在收到PUBREL消息后,修改暂存的消息状态为发布完成,停止发送PUBREC,然后给发送端发去一个发布完成(PUBCOM)的消息。此时接收端则将删除暂存的消息,之后每次收到PUBREL都直接回复PUBCOM。

6.发送端收到PUBCOM,如果发现暂存的消息还每删除的话,就删除暂存消息,如果已经删除了就不管了。

注意:在此过程中本地暂存消息的作用是为了在收到重复内容时可以实现去重,在接收到PUBREL后,就能确定发送端不再会发送此消息,所以这个时候就可以删除暂存消息了,同样的,发送端在接收到PUBREC后知道接收端已经接收到消息了,所以不必再发送消息,并且可以删除暂存了。

想了解更多关于开源的内容,请访问:

​51CTO 开源基础软件社区​

​https://ost.51cto.com​

责任编辑:jianghua 来源: 51CTO 开源基础软件社区
相关推荐

2023-09-24 23:18:50

2022-06-27 10:41:45

MQTT物联网协议

2024-03-26 11:52:13

2018-08-17 06:13:16

物联网协议MQTTMQTT-SN

2023-09-07 14:59:42

物联网MQTTCoAP

2023-07-18 10:38:09

2024-01-23 12:47:27

2024-01-12 07:46:07

MQTT协议物联网应用.NET

2020-11-15 23:25:50

物联网IoT协议IOT

2020-07-26 00:25:07

物联网IOT物联网应用

2022-10-28 11:44:44

物联网IoT

2023-04-19 15:02:01

MQTT人工智能物联网

2022-11-11 11:07:33

2020-03-26 07:52:20

物联网平台物联网IOT

2022-08-29 12:04:39

物联网节点物联网IOT

2022-12-07 15:04:16

物联网蜂窝物联网通信

2022-05-27 12:22:56

物联网物联网安全

2022-06-02 10:10:24

物联网传感器

2019-12-27 10:42:45

HTTPMQTT物联网

2013-04-28 10:29:07

MQTT物联网消息队列遥测传输
点赞
收藏

51CTO技术栈公众号