MQTT作为一种工具，可以在各种规模的部署中连接多种类型的 IoT 设备。它最初始于 1999 年，用于石油和天然气管道通过远程卫星进行通信。
MQTT 运行在 TCP/IP 之上，是一种在发布者-订阅者通信模型上运行的网络协议。它足够轻巧，可用于各种物联网设备，但又足够强大，可以在不稳定的网络条件下工作。
由于其提供数据的节能方法，MQTT对于 CPU 功率或 RAM 有限的低功率设备很常见。
让我们看一个案例，我们需要使用基于 Python 的客户端来组织本地MQTT v5.0网络。我们将描述沿途的挑战、问题和利弊。我们将通过将其与 MQTT v3.1.1 网络进行比较来得出结论。
我们有一栋楼，里面有几个房间，里面有一个局域网（LAN）。一个房间包含三个独立设备（例如，活动独立传感器、照片相机传感器或音频传感器）。
主机设备位于 LAN 内部，并通过无线或电缆连接到路由器。它必须在一段时间内从独立设备提供数据收集（和处理）功能，并且必须将这些数据本地存储在数据库中。
对于当前范围，可以使用 SQLLite 数据库或更简单的替代方案。只有在收到来自活动传感器的消息后，照片相机传感器和音频传感器才必须激活。
确保主机设备和独立设备之间的通信；并在主机端提供本地数据库部署和通信。
从传感器到主机设备的所有消息都必须受到 MQTT 5.0 附加属性的约束（例如，传输到主题的消息的字节大小）。
来自主题的消息必须包含 MIME 类型，以便在主机端进行编码。
消息必须存储在本地的数据库实例中。
独立设备：基于 x86 或 ARM（例如，Raspberry Pi），带有连接的传感器并可以访问本地网络。
主机设备：基于 x86 或 ARM 的（例如，Raspberry Pi）托管 MQTT 代理并处理来自独立设备的消息。
目前，我们有两个选项可以使用：paho-MQTT和gMQTT。但是，这些选项没有内置的 MQTT 5.0 代理，因此不适合本地部署网络。有一个名为 Mosquitto 的代理的非 Python 实现，它支持 MQTT 5.0。
文档可以在这里找到。每个代理最多可支持 50 000 个设备。Mosquitto 有一个“飞行队列”，可以配置大小（典型设置：1000 条消息），因此即使在高负载条件下，例如每秒数千条消息或数千个连接的客户端，也不会丢失连接或消息。
MQTT v5.0 协议的库和文档并不多，尤其是从 Python 开发人员的角度来看。当前唯一适用于 Python 的 v5.0 客户端是 gmqtt 和 paho-mqtt。
局域网内完全自主的设备交互。不需要像 GCP 或 AWS 这样的云提供商，也不需要本地物联网系统运行的 WAN 连接。
网络延迟和数据传输速度。传输速度仅取决于本地设备的硬件能力。LAN 环境中的设备部署可实现最小延迟。
与竞争对手相比，MQTT 的能源效率。
网络安全。由于本地网络未暴露于 WAN，因此本地网络外部的实体无法捕获或跟踪带有消息的数据包。MQTT v5.0 协议提供服务器对客户端和客户端对服务器的身份验证。MQTT 还可以使用 TLS 证书进行安全连接和数据传输。
数据包限制可以应用于网络内部的代理。
容器化。更简单的容器化使模拟和调试变得更加容易。
必须事先完成用于接收消息和并行工作的进程和线程管理。处理消息的线程应该被并行化和正确管理，以便您的设备正常运行。
广域网连接。开发人员必须定期调试和排除故障，并且必须首先组织主机和独立设备之间的正确连接，通常使用安全的 SSH 连接。
不支持使用 MQTT 协议进行流传输。如果您的组织需要，请查看其他协议。
MQTT 上不可用的大文件传输。考虑存储桶上传或 HTTP 协议。
经纪人无法智能地管理数据。但是，数据可以在断开连接期间存储有限的时间。
用于存储附加数据的属性
负载格式指示符（字节、UTF-8 或 UTF-8 字符串对）
请求/响应模式
客户端连接和断开的原因代码
会话过期和控制
升级后的协议版本允许简化数据负载处理和解析。它带来了对消息、连接和会话进行分离和精确控制的能力。它允许通过属性传输额外的数据，这可能会导致创建更复杂的物联网解决方案。
用于在独立设备上并行发布和侦听消息的进程/线程管理。在生产环境中需要注意。
可用的文档有限，并且包（paho-mqtt）内部类的实现过程并不明显。
由于缺乏文档，代理的安装和升级到 MQTT v5.0 很困难。
要识别网络中的设备，我们需要将 IP 发现器添加到系统中。
如果您有一个中央设备可以托管消息代理以在设备和/或主机之间进行通信，则 MQTT v5.0 是本地 IoT 设备通信的合适选项。尽管有其缺点（其中大部分在 MQTT v5.0 中已消除），但该协议可用于中小型物联网设备网络之间的通信