当前位置：首页 > news >正文

VB6 MQTT为什么在物联网应用中使用 MQTT 而不是 HTTP？

news 文章来源：https://blog.csdn.net/xiaoyao961/article/details/139332512 2025/5/10 10:41:51

有需要VBA,VB6,VB.NET等方面的MQTT的可以找我

一、MQTT简介

MQTT被广泛用于物联网(IoT:Internet of Things)领域，其中大量的设备需要进行实时通信和数据交换。它采用了一种发布/订阅(publish/subscribe)模型，其中消息的发送者（发布者）将消息发布到特定的主题（topic），而订阅者可以选择性地订阅感兴趣的主题，以接收相应的消息。

二、MQTT特点

1、轻量级

MQTT的设计非常轻量，协议头部非常小，传输的数据量很小，适用于带宽有限的网络环境，如低速、高延迟或不稳定的网络。

2、简单

MQTT的协议规范相对简单，易于实现和部署。它定义了少量的消息类型和协议操作，使得开发人员可以快速上手。

3、异步通信

MQTT使用异步通信模式，发布者发送消息后，不需要等待接收者的响应，可以继续执行其他操作。这种异步通信模式适合在资源有限的设备和网络中工作。

4、可靠性

MQTT支持三种不同的消息传递质量（QoS）级别：QoS 0（至多一次），QoS 1（至少一次）和QoS 2（只有一次）。这使得可以根据应用程序的要求选择适当的消息交付保证级别。

5、网络状况适应性

MQTT可以适应不稳定的网络状况，如网络中断、重连等。它具有断开连接后自动重连的机制，可以确保消息的可靠传输。

三、订阅和发布模型

1、Publisher(发布者)

发布者是消息的发送者，它将消息发布到特定的主题（topic）上。可以有一个或多个发布者。发布者一次只能向一个主题发送数据，发布者发布消息时也无需关心订阅者是否在线。

2、Subscriber(订阅者)

订阅者通过订阅主题接收消息,订阅者可以对消息感兴趣的实体，它选择性地订阅一个或多个主题。一旦订阅了主题，它就会接收到相应的消息。

3、MQTT Broker(MQTT代理)

MQTT代理是中间件，负责接收发布者发送的消息，并将其路由到对应的订阅者。代理也需要负责处理客户端发起的连接、断开连接、订阅、取消订阅等请求。

4、Topic(主题)

主题是 MQTT 进行消息路由的基础，它类似 URL 路径，使用斜杠 / 进行分层，比如 sensor/1/temperature。一个主题可以有多个订阅者，代理会将该主题下的消息转发给所有订阅者；一个主题也可以有多个发布者，代理将按照消息到达的顺序转发。

MQTT 还支持订阅者使用主题通配符一次订阅多个主题。

四、MQTT QoS

1、QoS介绍

很多时候，使用 MQTT 协议的设备都运行在网络受限的环境下，而只依靠底层的 TCP 传输协议，并不能完全保证消息的可靠到达。因此，MQTT 提供了 QoS（Quality of Service）机制，其核心是设计了多种消息交互机制来提供不同的服务质量，来满足用户在各种场景下对消息可靠性的要求。

MQTT（Message Queuing Telemetry Transport）协议支持三种不同的QoS级别，用于控制消息的可靠性和传输保证。

MQTT的三个QoS级别:QoS 0（至多一次），QoS 1（至少一次）和QoS 2（只有一次）。

2、QoS三个级别介绍

① QoS 0（至多一次）

在QoS 0级别下，消息以“至多一次”传输，没有确认机制。消息被发布后，发布者不会接收到关于消息是否成功传输或交付的确认。MQTT代理会尽最大努力将消息传输给订阅者，但可能会出现消息丢失或重复的情况。此级别适用于对消息传输的可靠性要求不高的场景，如传感器数据的临时更新等。

为什么 QoS 0 消息会丢失？ 当我们使用 QoS 0 传递消息时，消息的可靠性完全依赖于底层的 TCP 协议。而 TCP 只能保证在连接稳定不关闭的情况下消息的可靠到达，一旦出现连接关闭、重置，仍有可能丢失当前处于网络链路或操作系统底层缓冲区中的消息。这也是 QoS 0 消息最主要的丢失场景。

② QoS 1（至少一次）

为了保证消息到达，QoS 1 加入了应答与重传机制，发送方只有在收到接收方的 PUBACK 报文以后，才能认为消息投递成功，在此之前，发送方需要存储该 PUBLISH 报文以便下次重传。

如果发布者没有收到确认消息，它会再次发送相同的消息，直到收到确认为止。MQTT代理会确保消息至少传输一次给订阅者，但可能会出现重复传输的情况。此级别适用于对消息传输的可靠性要求较高的场景，如控制指令的传递。

QoS 1 需要在 PUBLISH 报文中设置 Packet ID，而作为响应的 PUBACK 报文，则会使用与 PUBLISH 报文相同的 Packet ID，以便发送方收到后删除正确的 PUBLISH 报文缓存。

PUBACK - 发布确认报文

① QoS 2（只有一次）

在QoS 2级别下，消息以“只有一次”传输，确保仅传输一次。发布者发送消息后，会等待MQTT代理发送两个确认消息（PUBREC和PUBCOMP）来确认消息的接收和完成。MQTT代理会确保消息仅传输一次给订阅者，没有重复传输的情况。

此级别提供了最高的消息传输可靠性，但也伴随着更高的网络开销。此级别适用于对消息传输的可靠性要求非常高的场景，如金融交易或严格的数据同步

PUBREC – 发布收到报文（QoS 2，第一步）

PUBREL – 发布释放（QoS 2，第二步）

PUBCOMP – 发布完成（QoS 2，第三步）

QoS 2 解决了 QoS 0、1 消息可能丢失或者重复的问题，但相应地，它也带来了最复杂的交互流程和最高的开销。每一次的 QoS 2 消息投递，都要求发送方与接收方进行至少两次请求/响应流程。

首先，发送方存储并发送 QoS 为 2 的 PUBLISH 报文以启动一次 QoS 2 消息的传输，然后等待接收方回复 PUBREC 报文。这一部分与 QoS 1 基本一致，只是响应报文从 PUBACK 变成了 PUBREC。

当发送方收到 PUBREC 报文，即可确认对端已经收到了 PUBLISH 报文，发送方将不再需要重传这个报文，并且也不能再重传这个报文。所以此时发送方可以删除本地存储的 PUBLISH 报文，然后发送一个 PUBREL 报文，通知对端自己准备将本次使用的 Packet ID 标记为可用了。与 PUBLISH 报文一样，我们需要确保 PUBREL 报文到达对端，所以也需要一个响应报文，并且这个 PUBREL 报文需要被存储下来以便后续重传。

当接收方收到 PUBREL 报文，也可以确认在这一次的传输流程中不会再有重传的 PUBLISH 报文到达，因此回复 PUBCOMP 报文表示自己也准备好将当前的 Packet ID 用于新的消息了。

当发送方收到 PUBCOMP 报文，这一次的 QoS 2 消息传输就算正式完成了。在这之后，发送方可以再次使用当前的 Packet ID 发送新的消息，而接收方再次收到使用这个 Packet ID 的 PUBLISH 报文时，也会将它视为一个全新的消息。

选择合适的QoS级别取决于应用程序对消息传输可靠性和网络开销的要求。更高的QoS级别提供了更可靠的传输，但同时也增加了网络开销。因此，需要根据具体场景的需求来选择适当的级别。

本篇文章转载自天翼云官方网站开发者社区，了解更多云计算知识可登录天翼云官方网站开发者社区，点击专栏查看更多技术干货，与技术大咖促膝论道！