MQTT协议基础学习

已于 2023-11-09 10:51:32 修改
阅读量602 收藏
点赞数
文章标签： 学习 物联网 MQTT
于 2023-11-06 17:25:08 首次发布
版权声明：本文 遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。【个人网站： www.andus.top 】
本文链接：https://blog.csdn.net/github_33809414/article/details/134248953
版权

MQTT是什么

MQTT是一个客户端服务端架构的发布/订阅模式的消息传输协议。

MQTT基本原理

在这里插入图片描述

MQTT服务端

  • MQTT服务端通常是一台服务器，可对MQTT信息的接收、储存、处理和发送。
  • 负责将MQTT客户端发送来的信息传递给其他MQTT客户端（需要客户端订阅）。确保客户端之间的通讯顺畅，保证MQTT消息得以正确接收和准确投递。
  • 负责管理MQTT客户端。

MQTT客户端

  • 发布行为——向服务端发布信息。
  • 接收行为——从服务端收取信息。需要先要向服务端“订阅”信息（即告诉服务端需要哪些信息）。
  • 既可以作为信息发布者也可以同时作为信息订阅者。

MQTT主题

  • MQTT服务端在管理MQTT信息通讯时，就是使用“主题”来控制的。
  • 当某客户端向主题发送信息后，服务端会首先检查都有哪些客户端订阅了这一主题，再将信息转发给订阅了该主题的客户端。

主题基本形式

  • 主题是区分大小写的。motor_speed和Motor_speed是两个完全不同的主题。
  • 主题可以使用空格。如current time，虽然有空格分隔current和time这两个词，但这实际是一个MQTT主题。
  • 大部分MQTT服务端是不支持中文主题的。应使用英文字符或ASCII字符来作为MQTT主题。

主题分级

  • MQTT主题可以是一个简单的字符串，比如motor_speed，myTopic。这些都是单一级别的主题。
  • 为了更好的对主题进行管理和分类，可对主题进行分级处理。MQTT主题各个级别之间可以使用”/”来分隔。
单级通配符：+
  • 单级通配符可以代替一个主题级别。
    • 示例：home/sensor/+/temperature，可以收到home/sensor/kitchen/temperature、home/sensor/bedroom/temperature主题的信息内容。
多级通配符：#
  • 多级通配符”#”可以涵盖任意数量的主题级别。应放在最后

主题应用注意事项

  • 以$开始的主题是MQTT服务端系统保留的特殊主题，我们不能随意订阅或者向其发布信息。
    • $SYS/broker/clients/connected
    • $SYS/broker/clients/disconnected
    • $SYS/broker/clients/total
    • $SYS/broker/messages/sent
    • $SYS/broker/uptime
  • 不要用 “/” 作为主题开头
  • 主题中不要使用空格
  • 保持主题简洁明了
  • 主题中尽量使用ASCII字符
  • 在主题中嵌入客户端ID：通过主题中的客户端ID内容，我们可以很容易的了解该主题信息是由哪一台设备所发布的

MQTT 发布/订阅 特性

  • 相互可独立。MQTT客户端是一个个独立的个体，它们无需了解彼此的存在，依然可以实现信息交流。
  • 空间可分离。MQTT客户端在通讯必要条件是连接到了同一个MQTT通讯网络。这个网络可以是互联网或者局域网。只要客户端联网，无论他们远在天边还是近在眼前，都可以实现彼此间的通讯交流。
  • 时间可异步。MQTT客户端在发送和接收信息时无需同步。当客户端离线后，MQTT服务端可以将主题的新信息保存，待客户端再次上线后，服务端再将信息推送给客户端。

连接MQTT服务端

第一步：发送连接请求

MQTT客户端要想连接服务端，首先要向服务端发送CONNECT报文。如果此CONNECT报文的格式或内容不符合MQTT规范，则服务器会拒绝客户端的连接请求
CONNECT报文所包含的信息内容

  • CONNECT数据报文的作用：告诉服务端，客户端与服务端通信的模式。
    • clientId：客户端ID。同一个服务端不可重复，客户端身份标识
    • cleanSession：清除会话。true，告诉客户端不要保存任何会话内容；false，告诉客户端需要保存会话内容。客户端收到信息后需向服务端反馈“我已收到”，若客户端未反馈，服务端会保存会话内容并重复发送。
      • 请注意，如果需要服务端保存重要报文，光设置cleanSession 为false是不够的，还需要传递的MQTT信息QoS级别大于0。
    • keepAlive：心跳时间间隔（单位秒）。定期告诉服务端客户端的连接状态。

第二步：连接确认

MQTT服务端收到客户端连接请求后，会向客户端发送连接确认
CONNACK报文所包含的信息内容

  • CONNACK数据报文的作用：向客户端发送连接确。
    • returnCode：连接返回码。说明连接情况。数字0，表示成功连接。
      状态码
    • sessionPresent：当前会话。客户端与服务端cleanSession为false时，服务端会保存客户端未确认收到的信息。true：服务端告诉客户端有未确认的消息；false：表示客户端所有消息都已正常发送并接收。

发布、订阅、取消订阅

发布

  • MQTT客户端一旦连接到服务端，便可以发布消息。
  • 每条发布的MQTT消息必须包含一个主题。
  • MQTT服务器可以通过主题确定将消息转发给哪些客户端。
    在这里插入图片描述
  • MQTT客户端发布消息时，会向服务端发送PUBLISH报文。
    • topicName：主题名称。用于识别此信息应发布到哪一个主题。
    • qos：服务质量等级。QoS有三个级别：0、1和2（重要性一次增高）。QoS决定MQTT通讯有什么样的服务保证。
    • packetId：报文标识符。同的MQTT报文所拥有的标识符不同。MQTT设备可以通过该标识符对MQTT报文进行甄别和管理。请注意：报文标识符的内容与QoS级别有密不可分的关系。只有QoS级别大于0时，报文标识符才是非零数值。如果QoS等于0，报文标识符为0。
    • retainFlag ：保留标志。false：发布非保留消息。当客户端订阅了某一主题后，并不会马上接收到该主题的信息。只有在客户端订阅该主题后，服务端接收到该主题的新信息时，服务端才会将最新接收到的该主题信息推送给客户端。true：发布保留消息。客户端在订阅了某一主题后马上接收到一条该主题的信息（因为服务端保留了最新的payload）。
    • payload：有效载荷。通过MQTT所发送的实际内容。可以发送文本，图像等格式的内容。
    • dupFlag ：重复标志。true：接收方没有及时确认收到报文时，发送方会重复发送MQTT报文。请注意，重发标志只在QoS级别大于0时使用。

订阅

  • 客户端是通过向服务端发送SUBSCRIBE报文来实现主题订阅。
  • 请留意，一个SUBSCRIBE报文可以包含有单个或者多个订阅主题名。
  • 客户端在订阅主题时也可以明确QoS。服务端会根据SUBSCRIBE中的QoS来提供相应的服务保证。
  • 每一个SUBSCRIBE报文还包含有“报文标识符”。

订阅确认

  • 服务端接收到客户端的订阅报文后，会向客户端发送SUBACK报文确认订阅。
    • packetId：报文标识符。
    • returnCode ：订阅返回码。服务端会针对SUBSCRIBE报文中的所有订阅主题来逐一回复给客户端一个返回码。针对不同的主题订阅QoS，服务端的返回码会有所不同。
      在这里插入图片描述

取消订阅

  • 客户端向服务端发送UNSUBSCRIBE报文取消订阅。
    在这里插入图片描述
  • 同一个UNSUBSCRIBE报文可以同时包含多个取消订阅的主题名称。
  • UNSUBSCRIBE报文也包含“报文标识符”，MQTT设备可以通过该标识符对报文进行管理。

取消订阅确认

  • 服务端接收到UNSUBSCRIBE报文后，会向客户端发送取消订阅确认报文 – UNSUBACK报文。该报文含有客户端所发送的“取消订阅报文标识符”。客户端接收到UNSUBACK报文后就可以确认取消主题订阅已经成功完成了。

Qos 服务质量等级

  • 告知物联网系统，哪些信息是重要信息需要准确无误的传输，而哪些信息不那么重要，即使丢失也没有问题。

Qos三种服务质量级别

Qos=数字0，最多发一次

  • MQTT服务端和客户端不会对消息传输是否成功进行确认和检查。消息能否成功传输全看网络环境是否稳定。
  • 也就是说，在QoS为0时。发送端一旦发送完消息后，就完成任务了。发送端不会检查发出的消息能否被正确接收到。

Qos=数字1，最少发一次（可能重复接收）

  • 发送端将消息发送给接收端后，会等待接收端的确认。接收端成功接收消息后，会发送一条确认报文PUBACK给发送端。如果发送端收到了这条PUBACK确认报文，那么它就知道消息已经成功接收。
  • 若发送端没有收到PUBACK报文，那么发送端会再次发送消息，然后再次等待接收端的PUBACK确认报文。因此，当QoS=1时，发送端在没有收到接收端的PUBACK确认报文以前，会重复发送同一条消息。
  • 当发送端重复发送一条消息时，PUBLISH报文中的dupFlag会被设置为True。这是为了告诉接收端，此消息为重复发送的消息。

Qos=数字2，保证只收一次

  • 发送端需要接收端进行两次消息确认。①发送端发送Qos=2的PUBLISH报文给接收端。②接收端收到QoS为2的消息后，会返回PUBREC报文作为应答。③发送端收到PUBREC报文后，会把此报文进行存储，并且返回PUBREL报文作为应答。④当接收端收到PUBREL报文后，会应答发送端一条PUBCOMP报文。

设置Qos

Qos=1

  • 接收端连接服务端时需将CONNECT报文中cleanSession设置为false
  • 接收端订阅主题时SUBSCRIBE数据包中QoS=1
  • 发布端发布消息时PUBLISH数据包中QoS=1

Qos=2

  • 接收端连接服务端时需将CONNECT报文中cleanSession设置为false
  • 接收端订阅主题时SUBSCRIBE数据包中QoS=2
  • 发布端发布消息时PUBLISH数据包中QoS=2

服务质量降级（最低级原则）

  • 假如客户端在发布和订阅信息时使用不同级别的QoS，服务端会主动采用较低级别的QoS来实现消息传输。
  • 情况一：发布端发布消息时PUBLISH数据包中QoS=2，接收端订阅主题时SUBSCRIBE数据包中QoS=1。此时，服务端向接收端发送消息时，采用的Qos为1。
  • 情况二：发布端发布消息时PUBLISH数据包中QoS=0，接收端订阅主题时SUBSCRIBE数据包中QoS=1。此时，服务端向接收端发送消息时，采用的Qos为0。

小结

  • 若想实现QoS>0，订阅端连接服务端时cleanSession需要设置为false，订阅端订阅主题时QoS>0，发布端发布消息时的QoS>0。
  • 服务端会选择发布消息和订阅消息中较低的QoS来实现消息传输，这也被称作“服务降级”。
  • QoS = 0, 占用的网络资源最低，但是接收端可能会出现无法接收消息的情况，所以适用于传输重要性较低的信息。
  • QoS = 1, MQTT会确保接收端能够接收到消息，但是有可能出现接收端反复接收同一消息的情况。
  • QoS = 2, MQTT会确保接收端只接收到一次消息。但是QoS为2时消息传输最慢，另外消息传输需要多次确认，因此所占用的网络资源也是最多的。此类服务等级适用于重要消息传输。
  • 由于QoS1和QoS2都能确保客户端接收到消息，但是QoS1所占用的资源较QoS2占用资源更小。因此建议使用QoS1来实现网络资源较为珍贵的环境下传输重要信息。

心跳机制

在这里插入图片描述

  • 服务端可以使用类似心跳检测的方法，来判断客户端是否在线。
  • 客户端在没有向服务端发送信息时，可以定时向服务端发送一条消息。这条用于心跳机制的消息也被称作心跳请求（PINGREQ）。
  • 服务端在收到客户端的心跳请求后，会回复一条消息。这条回复消息被称作心跳响应（PINGRESP）。
  • 由于心跳请求是客户端定时发送的，一旦服务端发现客户端停止发送请求信息，那么服务端就会知道，这台客户端已经断开了连接。同时，也可用于客户端判断自己与服务端是否保持连接。

设置心跳间隔

  • 在客户端连接服务端时，会将心跳时间间隔信息放入CONNECT报文中keepAlive字段（单位秒）。

心跳机制详情

  • 客户端在心跳时间间隔内发布了消息给服务端，那么服务端不需要客户端发送心跳请求也可以确定该客户端肯定在线。
  • 客户端在心跳间隔内没有发布消息给服务端，这时客户端会主动发送一个心跳请求消息给服务端。以表明自己仍让在线。
  • 在实际运行中，如果服务端没有在1.5倍心跳时间间隔内收到客户端发布消息(PUBLISH)或发来心跳请求(PINGREQ)，那么服务端就会认为这个客户端已经掉线。举例来说，如果心跳时间间隔是60秒。那么服务端在90秒内没有收到客户端发布的消息也没有收到PINGREQ请求，那么它就会认为客户端已经掉线。

MQTT遗嘱

  • MQTT协议允许客户端在“活着”的时候就写好遗嘱，这样一旦客户端意外断线，服务端就可以将客户端的遗嘱公之于众。客户端的遗嘱只在意外断线时才会发布，如果客户端正常的断开了与服务端的连接，这个遗嘱机制是不会启动的，服务端也不会将客户端的遗嘱公布。
  • 服务端在没有收到DISCONNECT报文的情况下，发现客户端“心跳”停止了，这时服务端就知道客户端是意外断线了。
  • 客户端正常断开连接时，会向服务端发送DISCONNECT报文，服务端接收到该报文后，就知道，客户端是正常断开连接，而并非意外断开连接。
    在这里插入图片描述

客户端如何将遗嘱消息发送给服务端

在这里插入图片描述

  • 在上图的CONNECT报文中，使用红色对一系列信息进行了标注。客户端正是在连接服务端时，利用这一系列信息将遗嘱消息发送给服务端。
  • lastWillTopic ：遗嘱主题。遗嘱消息和普通MQTT消息很相似，也有主题和正文内容。
  • lastWillMessage ：遗嘱消息（遗嘱正文）。只有那些订阅了遗嘱主题的客户端才会收到本客户端的遗嘱消息。
  • lastWillQoS ：遗嘱QoS。使用服务质量来控制遗嘱消息的传递和接收。（与普通MQTT消息的服务质量是一样0、1、2三个级别）
  • lastWillRetain ：遗嘱保留。设置遗嘱消息是否需要进行保留处理。

遗嘱操作注意事项

  • 假设我们现在有一台MQTT客户端。它的client id是 client-1。它的遗嘱主题是“client-1-will”
  • 当client-1连接服务端时，CONNECT报文中的遗嘱消息是“offline”。并且它的遗嘱保留设置为true。
  • 当client-1成功连接服务端后，立即向遗嘱主题“client-1-will”发布一条消息“online”。同时在发布此消息时，保留标志设置为true。这样，只要client-1在线，那么任何设备一订阅“client-1-will”就能收到设备在线的消息“online”。
  • 如果client-1发生意外离线。那么任何设备一订阅“client-1-will”就会收到设备离线的消息”offline”。
  • 如果client-1恢复连接，那么它会将遗嘱主题“client-1-will”的保留消息更改为“online”，这样任何设备一订阅“client-1-will”就能收到设备在线的消息“online”。

特别感谢
教程来源： 太极创客

松林羊
关注
MQTT协议资料及源码
05-09
MQTT（Message Queuing ...无论是想要理解MQTT协议的基础概念，还是深入研究其内部工作原理，或者直接使用源码进行开发，都能从中受益。通过学习和实践，我们可以更好地利用MQTT来构建高效、可靠的物联网通信系统。
MQTT 协议快速入门
CSDN人工智能头条
01-07 602
MQTT 协议快速入门课程简介：MQTT 协议实例全解析MQTT 协议的最佳实践和反模式MQTT 协议的安全性实践AI+IoT 项目实战本课程深入浅出地介绍了 MQTT ...
MQTT协议的简单介绍和服务器的安装
Scott Wang
04-12 2723
最近公司做的项目中有用到消息推送，经过多方面的筛选之后确定了使用MQTT协议，相对于XMPP，MQTT更加轻量级，并且占用用户很少的带宽。 MQTT是IBM推出的一种针对移动终端设备的基于TCP/IP的发布/预订协议，可以连接大量的远程传感器和控制设备。 MQTT的官网见：http://mqtt.org/。其中http://mqtt.org/software里面提供了官方推荐的各种服务
MQTT主题Topic讲解
热门推荐
jacklin_01的博客
09-06 4万+
参考：https://www.cnblogs.com/hayasi/p/7792191.html 如果传统的通信方式是客户端和服务端之间一般就直接传输信息。但是MQTT的通信方式是通过发布/订阅的方式进行的。笔者不知道他是否跟设计模式中的发布订阅模式有没有关系。可是他们思想却有一点相似之处。 客户端知道服务上有很多个主题。就好比如说有很多消息的分类一样子。有社会新闻、体育讲坛等。那么客户端只要...
IoT物联网平台通信MQTT之Topic定义方式
LXDOS的专栏
03-23 8809
IoT物联网平台通信MQTT之Topic定义方式
MQTT物联网
m0_72749070的博客
10-01 7746
MQTT物联网简介
Mqtt主题那点事(topic)
zona_wzq的博客
03-13 4386
2、主题（消息路由），子主题，分组订阅(共享订阅) （1） 常见的主题形式以及定义 mqtt 常见的topic 形式举例 chat/room/1 sensor/10/temperature sensor/+/temperature $SYS/broker/metrics/packets/received $SYS/broker/metrics/# $queue/t/1 $share/abc/t/1 定义形式： 可以理解问文件式的分层结构： chat/root/1，主题是以 ”/“ 分割的
MQTT Topic通配符
最新发布
Java 技术专栏，从入门到精通，熟悉企业级开发
03-13 7409
在MQTT世界里，我们使用编程语言对接MQTT，通常需要做2个事情，发布和订阅。一般来说，我们可以当做消息队列来使用，对使用过MQ的同学来说是非常容易上手的。 今天为大家讲一下订阅的topic这块，在物联网实际应用中，通常都会有成千上万的物联网设备，通常订阅设备消息都主题名称：message/设备imei。 这时候程序如何去订阅这些机器呢？难道要去订阅成千上万的topic吗？ MQTT给出了解决方案，可以使用Topic通配符去订阅主题。
整理的MQTT协议
04-26
MQTT协议基础 - **协议模型**：MQTT基于客户端-服务器架构，使用发布/订阅模式进行通信。每个主题（Topic）对应一个消息队列，客户端可以作为发布者发布消息到主题，也可以作为订阅者接收特定主题的消息。 - **...
MQTT 协议文档
07-05
### MQTT协议概述 MQTT（Message Queuing Telemetry Transport）是一种轻量级的消息发布/订阅协议，它设计用于低带宽、高延迟或不...这些知识点为初学者提供了关于MQTT协议的初步理解，为进一步深入学习奠定了基础。
MQTT协议及源码
09-21
1. **MQTT协议基础** MQTT的核心理念是发布/订阅模型，它允许客户端（publishers）发布消息到特定的主题（topics），而其他客户端（subscribers）可以订阅这些主题以接收消息。这种模式确保了消息的分发和解耦。 2...
基于c#实现MQTT协议的报文封装
04-18
首先，我们需要理解MQTT协议的基础。MQTT采用TCP/IP协议栈，其核心概念包括发布者（Publishers）、订阅者（Subscribers）和代理（Broker）。发布者发送消息到特定的主题（Topics），订阅者则对感兴趣的主题进行订阅...
mqtt 入门+开发
csdnzhang365的博客
04-08 6531
简介 MQTT(消息队列遥测传输)是ISO 标准(ISO/IEC PRF 20922)下基于发布/订阅范式的消息协议。 它工作在TCP/IP协议族上，是为硬件性能低下的远程设备以及网络状况糟糕的情况下而设计的发布/订阅型消息协议，为此，它需要一个消息中间件。 实现方式 实现MQTT协议需要客户端和服务器端通讯完成。 在通讯过程中，MQTT协议中有三种身份：发布者（Publish）、代理（...
MQTT入门手册
青鸟飞鱼
05-22 3433
发布订阅模式（Publish-SubscribePattern）是一种消息传递模式，它将发送消息的客户端（发布者）与接收消息的客户端（订阅者）解耦，使得两者不需要建立直接的联系也不需要知道对方的存在。MQTT 发布/订阅模式的精髓在于由一个被称为代理（Broker）的中间角色负责所有消息的路由和分发工作，发布者将带有主题的消息发送给代理，订阅者则向代理订阅主题来接收感兴趣的消息。
mqtt协议_MQTT协议解析
weixin_39814454的博客
11-19 676
这篇属于IM三剑客中的第二篇，前面一篇主要讲解了通用IM的一些架构的知识，这边主要讲解MQTT协议的细节，最后一篇将会着重介绍了MQTT Broker的Go语言实现。通用IM架构Go实现Mqtt broker MQTT协议以其效率高，语义完善而著名，非常适合使用在移动设备中，可以大幅度的减少耗电量。相对于TCP，语义更加丰富，额外的overload小，最少只需要2byte；相对于其他的应用层协...
mqtt--Topic主题
果果的博客
11-11 1527
MQTT是基于topic来发布消息的，发布者在发布消息时需要指定该消息发布在哪个topic下 topic最容易的理解方式是文件夹路径。如果有成千上万的不同类型的文件要保存，为了合理放置这些文件，需要创建一系列有层次性的文件夹来管理它们。发布消息就好比把文件保存到不同的文件夹下。 注意： topic名是大小写敏感的。 topic名中的每个主题级别可以使用任何UTF-8字符 尽可能避免使用美元符开头。因为一般MQTT服务器都会使用开头。因为一般MQTT服务器都会使用开头。因为一般MQTT服务器都会使
MQTT客户端实用实例
liuge3452的博客
10-13 868
基于qmqtt开源库实现MQTT客户端的方法，实现基于主题的消息发送、订阅等功能，以及具备了友好的人机界面。 本资源具备完整的实现方法，能够正常编译运行，编译和运行环境要求如下： 1、编译环境：Qt 4.8.4 2、运行环境：ubuntu、Windows、linx、麒麟等操作系统。
MQTT Client&Broker链接分析
loushanlin的博客
05-09 1814
连接流程 MQTT协议，Client需要与Broker进行数据通信，如订阅或者发布信息时，需要主动发起通信建立连接。如下图所示，流程简单，双方建立TCP连接后： Client向Broker发送CONNECT报文。 Broker接收到Connect报文后，向Client发送CONACK报文。 CONNECT报文组成 CONNECT报文共3个字段。 字段 描述 Fixed Header 固定包头 Variable Header 可变包头 Payload 有效载荷 Fixed H
MQTT协议解析与Moquette源码探索
"本文档是关于消息推送及MQTT协议的学习总结，主要涵盖了推送的现状、Android推送方案的比较、MQTT协议的详细解析，包括不同QoS级别的消息流，以及MQTT 3.1.1的新特性。此外，还涉及了开源MQTT代理服务器Moquette的...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值