首页 > 编程知识 正文

mqtt协议应用实例,mqtt协议和tcp协议区别

时间:2023-05-06 03:16:41 阅读:44142 作者:4908

使用物联网协议-MQTT协议的未加密消息传输物联网系统中的网络协议是物联网设备之间交流的“语言”,只有使用相同的语言,双方才能成功通信MQTT协议最为流行,已成为物联网系统事实上的网络协议标准。

第一步是安装hbhbmqtt,它是一个基于Python语言的开源mqtt中介软件。 这包括需要使用一些工具。 可以通过打开终端并输入pip命令来安装hbmqtt。 这也是选择使用它的主要理由。

但是,请注意,hbmqtt是基于Python3实现的,因此这里使用的是pip3工具。

安装pip3 install hbmqtt后,可以使用hbmqtt提供的两个命令行工具: hbmqtt_sub和hbmqtt_pub。 您也应该从名称中看到hbmqtt_sub作为订阅者。hbmqtt_pub可以用作消息的发布者。

对于订阅者和发布者之间的kq滴滴涕(mqtt中介),我们使用Eclipse的免费开放在线中介服务。

链接:链接。

打开链接后,将显示有关端口的介绍信息。 同时支持加密和非加密方法。 另外,还有基于web套接字的实现。 这对基于前端网络的APP应用非常有利。

首先使用1883端口的非加密方法,然后确定消息传输的主题(主题)。 主题确定消息的类别,并将其用于消息过滤。 主题可以是“/geektime/iot”。

/geektime/iot然后,您可以在电脑终端界面中输入以下命令来订阅此主题消息:

hbmqtt _ su B- -如果要了解有关运行urlmqtt ://mqtt.eclipse.org :1883-t/geek time/IOT命令的详细信息,请在上述命令中输入“-d”参数

然后,启动另一个通过hbmqtt_pub发布/geektime/iot主题消息的终端接口。

hbmqtt _ pu B--urlmqtt ://mqtt.eclipse.org :1883-t/geek time/IOT-m hello,World! 通过Eclipse的开放中介,作为“kq滴滴涕”,向我们通过hbmqtt_sub运行的订阅者发送了一条消息。 下图显示了在完成完整消息传输过程的终端接口上运行的结果。

MQTT在物联网领域的优势MQTT生态良好,便于使用MQTT,可供选择的方案很多,可以支持多种语言。 类似的mqtt中介软件还提供了基于c语言的Mosquitto、基于Erlang语言的VerneMQ等选择。

关于MQTT的客户端实现,还有成熟的Python、c、Java、JavaScript等各种编程语言的开源实现。

另外,还有很多商业公司拥有更丰富的功能,例如提供并发的集群特性、易于扩展的插件机制等,并持续支持实现更完整的业务版Broker。 这些将大大提高我们技术开发人员的工作效率。

MQTT自身的“基因”是非常强大的Alibaba云、华为云、腾讯云、微软azure等领先厂商,不约而同地将MQTT协议作为物联网设备和设备

设计上的优点主要体现在五个方面。

1. 契合物联网大部分应用场景的发布 - 订阅模式。

2 .能够满足物联网资源限制设备需求的轻量级特性。

3. 时刻关注物联网设备低功耗需求的优化设计。

4 .物联网中针对变化的网络环境提供的多种服务质量等级。

5 .在物联网APP应用中支持越来越受到重视的数据安全。

发布-订阅模式下的刚才通信过程是一个发布者和一个订阅者。 然后,可以打开另一个终端接口,重复与以前相同的命令,启动另一个订阅者。

hbmqtt _ su B--- urlmqtt ://mqtt.eclipse.org :1883-t/geek time/IOT当前,这两个订阅者都是“/geektime/IOT”主题中的

然后,如果再次使用hbmqtt_pub发送消息,则可以看到这两个订阅者收到相同的消息。 这是发布-订阅模式的典型特征。

发布-由于采用了订阅模式,MQTT协议有很多优点。

例如可以使一个传感器数据发生一系列动作;

网络不稳定导致的暂时脱机不会影响工作;

便于根据需求动态调整系统规模等。

这样可以满足大多数物品的网络场景需求。

轻量级协议:减少传输数据量的MQTT是轻量级的网络协议,也是物联网系统中普及的重要原因。 毕竟,物联网有大量计算资源有限、网络带宽低的设备。

这个“轻量级”体现在两个方面。

另一方面,MQTT消息采用二进制编码格式,而不是HTTP协议那样的文本表示形式。

这样做的优点是能够最大限度地利用字节比特,能够使协议报头紧凑,能够将需要量抑制到最小限度

要通过网络传输的数据量。
比如,分析 HTTP 的一个请求抓包,它的消息内容是下面这样的(注意:空格和回车、换行符都是消息的组成部分):

GET /account HTTP/1.1 <--注释:HTTP请求行Host: time.geekbang.com <--注释:以下为HTTP请求头部Upgrade-Insecure-Requests: 1User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:81.0) Gecko/20100101 Firefox/81.0Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8Accept-Encoding: gzip, deflate, sdchAccept-Language: zh-CN,zh;q=0.8,en;q=0.6 <--注释:这个空行是必须的,即使下面的请求体是空的

在 HTTP 协议传输的这段文本中,每个字符都要占用 1 个字节。而如果使用 MQTT 协议,一个字节就可以表示很多内容。下面的图片展示了 MQTT 的固定头的格式,这个固定头只有 2 个字节:

第一个字节分成了高 4 位(4~7)和低 4 位(0~3);低 4 位是数据包标识位,其中的每一比特位又可以表示不同的含义;高 4 位是不同数据包类型的标识位。
第二个字节表示数据包头部和消息体的字节共个数,其中最高位表示有没有第三字节存在,来和第二个字节一起表示字节共个数。
如果有第三个字节,那它的最高位表示是否有第四个字节,来和第二个字节、第三个字节一起表示字节总个数。依此类推,还可能有第四个字节、第五个字节,不过这个表示可变头部和消息体的字节个数的部分,最多也只能到第五个字节,所以可以表示的最大数据包长度有 256MB。
比如,一个请求建立连接的 CONNECT 类型数据包,头部需要 14 个字节;发布消息的 PUBLISH 类型数据包头部只有 2~4 个字节。
轻量级的另一方面,体现在消息的具体交互流程设计非常简单,所以 MQTT 的交互消息类型也非常少。为了方便后面的讲解,我在这里整理了一个表格,总结了 MQTT 不同的数据包类型的功能和发消息的流向。
从表格可以看出,MQTT 3.1.1 版本一共定义了 14 种数据包的类型,在第一个字节的高 4 位中分别对应从 1 到 14 的数值。

功耗优化:节约电量和网络资源

除了让协议足够轻量,MQTT 协议还很注重低功耗的优化设计,这主要体现在对能耗和通信次数的优化。
比如,MQTT 协议有一个 Keepalive 机制。它的作用是,在 Client 和 Broker 的连接中断时,让双方能及时发现,并重新建立 MQTT 连接,保证主题消息的可靠传输。
这个机制工作的原理是:Client 和 Broker 都基于 Keepalive 确定的时间长度,来判断一段时间内是否有消息在双方之间传输。这个 Keepalive 时间长度是在 Client 建立连接时设置的,如果超出这个时间长度,双方没有收到新的数据包,那么就判定连接断开。

除了 Keepalive 机制,MQTT 5.0 中的重复主题特性也能帮助我们节省网络资源。
Client 在重复发送一个主题的消息时,可以从第二次开始,将主题名长度设置为 0,这样 Broker 会自动按照上次的主题来处理消息。这种情况对传感器设备来说十分常见,所以这个特性在工作中很有实际意义。

3 种 QoS 级别:可靠通信
除了计算资源有限、网络带宽低,物联网设备还经常遇到网络环境不稳定的问题,尤其是在移动通信、卫星通信这样的场景下。比如共享单车,如果用户已经锁车的这个消息,不能可靠地上传到服务器,那么计费就会出现错误,结果引起用户的抱怨。这样怎么应对呢?
这个问题产生的背景就是不稳定的通信条件,所以 MQTT 协议设计了 3 种不同的 QoS (Quality of Service,服务质量)级别。你可以根据场景灵活选择,在不同环境下保证通信是可靠的。
这 3 种级别分别是:
QoS 0,表示消息最多收到一次,即消息可能丢失,但是不会重复。
QoS 1,表示消息至少收到一次,即消息保证送达,但是可能重复。
QoS 2,表示消息只会收到一次,即消息有且只有一次。

我用一张图展示了它们各自的特点。可以看到,QoS 0 和 QoS 1 的流程相对比较简单;而 QoS 2 为了保证有且只有一次的可靠传输,流程相对复杂些。
正常情况下,QoS 2 有 PUBLISH、PUBREC、PUBREL 和 PUBCOMP 4 次交互。
至于“不正常的情况”,发送方就需要重复发送消息。比如一段时间内没有收到 PUBREC 消息,就需要再次发送 PUBLISH 消息。不过要注意,这时要把消息中的 “重复”标识设置为 1,以便接收方能正确处理。同样地,如果没有收到 PUBCOMP 消息,发送方就需要再次发送 PUBREL 消息。

安全传输

说到安全传输,首先我们需要验证 Client 是否有权限接入 MQTT Broker。为了控制 Client 的接入,MQTT 提供了用户名 / 密码的机制。在建立连接过程中,它可以通过判断用户名和密码的正确性,来筛选有效连接请求。但是光靠这个机制,还不能保证网络通信过程中的数据安全。因为在明文传输的方式下,不止设备数据,甚至用户名和密码都可能被其他人从网络上截获而导致泄漏,于是其他人就可以伪装成合法的设备发送数据。
所以还需要通信加密技术的支持。
MQTT 协议支持 SSL/TLS 加密通信方式。采用 SSL/TLS 加密之后,MQTT 将转换为 MQTTS。这有点类似于 HTTP 和 HTTPS 的关系。
我们只要将前面测试的命令修改一下,将 “mqtt://” 改为 “mqtts://”,端口改为 8883,就可以用 SSL/TLS 加密通信方式连接到 Eclipse 提供的开放 Broker。
如果这个的 SSL 证书已经过期了,连接会失败。
这里再提供另一个方式,供测试使用)
输入“mqtts://test.mosquitto.org:8883”,把开放 Broker 切换到这个链接,
链接: link.
从链接中下载一个客户端证书,然后通过下面的命令订阅主题消息:

hbmqtt_sub --url mqtts://test.mosquitto.org:8883 -t /geektime/iot --ca-file ~/Downloads/mosquitto.org.crt

接着,我们再通过下面的命令测试发布消息:

hbmqtt_pub --url mqtts://test.mosquitto.org:8883 -t /geektime/iot -m Hello,World! --ca-file ~/Downloads/mosquitto.org.crt

最后在运行 hbmqtt_sub 命令的终端,就可以看到 Hello,World! 的消息:

学习笔记总结自‘物联网开发实战’–fzdxtg
–笔记只用于学习交流,请不要用于商业用途。

版权声明:该文观点仅代表作者本人。处理文章:请发送邮件至 三1五14八八95#扣扣.com 举报,一经查实,本站将立刻删除。