IoT -- (八)MQTT优缺点

物联网并不仅仅是一种网络,而是一个新的生态环境,它描述的本质是越来越多的使用物品通过网络连接在一起并可使用单个或者多个的终端设备对它们进行各种控制和使用—当然,工业上的物联网通常连接到的石鼓传感器或者其他数据采集仪器以及行为单位。思科曾经预测过,物联网市场的规模可能在14万亿美金左右,前景极为光明。

众所周知,物联网是在传统互联网基础上延伸和扩展而出的概念,用户端从传统的计算机延伸和扩展到了任何物品与物品之间,而物品则通过各种传感器进行信息采集,然后通过计算设备进行网络信息交换与 通信。但是当前移动互联网正处于起步阶段,很多时候无法提供可靠的网络保障,因此,IBM主导并提出了MQTT协议,致力于解决这一方面的问题。

什么是MQTT协议?

img

MQTT是一个由IBM主导开发的物联网传输协议,它被设计用于轻量级的发布/订阅式消息传输,旨在为低带宽和不稳定的网络环境中的物联网设备提供可靠的网络服务。它的核心设计思想是开源、可靠、轻巧、简单,具有以下主要的几项特性:

\1. 非常小的通信开销(最小的消息大小为 2 字节);

\2. 支持各种流行编程语言(包括C,Java,Ruby,Python 等等)且易于使用的客户端;

\3. 支持发布 / 预定模型,简化应用程序的开发;

\4. 提供三种不同消息传递等级,让消息能按需到达目的地,适应在不稳定工作的网络传输需求

对于传统的HTTP和MQ协议,MQTT的优势在哪里呢?这有一张表格能清楚的展示这一点

img

低协议开销
MQTT 的独特之处在于,它的每消息标题可以短至 2 个字节。MQ 和 HTTP 都拥有高得多的每消息开销。对于 HTTP,为每个新请求消息重新建立 HTTP 连接会导致重大的开销。MQ 和 MQTT 所使用的永久连接显著减少了这一开销。

对不稳定网络的容忍
MQTT 和 MQ 能够从断开等故障中恢复,而且没有进一步的代码需求。但是,HTTP 无法原生地实现此目的,需要客户端重试编码,这可能增加幂等性问题。

低功耗
MQTT 是专门针对低功耗目标而设计的。HTTP 的设计没有考虑此因素,因此增加了功耗。

数百万个连接的客户端
在 HTTP 堆栈上,维护数百万个并发连接,需要做许多的工作来提供支持。尽管可以实现此支持,但大多数商业产品都为处理这一数量级的永久连接而进行了优化。IBM 提供了 IBM MessageSight,这是一个单机架装载服务器,经过测试能处理多达 100 万个通过 MQTT 并发连接的设备。相反,MQ 不是为大量并发客户端而设计的。

推送通知
您需要能够及时地将通知传递给客户。为此,必须采用某种定期轮询或推送方法;从电池、系统负载和带宽角度讲,推送是最佳解决方案。

我们的企业可能需要在没有第三方中介的情况下发送敏感的信息。这降低了特定于操作系统的解决方案(比如 Apple iOS、Google Play 通知)作为主要传输机制的价值。

HTTP 只允许使用一种称为COMET 的方法,使用持久的 HTTP 请求来执行推送。从客户端和服务器的角度讲,此方法都很昂贵。MQ 和 MQTT 都支持推送,这是它们的一个基本特性。

客户端平台差异
HTTP 和 MQTT 客户端都已在大量平台上实现。MQTT 的简单性有助于以极少的精力在额外的客户端上实现 MQTT。

防火墙容错
一些企业防火墙将出站连接限制到一些已定义的端口。这些端口通常被限制为 HTTP(80 端口)、HTTPS(443 端口)等。HTTP 显然可以在这些情况下运行。MQTT 可 封装在一个 WebSockets 连接中,显示为一个 HTTP 升级请求,从而允许在这些情况下运行。MQ 不允许采用这种模式。

事实上,MQTT的应用非常之广泛,几乎现在随便找一家大型的硬件、互联网企业,都可以找到MQTT的身影,例如Facebook、BP、alibaba、baidu等等

MQTT 协议的缺陷以及MQTT+概念的提出

由于MQTT本身的各项技术优势,越来越多的企业倾向于选用MQTT作为物联网产品通讯的标准协议,也因此,工程师们渐渐发现MQTT协议要想大规模商用,也有一些有待完善的功能。比如:

——没有齐备的SDK,不同的异构终端,需要有对应的与MQTT服务器通信的软件SDK包,比如MCU、Linux、Android、IOS、WEB等之间要实现互联互通必然需要不同的SDK包

——不支持File和AV,有些应用场景,需要传输的信息可能不仅仅限于指令,比如声音信号和视频信号,这些需要通过File和AV来实现通信。
——不支持与第三方HTTP的集成,虽然MQTT协议优于普通的HTTP协议,但是基于传统的HTTP协议的WEB服务器仍然占主流市场,那么这些服务器要实现与MQTT协议的互联互通,以降低升级成本也尤为关键。
——不支持负载均衡,为防止高并发和恶意攻击,负载均衡服务器也必不可少。
——不支持用户管理接口,用户在进行设备的行为数据分析的时候,显得尤为重要,这又是工业4.0、大数据时代的必然需求。
——不支持离线消息,弥补设备离线以后,MQTT服务器对设备的控制信息丢失的问题。
——不支持点对点通信,采用标准的MQTT协议,理论上可以通过相互订阅的方式实现点对点通信,但是逻辑相对复杂,并且对设备的安全性方面存在担忧。当设备B和设备C在同一主题的情况下,设备A无法知道是设备B还是设备C发送的消息,也有可能消息被设备D窃听。

——不支持群通信和群管理,实现了对群组成员的管理,群组成员之间能互通消息,这在一个设备被多人控制,或者多个设备被一人控制的这种场景下,尤为有用。

img

这些问题阻碍了MQTT技术在国内市场的进一步发展,毕竟对于单个的公司或者工程师而言,想要解决它们需要耗费大量的资源和时间,并且稳定性的验证也需要一个较长的时间周期。但近期,国内的一支物联网开发团队经过两年艰苦的研发和商业化验证,在MQTT协议的基础上,正式提出了一套新的解决方案,称之为ET-iLink MQTT+物联网解决方案,团队同步公布了其中的一些细节和技术指标,引起了业界的关注。

MQTT+ 连接云是什么?

ET-iLink MQTT+物联网解决方案是一套综合性的方案,下图是使用MQTT+作为设备接入协议的整体解决方案框图。

img

设备使用MQTT+客户端可以在特定的主题上发布消息,也可以通过订阅特定的主题以接收其他设备或者用户发布的消息,从而实现M2M,M2P,P2M的通信。

云网关LB Sever负责设备的接入,协议适配,消息转发等功能,如果要支持海量设备的接入,LB Sever集群是必须的。

设备管理负责设备接入认证,设备与用户绑定,操作授权等相关的功能。

账号管理负责用户账号安全认证,授权认证等相关的功能,同时也支持第三方账号安全认证。

云服务负责设备业务逻辑。不同的设备厂商都有一套自己的业务逻辑和服务,这种服务可以和容易的运行在云端提供的容器中,使用基于容器的微服务使得应用程序能够更快地进行创建,并且更易于维护,同时又能够得到更高的质量。而数据的存储和分析使用云平台提供的通用的存储服务和大数据分析引擎。

用户只要注册账号,绑定设备,就可以通过 手机APP,微信或者web等终端轻松查看设备信息,与设备进行交互操作。

img

此解决方案具有的优势有:

·移动设备

能在 8bit 位处理器上很好的运行 C /JavaScript/Java 的 client 库分别只有 30/75/100KB

在移动设备上耗电率低,大约只需要 HTTP 的一半

·很好的适应各种复杂网络,特别是受限网络

预期并适应频繁的网络中断,能应对低速、低质量的网络

压缩优化过后的协议,可以有效降低网络流量,从而节约网络成本

完成同样的数据通信,MQTT只需要 HTTP 约 1/4 得数据流量

·发布 - 订阅的消息通信协议,允许一条消息只发布一次,便可被多个消费端(应用程序 / 设备)所接收

·能够实现设备与设备之间的点对点的双向通信。

·对HTTP接口的兼容,能实现系统间松耦合,简化开发,方便扩展,整合。

·提供灵活便捷的系统整合能力

使用微服务+docker的方式,快速部署高效运行云端服务

提供可靠的设备管理和账号管理体系,您只需要关注核心业务

提供通用的数据存储和数据分析服务

提供与第三方云平台的对接功能

提供协议适配功能,客户端可以使用多种通信协议与设备进行通信。

·提供丰富的安全性

使用 SSL 提供的认证和加密来保证传输安全性

采用账号安全认证+设备安全认证结合的方式保证内容安全

·强大的性能提高系统的高可靠性

高连接数下系统低计算资源使用

高连接数下系统高信息处理速度

·提供多种消息服务质量,满足不同场景需求

0 :消息最多被传递一次,比如一般类广告,通知

1 :消息会被传递但可能会重复传递,比如账户余额通知

2 :消息保证传递且仅有一次传递,比如交易支付批复通知

硬件+软件+私有云平台开发套件/免费的公有云平台支持

小e MQTT系列全功能 开发板是为了帮助工程师们快速实现物联网项目的开发而提供一款配套开发板。考虑到实际的项目应用环境,它有两个不同的版本:

img

小e1Wi-Fi全功能开发板采用ESP8266 WiFi SOC 芯片,采用Free RTOS实时操作系统,主频可达160MHZ。支持标准的 IEEE802.11 b/g/n 协议,完整的 TCP/IP 协议栈,具有丰富的硬件接口,并配备OLED屏,温湿度传感器,大气压传感器,RGB,IR等,利用微信进行远程控制与语音互动,代码开源。

img

小e2 2G透明串口开发板,是利用SIM卡和运营商的GPRS网络提供无线数据传输功能的开发板,通过此开发板的2G模块,可以提供各种设备(PC、手机、服务器)到模块间的透明的数据交互

<think>嗯,用户之前问过关于pthread库栈资源分配的问题,现在又问MQTT协议的优缺点。看起来他们可能在进行某种项目开发,涉及多线程和网络通信。需要先确定用户的使用场景,比如是物联网设备、移动应用还是服务器后端? MQTT优缺点,首先得回顾一下协议的基本特性。MQTT是轻量级的发布/订阅消息协议,适合低带宽、高延迟或不可靠的网络环境。优点可能包括低功耗、适合不稳定网络、支持大量设备连接。缺点可能有安全性需要额外配置、不适合高吞吐量场景、服务端实现可能复杂。 用户可能是开发者,需要选择适合的通信协议,可能在物联网项目中应用。他们可能关心如何权衡不同协议的优缺点,或者是否有替代方案。之前的线程问题可能是在处理设备端的并发,而MQTT用于设备与服务器之间的通信。 用户可能没有明确说出来的需求是,他们可能正在设计一个分布式系统,需要处理大量设备的数据传输,同时考虑资源消耗和可靠性。需要确认他们是否了解MQTT的安全机制,比如TLS加密,以及是否有QoS的需求。此外,是否有其他协议如HTTP/2、CoAP等也在他们的考虑范围内? 在回答时,应该结构清晰,先优点后缺点,每个点简明扼要。同时可能需要对比其他协议,但用户没有明确要求,所以点到为止即可。确保用户理解MQTT适合的场景,以及潜在的限制,比如消息大小限制或需要中间代理的存在。</think>以下是关于 **MQTT(Message Queuing Telemetry Transport)协议**的优缺点分析,结合其设计目标与典型应用场景: --- ### **一、MQTT 的核心优势** 1. **轻量高效** - **协议开销极小**:消息头最小仅 **2字节**,适合带宽受限的物联网IoT)设备或移动网络。 - **低功耗**:适用于电池供电设备(如传感器),减少通信能耗。 2. **适应弱网络环境** - 基于 **TCP/IP** 但优化了断线重连机制,支持 **自动重连** 和 **消息缓存**(通过 `Clean Session` 和 QoS 配置)。 3. **灵活的消息路由(发布/订阅模型)** - **解耦生产者和消费者**:客户端无需直接通信,通过主题(`Topic`)路由消息(如 `sensors/temperature/room1`)。 - 支持 **通配符订阅**(`+` 单层匹配,`#` 多层匹配),简化设备群组管理。 4. **多等级服务质量(QoS)** - **QoS 0**(最多一次):尽力交付,无重传。 - **QoS 1**(至少一次):确保送达,但可能重复。 - **QoS 2**(恰好一次):严格保证消息唯一性(需更高开销)。 5. **安全性扩展性** - 支持 **TLS/SSL 加密** 和 **客户端认证**(如证书、用户名/密码),适应安全敏感场景。 - 可扩展的 **遗嘱消息(Will Message)**:设备异常离线时自动通知其他客户端。 --- ### **二、MQTT 的局限性** 1. **依赖中间代理(Broker)** - 必须部署 MQTT Broker(如 Mosquitto、EMQX),单点故障可能影响全局,需通过集群解决。 2. **实时性受限** - 基于 TCP 的协议在极端高延迟或抖动网络中可能表现不如 UDP 协议(如某些场景下 CoAP 更优)。 3. **消息大小限制** - 协议规范未明确限制消息体大小,但实际受限于 Broker 和网络 MTU(通常建议小于 **256KB**)。 4. **协议复杂性** - QoS 2 的实现需要多次握手,增加延迟和计算开销,可能抵消轻量化的优势。 5. **无原生二进制数据支持** - 需通过自定义编码(如 JSON、Protobuf)传输二进制数据,增加解析成本(相比之下,CoAP 直接支持二进制)。 --- ### **三、典型应用场景** 1. **物联网IoT)** - 传感器数据上报(如温度、湿度)、设备远程控制(如智能家居)。 2. **移动应用** - 即时通讯、推送通知(如 Facebook Messenger 早期使用 MQTT)。 3. **车联网(V2X)** - 车辆状态监控、远程诊断。 4. **工业互联网(IIoT)** - 设备状态监控、边缘计算节点通信。 --- ### **四、与其他协议的对比** | 协议 | 适用场景 | 关键差异 | |---------|----------------------------|-----------------------------| | **HTTP** | 请求-响应模型,RESTful API | 高开销,无持久连接,不适合实时流。 | | **CoAP** | 受限设备(如 6LoWPAN) | 基于 UDP,支持多播,内置资源发现。 | | **AMQP** | 企业级消息队列(如金融交易) | 更复杂,支持事务、高级路由。 | --- ### **五、总结建议** - **优先选择 MQTT**:若需低功耗、弱网络适应性和发布/订阅模型(如 IoT 设备群)。 - **谨慎使用**:在需要极低延迟(如工业控制)或直接端到端通信的场景,可考虑其他协议(如 WebSocket + 自定义协议)。 - **安全必选项**:始终启用 TLS 加密和客户端认证,避免裸协议暴露在公网。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

Archie_java

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值