技术

|

08 Jan 2022

MQTT – 2020 年版初学者指南

在 IoT(物联网)环境中开始使用 MQTT 和 MQTT-SN。
Beginner's guide to MQTT

在 A 与 B 之间来回传输数据的方法有上百万种,但是实现可靠传输并非总是小菜一碟。物联网设备和应用(也称为“Things”)需要使用可靠、稳健且安全的消息传输协议。这就是消息传输协议 MQTT 的来历。

本文将为您提供您需要了解的专业知识,以便您能够在 IoT(物联网)环境中开始使用 MQTT 和 MQTT-SN。

本文涉及的主题:

MQTT 是什么?

用最简单的术语来说,MQTT 是一种消息传输协议,旨在为机器对机器 (m2m) 通信设立可靠的标准。该协议由 IBM 的 Andy Stanford Clark 和 Eurotech 的 Arlen Nipper 于 1999 年创建。

MQTT 是一种发布和订阅协议,这意味着无需与服务器进行通信,而由客户端设备和应用发布和订阅主题,该主题由代理进行处理。

MQTT 通常使用 IP(互联网协议)作为其传输协议,但也可以使用其他双向传输协议。

若要了解 MQTT 的历史,请访问 mqtt.org

What is MQTT? MQTT explained

MQTT-SN 是什么?

MQTT-SN(用于传感器网络的 MQTT)是 MQTT 的一种变体,顾名思义,该协议已针对在传感器网络等低功耗环境中使用进行了优化。

在标准功能集的基础上,SN 为需要低功耗的用例添加了额外的功能。此类额外功能包括:

  • QoS 模式 -1:实现即发即弃的消息传输
  • 主题别名:简化发布并减少数据开销
  • 休眠模式(断开连接的会话):当远程 Thing 或设备关闭电源时,允许消息在代理上排队

立即开始使用 u-blox Thingstream

为什么 MQTT 非常适合物联网

归根结底,物联网 (IoT) 仅有一项作用:在网络中的设备之间来回传输数据。问题在于此类网络可能位于世界上的任何地方,并且每个网络都面临着许多可能并且将会导致其发生故障的状况。MQTT 及其扩展而来的 MQTT-SN 具有许多内置功能,可帮助缓解其中的某些问题。下面列出了一些主要功能:

1.MQTT 简单易用

MQTT 的入门和使用既快速又简便。有数百万个现成的客户端应用可用,同时还有几乎一样多的代理。利用 u-blox Thingstream 平台内置的代理,您可以立即开始使用 MQTT

2.MQTT 的可靠性

许多物联网设备都依靠无线电连接来传输和收集数据,这意味着连接并非总是可靠的。MQTT 允许将消息存储在代理中,直到设备准备好接收该消息为止。借助 QoS(服务质量),MQTT 能够对消息进行排队,确保其能够到达目的地,如果需要,则确保该消息仅到达一次。

3.双向消息传输

说 MQTT 是全向的,也许更准确。任何设备、“Thing”或应用都可以发布或订阅由代理处理的任何主题。这意味着在网络上可以发布或订阅的内容没有限制。

4.大规模消息传输

借助 MQTT,将消息广播到一百万个设备就像发送到一百个设备一样容易。要想被网络上的其他“Thing”听到,某个“Thing”只需要发布到其他设备都已订阅的主题即可。

MQTT 的优点是什么?

Advantages of MQTT messaging protocol

MQTT 客户端和代理

请勿将 MQTT 理解为由“客户端和服务器”构成,因为 MQTT 由“客户端和代理”构成。在传统的客户端/服务器关系中,客户端与服务器相连,并且服务器作为数据的存储和分发库。对于 MQTT,该过程有所不同。代理更为被动,其行为更像是路标,为数据指示目的地。

MQTT 客户端

实际上,运行 MQTT 库并通过网络连接到代理的任何“Thing”(从微控制器到大型服务器)都可以成为 MQTT 客户端。

客户端彼此之间不会直接发送消息,而是与代理管理的主题进行沟通。此类主题的工作原理类似于电子邮件收件箱。某个“Thing”将消息发布到某个主题;如果其他“Thing”订阅了该主题,则就会拾取该消息。

MQTT 代理

代理处理网络上的“Thing”的身份验证,并且管理连接、会话和订阅。其主要职责是接收各类已发布的消息,然后将消息发送给订阅的客户端。代理还为订阅的客户端对消息进行排队,并根据约定的 QoS 级别传输消息。

u-blox carrier-grade MQTT broker

MQTT 主题

MQTT 消息不会在“Thing”之间直接传输。相反,各个“Thing”将消息发布至“主题”。然后,代理会将相关消息发送至任何订阅的客户端。

MQTT 主题剖析

  • 主题由一个或多个主题级别组成,各个级别由斜杠分隔:

MQTT topic architecture

  • 主题是按案例区分的
  • 主题不必在代理处预先注册。

MQTT-SN 主题功能

MQTT-SN 添加了一些特殊的主题功能来帮助带宽受限的环境:

  • 如果使用预定义的主题,您可以在代理上创建主题别名,然后客户端就可以使用该别名,而无需提前注册。此功能可以减少计费消息的数量。
  • 长主题名称不会在任何方向上无线发送。此功能可以节省带宽,并且不需要将长主题名称存储在内存中。
  • 如果未使用预定义的主题,则“Thing”将使用 REGISTER 命令利用服务器注册主题名称。服务器将使用包含由 2 个字符组成的主题 ID 的 REGACK 进行响应。请注意,每次客户端连接时,您都需要注册主题。

为何要使用 MQTT 主题?

主题是组织流经网络的数据的一种好方法,并且随着规模的增长,这一点会变得更加明显。举例来说,如果您的设备在多个站点上部署了多个传感器,则可以将各类数据放在一个有效负载中,并在数据到达目的地时对其进行解析,或者可以使用 MQTT 方式并使用主题来划分数据,如下所示:

  • site1/position(站点 1/位置)
  • site1/temp(站点 1/温度)
  • site1/vibration(站点 1/振动)
  • site2/position(站点 2/位置)
  • site2/temp(站点 2/温度)
  • site2/vibration(站点 2/振动)

当按主题划分传输的数据时,“Things”可以订阅其感兴趣的主题。如果某个设备对多个主题感兴趣,则可以分别订阅或使用通配符订阅。举例来说,若要获得站点 1 的全部数据,您需要使用通配符,即“site1/#(站点 1/#)”。您也可以使用通配符(即“+/temp(+/温度)”)来获得全部站点的各类“temp(温度)”。

连接

连接始终建立在客户端和代理之间。客户端无法直接相互连接。

建立连接的方式如下:客户端发送一条 CONNECT 消息,然后代理发送一条 CONNACK(连接已确认)消息进行响应。客户端需要建立连接才能发布具有服务质量 (QoS) 级别 0、1 或 2 的主题或订阅任何主题。客户端通常使用客户端 ID (ClientID)、用户名和密码连接到代理。在任何给定时间,客户端仅能与同一代理建立一个连接。

清理会话

利用“clean session(清理会话)”设置,您可以开始新的会话,同时清除队列中的消息。

  • false(假):代理为客户端存储全部订阅,当 QoS 级别为 1 或 2 时,代理将会对已发布的某个订阅的全部消息进行排队
  • true(真):当客户端连接时,代理会清除队列中的全部消息。

保持激活

“keep alive(保持激活)”设置定义了在代理或客户端不发送消息的情况下,连接可以保持不变的最长时间。此设置允许由电池供电的设备进入休眠状态,在此状态下,发给该设备的全部消息都会缓存在服务器/网关处,并在其醒来后再传递给该设备。

为了让连接保持不变,客户端会在“keep alive(保持激活)”窗口到期之前发送 PINGREQ 消息,代理会以 PINGRESP 消息作为响应。如果在“keep alive(保持激活)”窗口中看不到该设备,则代理可以选择断开会话的连接,然后停止向该设备发送消息,直到下一个会话为止。

休眠(仅限 MQTT-SN)

通过发送 DURATION 值大于 0 的 DISCONNECT 消息,MQTT-SN 客户端可以告诉代理自己要休眠一段时间。在指定时间段内,代理将保持该状态。在休眠状态下,代理将会对订阅的全部消息进行排队(Qos 0、QoS 1 或 QoS 2)。该设置与“clean session(清理会话)”设为“false(假)”时的断开连接不同,后者仅保留 QoS 1 和 QoS 2 消息。

在休眠时,客户端可以通过发出 PINGREQ 消息来刷新队列而无需醒来。然后,如果有消息要传输,则代理将以 PUBLISH 消息进行响应。完成刷新后,代理将以 PINGRESP 消息进行响应,从而让设备重新进入休眠状态。

订阅

MQTT 客户端彼此之间并不直接连接,而是订阅主题以接收消息。

要订阅主题,客户端必须首先将 SUBSCRIBE 请求发送给代理。SUBSCRIBE 请求可以包含多个主题。代理将使用 SUBACK(已确认订阅)消息响应 SUBSCRIBE 请求。订阅还具有用于降低已发布消息的 QoS 级别的 QoS 设置。在此情况下,该消息将始终以较低的 QoS 设置发布。

订阅通配符

订阅可以使用以下所示的两种通配符之一。

单级 (+)

单级通配符用于替换一个主题级别。如下图所示。

MQTT subscription wildcards topic

该通配符将涵盖以下主题:

  • sensors/soil/out(传感器/土壤/输出)
  • sensors/water/out(传感器/水/输出)
  • sensors/light/out(传感器/光/输出)

多级 (#)

多级通配符用于替换多个主题级别:

Wildcard MQTT subscription topic

该通配符将涵盖以下主题:

  • sensors/soil/out(传感器/土壤/输出)
  • sensors/soil/in(传感器/土壤/输入)
  • sensors/temperature/out(传感器/温度/输出)

MQTT QoS 说明

在涉及 MQTT 协议时,传输的保证由 QoS(服务质量)定义。

在此处,您将了解到,应该如何以及在何时何地使用 MQTT QoS,以及哪些级别适合您自己的物联网应用。

MQTT QoS 级别

MQTT 和 MQTT-SN 支持多个级别的 QoS,以确保消息传输。

QoS -1 – 即发即弃

QoS -1(负一)是低功耗非关键应用的理想之选,在此类应用中,每条消息是否到达目的地都无关紧要。通过不与代理建立硬连接并且不接收任何确认,此级别将大幅减少完成处理所用的电量。

MQTT-SN QoS level -1

QoS -1 主要特性:

  • 仅适用于使用 MQTT-SN 的设备
  • 无需建立 MQTT 连接
  • 无接收者的确认
  • 发送者无法重试
  • 到达代理的用时类似于 QoS 0

何时使用 QoS -1:

  • 功率受限“Things”的理想之选,旨在最大程度缩短无线传输时间
  • 最大程度降低消息传输成本
  • 适用于频繁发送的数据等非关键消息的传输

QoS 0 – 至多一次

QoS 0(零)用于确保消息到达其目的地的次数不超过一次。与 QoS -1 不同,此级别需要建立 MQTT 连接,也就意味其在功耗方面的效率较低。

MQTT QoS level 0

QoS 0 主要特性:

  • 尽力实现消息传输
  • 无接收者的确认
  • 发送者无法重试
  • 对于订阅了某个主题且已断开连接的客户端,代理不会对消息进行排队

何时使用 QoS 0:

  • 适用于功率受限“Things”,旨在最大程度缩短无线传输时间
  • 最大程度降低消息传输成本
  • 适用于频繁发送的数据等非关键消息的传输
  • 效率不如 MQTT-SN QoS -1,因为需要建立 MQTT 连接

QoS 1 – 至少一次

QoS 1 适用于消息传输非常重要的场景。若要实现此服务级别,需要对消息进行排队,直到订阅者可以接收到为止。

MQTT QoS level 1

QoS 1 主要特性:

  • 确保至少将消息传输给接收者一次。
  • 发送者存储消息,直到收到接收者的 PUBACK 消息
  • 消息可能会收发多次。

何时使用 QoS 1:

  • 在必须接收每条消息时使用,但要确保处理重复项
  • 希望消息在代理处排队以传输到离线客户端时使用
  • 当 QoS 2 的开销过高时使用

QoS 2 – 只有一次

QoS 2 适用于消息需要到达一次且仅一次的场景。此级别适用于必须传输消息的场景。

MQTT QoS level 2

  • QoS 2 是最安全、最慢的服务质量级别
  • 对于每个消息,通过在发送者与接收者之间使用至少两个请求/响应流(四次握手),确保目标接收者仅接收一次。

何时使用 QoS 2:

  • 适用于消息传输至关重要并且重复数据对订阅者有害的场景

QoS 降级

如果网络上有许多设备,则可能需要使用不同级别的 QoS。为此,MQTT 允许在订阅者节点处降低 QoS 级别。此操作的结果就是,发布的消息的 QoS 可能与接收的消息的 QoS 不同。

MQTT QoS downgrade

QoS 由原始发布者定义,但是当代理将消息传递给订阅者时,将使用 PUBLISH QoS 与在 SUBSCRIBE 期间定义的 QoS 之中的较低者。

安全 – MQTT 安全吗?

确保物联网设备的安全与确保其正常工作且网络上的每个链接或节点都是潜在的利用媒介一样重要。虽然 MQTT 本身确实包含一些安全机制,但重要的是要考虑与传输本身无关的因素。

网络层安全

首先要考虑网络本身的安全。确保使用 VPN 隧道保护网络连接,从而防止其暴露于网络流量。

传输层安全

与 HTTP 通信一样,可以使用 TLS/SSL 在传输层保护 MQTT 通信。

应用层安全

该协议本身提供了唯一的客户端标识和用户名/密码凭据,应将其视为最低安全要求。

有效负载加密

通过在应用层加密有效负载本身可进一步提高安全性。

U-blox Thingstream MQTT 安全

u-blox Thingstream 服务交付平台通过不公开设备的 IP 地址,在上述功能之上增加了一层额外的安全保护。由于没有与互联网的物理连接,因此设备更难被黑客利用。

立即开始使用 u-blox Thingstream

额外资源

Make your IoT devices fly with MQTT

What is MQTT? MQTT explained

  • MQTT (message queuing telemetry transport) is a messaging protocol that was designed to create a reliable standard for machine-to-machine (m2m) communication.
  • MQTT is a publish-and-subscribe protocol, meaning that instead of communicating with a server, client devices and applications publish and subscribe to topics handled by a broker.
  • MQTT typically uses TCP/IP (Transmission Control Protocol/Internet Protocol) as its transport but can also use other bi-directional transports.
  • MQTT has become the de facto standard for loT communication because of its efficiency and flexibility. u-blox uses this to overlay various radio networks (2G-4G cellular and LoRa) and protocols (USSD, UDP) providing developers with a familiar and simple experience.
  • MQTT allows devices and systems (clients) to communicate by sending messages. Messages are not sent directly from client to client but are published by a client to a topic* stored in an MQTT broker.
  • Clients receive messages by subscribing to one or more topics and will receive messages from that point forwards.
  • Topics are like street addresses - they form a tree which becomes more specific the further down you travel.
  • Messages can be published with different Quality of Service levels which define reliability and whether receipts are generated for delivery.
  • MQTT was created by Andy Stanford Clark and Arlen Nipper in 1999.

Useful links:

MQTT specification

MQTT is an OASIS standard. The specification is managed by the OASIS MQTT Technical Committee. For more information on the standard and specification, please see the links below:

 

What is MQTT? MQTT explained

What is MQTT-SN?

MQTT-SN (MQTT for sensor networks) is a variant of that has been optimized for use in low power environments such as sensor networks, as the name suggests.

On top of the standard feature set, SN adds extra functionality for use cases where lower power is required. These extra features include:

  • QoS mode -1: allows for fire-and-forget messaging
  • Topic aliases: allows for simplified publishing and reduced data overheads
  • Sleep mode (disconnected sessions): allows messages to be queued on the broker while the remote Thing or device is powered off

Why MQTT is perfect for IoT

When you boil it down, the Internet of Things (IoT) has one job: to get data to and from devices on a network. The problem is that these networks could be anywhere in the world and each faces many conditions that can and will cause them to fail. MQTT, and by extension MQTT-SN, has myriad features built in to help mitigate some of these issues. Some of the main features are listed below:

1. It's easy

Getting up and running with MQTT is quick and easy. There are millions of ready-made client applications and almost as many brokers available. You can get started with MQTT right now by using the broker integral to the u-blox Thingstream platform.

2. It's reliable

Many IoT devices rely on a radio connection to transmit and collected data, meaning connectivity isn’t always reliable. MQTT can allow for messages to be stored at the broker until a device is ready to receive it. Thanks to QoS (Quality of Service), MQTT has the ability to queue messages, make sure they get where they are going and if required, ensure that they only get there once.

3. Bidirectional messaging

It is perhaps more accurate to say that MQTT is omnidirectional. Any device, Thing, or application can publish or subscribe to any topic handled by the broker. This means there is no limit on what can talk or listen to what across the network.

4. Messaging at scale

it is just as easy to broadcast a message to a million devices as it is to send to just a hundred. To be heard by everything on the network, a Thing simply needs to publish to a topic to which all devices are subscribed.

Check out our white paper to find out how u-blox MQTT-based services can help you solve the complexity of communicating between IoT devices and the enterprise

What are the advantages of MQTT?

  • Simplified communication
    Communication is a complex problem. MQTT reduces complexity, allowing a single connection to a message topic. Data is logically structured and can be processed flexibly.
  • Eliminate polling
    Instantaneous, push-based delivery, eliminates the need for message consumers to periodically check or "poll" for new information. This drastically reduces network traffic.
  • Dynamic targeting
    MQTT makes discovery of services easier and less error prone. Instead of maintaining a roster of peers that an application can send messages to, a publisher will simply post a message to a topic.
  • Decouple and scale
    MQTT also makes solutions more flexible and enables scale. It allows changes in communication patterns, adding or changing functionality without sending ripple effects across the system.
Advantages of MQTT messaging protocol

MQTT client and broker

Don’t think, “client and server”, think, “client and broker” instead. In a traditional client/server relationship, the client and the server connect, and the server is treated as a storage and distribution depot for the data. With MQTT, the process is different. The broker is much more passive, acting more like a signpost for where the data should go.

MQTT client

Any Thing (from a microcontroller to a massive server) that runs an MQTT library and connects to a broker over a network can effectively become a client. 

Clients don’t send messages directly to and from each other but instead communicate to topics managed by the broker. These topics work a little like email inboxes. Messages are published by Things to topics; messages are then picked up when a Thing subscribes to those topics.

MQTT broker

The broker handles authentication of Things on the network as well as managing connections, sessions, and subscriptions. Its main responsibility is to receive all published messages and then send them subscribed clients. The broker also queues messages for subscribed clients, delivering them according to the agreed QoS level.

 

u-blox carrier-grade MQTT broker

MQTT devices and applications

In an MQTT network, devices and applications are usually known as “things”. The reason for this is that there is no difference between the two as far as the broker is concerned. To that end, both devices and applications can publish and subscribe to topics managed by the broker.

Devices

There are various types of MQTT-enabled devices in the field today, ranging from simple Arduino-based devices to devices for mission-critical commercial, industrial, and medical applications. Many smart homes and businesses are also built around interconnected MQTT devices.

Instant IoT

XPLR-IOT-1-Digikey

For businesses looking to launch digital transformation or IoT trials, u-blox has developed the XPLR-IOT-1.

The XPLR-IOT-1 comes with MQTT Anywhere connectivity baked-in, meaning it can operate in over 190 countries straight out of the box.

Along with access to the u-blox IoT Communication-as-a-Service suite, the XPLR-IOT-1 also contains u-blox GNSS and short range devices, an array of sensors, and easy access to u-blox IoT Location-as-a-Service services.

MQTT Anywhere

 

MQTT topics

Messages aren’t delivered directly from Thing to Thing. Instead, they are published to "topics". The broker then delivers those messages to any subscribed clients.

Anatomy of an MQTT topic

  • Topics are made up of one or more topic levels, separated by a forward slash:

 

MQTT topic architecture
  • Topics are case sensitive
  • Topics don’t have to be pre-registered at the broker.

MQTT-SN topic features

MQTT-SN adds some special topic features to assist in a bandwidth-constrained environment:

  • If using predefined topics, you can create a topic alias on the broker which the client can then use without the need to register first. This can reduce the number of billable messages.
  • The long topic name does not have to be sent over the air in either direction. This saves bandwidth, and there is no need to store the long topic name in memory.
  • If not using predefined topics, Things use the REGISTER command to register a topic name with the server. The server will respond with a REGACK containing a topic ID consisting of 2 characters. Note that you would need to register the topic each time the client connects.

Why use topics?

Topics are a great way to organize data as it flows through the network and this becomes more apparent with scale. For example, if you have devices with several sensors deployed across multiple sites, you could put all of the data in one payload and parse it when it gets to its destination or you could do it the MQTT way and use topics to divide up the data, as shown below:

  • site1/position
  • site1/temp
  • site1/vibration
  • site2/position
  • site2/temp
  • site2/vibration

When the data transmitted is divided by topic, Things can then subscribe to the topics they are interested in. If a device is interested in multiple topics, they can be subscribed to individually or wildcards can be used. For example, to get all the data from site1, you would use the wildcard, “site1/#”. You could also get all “temp” data from all sites by using the wildcard, “+/temp”.

Connections

Connections are always made between a client and a broker. Clients cannot connect directly to each other.

The connection is established by the client sending a CONNECT message, to which the broker responds with a CONNACK (connection acknowledged). A connection is required in order to publish with a Quality of Service (QoS) level 0, 1, or 2 or to subscribe to any topics. Clients usually connect to a broker using a Client ID (ClientID), username, and password. A client may only have one connection with the same broker at any given time.

Clean session

The “clean session” setting gives you the ability to start fresh with no messages in the queue.

  • false: The broker stores all subscriptions for the client and will queue any messages for that subscription that were published with a QoS level 1 or 2
  • true: The broker purges all queued messages when the client connects.

Keep alive

The “keep alive” setting defines the longest period of time that the connection can remain in place without the broker or client sending a message.

Note that while a client is in a connected state, the broker will immediately deliver any messages published to topics that the client is subscribed to. For this reason, especially where connectivity is volatile e.g. in mobile communications, the keep alive should be kept to a minimum to prevent possible data loss.

Sleep (SN only)

An MQTT-SN client can tell the broker it is going to sleep for a period of time by sending a DISCONNECT with a DURATION greater than 0.

While a client is in a sleep state, the broker will queue all messages published to topics that the client is subscribed to regardless of the QoS used for the publish.

From the sleep state, the client can flush the queue by issuing a PINGREQ. The broker will then respond with a PUBLISH if there are messages to deliver, and a PINGRESP when the flush is complete, putting the device back to sleep.

Subscriptions

Clients don’t connect directly to each other, instead, they subscribe to topics to receive messages.

To subscribe to a topic, the client must first send a SUBSCRIBE request to the broker. The  SUBSCRIBE request can include multiple topics. The broker responds to the SUBSCRIBE request with a SUBACK (subscription acknowledged) response. Subscriptions also have a QoS setting which can be used to downgrade the QoS of the published message. In this case, the message is always published at the lower QoS setting.

Subscription wildcards

Subscriptions can use one of two types of wildcard shown below.

Single-level (+)

A single-level wildcard replaces one topic level. As shown in the image below.

 

MQTT subscription wildcards topic

This wildcard would cover the following topics:

  • sensors/soil/out
  • sensors/water/out
  • sensors/light/out

Multi-level (#)

A multi-level wildcard replaces multiple topic levels:

 

Wildcard MQTT subscription topic

This wildcard would cover the following topics:

  • sensors/soil/out
  • sensors/soil/in
  • sensors/temperature/out

MQTT QoS explained

Guarantee of delivery is defined by QoS (Quality of Service).

Here, you will learn how, where, and when to use QoS, and which levels are right for your own IoT applications.

QoS levels

MQTT and MQTT-SN support multiple levels of QoS for guaranteeing message delivery.

QoS -1 – fire and forget

QoS -1 (minus one) is ideal for low-power non-critical applications where it doesn’t matter if every message gets to where it’s going. By not making a hard connection with the broker and receiving no acknowledgment, considerably less power is used to complete the transaction.

 

MQTT-SN QoS level -1

QoS -1 key features:

  • Only available for devices using MQTT-SN
  • Does not require an MQTT connection to be established
  • No acknowledgment from the recipient
  • Not retried by the sender
  • Analogous to QoS 0 by the time it reaches the broker

When to use QoS -1:

  • Ideal for power-constrained Things to minimize time on air
  • Minimize messaging cost
  • OK if message delivery is not critical e.g. data sent frequently

QoS 0 – at most once

QoS 0 (zero) is used to ensure that a message reaches its destination no more than once. Unlike QoS -1, this method requires an MQTT connection meaning it is less efficient in terms of power.

 

MQTT QoS level 0

QoS 0 key features:

  • Best effort message delivery
  • No acknowledgment from the recipient
  • Not retried by the sender
  • Not queued by the broker for disconnected clients with a valid subscription to the topic

When to use QoS 0:

  • Good for power-constrained Things to minimize time on air
  • Minimize messaging cost
  • OK if message delivery is not critical e.g. data sent frequently
  • Not as efficient as MQTT-SN QoS -1 due to the requirement of CONNECT

QoS 1 – at least once

QoS 1 is used when message delivery is critical. This is achieved by queueing messages until the subscriber is able to receive it.

 

MQTT QoS level 1

QoS 1 key features:

  • Guarantees that a message is delivered at least one time to the recipient. 
  • Sender stores the message until it receives a PUBACK from the recipient
  • Messages may be sent or delivered multiple times.

When to use QoS 1:

  • Use when you have to receive every message, but make sure you handle duplicates
  • Use if you want messages to be queued on the broker for delivery to offline Clients
  • Use when the overhead of QoS 2 is too high

QoS 2 – exactly once

QoS 2 is used when the message needs to arrive once and only once. This level is used when delivery is essential.

 

MQTT QoS level 2
  • QoS 2 is the safest and slowest Quality of Service level
  • Guarantees that each message is received only once by the intended recipients by using at least two request/response flows (a four-part handshake) between the sender and the receiver.

When to use QoS 2:

  • Use if message delivery is critical and duplicate data is harmful to subscribers

QoS downgrade

In cases where there are many devices on the network, different levels of QoS might be needed. To achieve this, MQTT allows downgrading of the QoS level at the subscriber node. The result of this is that the QoS for a message that is published does not have to be the same as the QoS for a message that is received.

 

MQTT QoS downgrade

QoS is defined by the original publisher, but when the broker then delivers the message on to subscribers, the lower of the PUBLISH QoS and the QoS defined during the SUBSCRIBE is used.

Security – is MQTT secure?

Making sure IoT devices are secure is just as important as making sure that they work and every link or node on the network is a potential exploit vector. While the protocol itself does contain some security mechanisms, it’s important to consider factors extraneous to the transport itself.

Network-level security

The first place to consider security is the network itself. Ensuring that the network connection is secured by using a VPN tunnel will prevent exposure to network traffic.

Transport-level security

As with HTTP traffic, MQTT traffic can be secured at the transport layer with TLS/SSL.

Application-level security

Unique client identification and username/password credentials are provided by the protocol itself and should be considered the bare minimum security requirement.

Payload encryption

Further security can be added by encrypting the payload itself at the application level.

U-blox Thingstream MQTT security

The u-blox Thingstream service delivery platform adds an extra layer of security on top of those mentioned above by not exposing the IP address of the device. By having no physical connection to the Internet, this makes devices much harder to exploit.

MQTT v5.0 and future evolution

In 2019, standards body, OASIS released the official MQTT 5.0 standard.

New features added to the Version 5.0 standard:

  • Reason codes: Acknowledgements now support return codes, which provide a reason for failure.
  • Shared subscriptions: Allow the load to be balanced across clients and thus reduce the risk of load problems
  • Message expiry: Messages can include an expiry date and are deleted if they are not delivered within this time period.
  • Topic alias: The name of a topic can be replaced with a single number

u-blox MQTT IoT services

  • MQTT Anywhere - IoT Communication-as-a-Service SIM-based LPWA
  • MQTT Flex - MQTT-SN communication with bring-your-own SIM LTE & NB-IoT connectivity
  • MQTT Here - LoRaWAN IoT connectivity solution
  • MQTT Now - Cloud-based MQTT integration for IP devices

Get started with u-blox Thingstream today

Lee Stacey

物联网布道者 - u-blox 服务

Linkedin

You might also be interested in