MQTT (Message Queuing Telemetry Transport) is a lightweight message protocol based on the publish/subscribe method under the ISO standard, which is usually used in communication between devices and applications such as the Internet of Things and smart homes.
Content Express here：
The MQTT protocol consists of publisher/subscriber and message broker Broker. As shown in Figure 1, the publisher is responsible for pushing messages to the Broker, and the Broker pushes the messages to the matching subscribers.
Publisher: The device sends messages to subscribers through topics.
Subscriber: As a terminal device, a subscriber receives messages from a publisher through a topic.
Message broker (Broker): The server acts as a central hub responsible for organization-level communication between publishers and subscribers.
There are two main versions of MQTT: v3 and v5. The principles of these two versions are basically the same, but there are some key differences between them, and the following will introduce the differences between them from the following aspects.
MQTT protocol - design specifications, characteristics, principles
1. Development
Andy Stanford-Clark of IBM and Alan Nip of Cirrus Link wrote the first version of the protocol in 1999. In 2013, IBM submitted the MQTT version 3.1 specification to the Structured Information Standards Promotion Organization, with relevant charters to ensure that only a small number of changes to the specification can be made.
2. Overview
The MQTT (Message Queue Telemetry Transport) protocol is a message protocol based on the publish/subscribe paradigm under the ISO standard (ISO/IEC PRF 20922). It works on the TCP/IP protocol family and is a publish/subscribe message protocol designed for remote devices with low hardware performance and poor network conditions.
MQTT is a client-server based message publishing/subscribing transport protocol. The MQTT protocol is lightweight, simple, open and easy to implement. These characteristics make it widely applicable. Such as: machine-to-machine (M2M) communication and Internet of Things (IoT). They are also widely used in communicating sensors via satellite links, occasional dial-up medical devices, smart homes, and some miniaturized devices.
Related article about protocol:
3. Specification
Due to the particularity of the IoT environment, MQTT design needs to comply with the following specifications:
① Streamlined, without adding dispensable functions;
② Publish/Subscribe (Pub/Sub) mode to facilitate message transfer between sensors;
③ Allow users to dynamically create topics, zero operation and maintenance costs;
④ Minimize the amount of transmission to improve transmission efficiency;
⑤ Take factors such as low bandwidth, high latency, and unstable network into consideration;
⑥ Support continuous session control;
⑦ Understand that the computing power of the client may be low;
⑧ Provide service quality management;
⑨ Assuming that the data is agnostic, the type and format of the transmitted data are not required to maintain flexibility.
4. Features
The MQTT protocol is a protocol designed for communication between remote sensors and control devices in low-bandwidth, unreliable networks. It has the following main characteristics:
① Use the publish/subscribe message mode to provide one-to-many message publishing and decouple application programs.
② Message transmission for payload content masking.
③ Use TCP/IP to provide network connection.
④ There are three kinds of message publishing service qualities: "at most once", "at least once" and "only once".
⑤ Small transmission, small overhead (fixed-length header is 2 bytes), protocol exchange is minimized to reduce network traffic.
⑥ Use the Last Will and Testament features to notify the relevant parties of the mechanism of abnormal client interruption.
5. Principle
The realization of the MQTT protocol requires the completion of communication between the client and the server. During the communication process, there are three identities in the MQTT protocol: Publisher (Publish), Broker (Server), and Subscriber (Subscribe). Among them, the publisher and subscriber of the message are clients, the message agent is the server, and the publisher of the message can be the subscriber at the same time.
The message transmitted by MQTT is divided into two parts: topic (Topic) and load (payload):
Topic, which can be understood as the type of message, after the subscriber subscribes (Subscribe), he will receive the message content (payload) of the topic;
payload, which can be understood as the content of the message, refers to the specific content that the subscriber wants to use.
An MQTT client is an application or device using the MQTT protocol that always establishes a network connection to a server. Clients can be:
(1) Publish information that other clients may subscribe to;
(2) Subscribe to messages published by other clients;
(3) Unsubscribe or delete messages from the app;
(4) Disconnect from the server.
The MQTT server is called a "message broker" (Broker), which can be an application or a device. It is located between message publishers and subscribers. It can accept network connections from customers; accept application information published by customers; process subscription and unsubscribe requests from clients; and forward application messages to subscribed customers.
MQTT v5 adds a Property field, which enables MQTT v5 to support more new features. In MQTT v3, MQTT has no room for expansion, which limits the possibility of MQTT expansion.
A topic is a core concept in MQTT, which is used to identify the content and intent of a message. In MQTT v3, a topic is just a simple string whose structure is a series of words separated by slashes.
For example, an MQTT v3 topic could be sensors/temperature/room1, where sensors is the top-level topic, temperature is its subtopic, and room1 is a specific device under the subtopic.
However, in MQTT v5, the topic structure has been extended to include some more advanced features. Specifically, MQTT v5 introduces a new concept called topic aliases, which allow clients to map topic strings to predefined topic IDs, reducing network traffic and message size.
The topic alias is maintained by the client and the server respectively, and its life cycle and scope are limited to the current connection.
For a topic, set an alias when publishing for the first time, and then you can use the topic alias to publish. This enables clients to send only the topic ID when sending a message without having to send the full topic string every time. This is useful for IoT devices and environments with limited network bandwidth.
MQTT v5 introduces a new subscription type called shared subscription. More flexible subscriptions can be achieved through additional flags and filtering functions. As shown in the figure below, a shared subscription allows multiple clients to share a subscription and distribute it according to certain rules. This subscription type is very useful for subscribing to high-load topics, because it can balance subscription requests and reduce the load pressure of individual clients.
In addition, MQTT v5 adds the concept of subscription options, which can specify subscription options, such as QoS level, Retain As Publish, Retain Handling, message life cycle, etc., to control subscription behavior more finely.
Will messages are MQTT's ability to gracefully send wills to third parties for devices that may disconnect unexpectedly. In the Payload of the CONNECT message, some fields have changed, among which Will Message (will message) has become Will Payload (will payload).
Will Properties (will properties) is a new field in MQTT v5. Different types of messages have different properties. For example, CONNECT messages have attributes such as maximum message length and session expiration interval, and SUBSCRIBE messages have subscription identifiers, etc. Attributes. Moreover, compared with MQTT v3, the content of the will message becomes more flexible, and can contain any topic and any message content.
MQTT v5 supports a more detailed error handling mechanism, which can locate and solve problems through error codes and error reasons. At the same time, MQTT v5 also introduces a new control message - Disconnect message, which can help the client and server to better handle error conditions.
MQTT v5 introduces some new mechanisms for flow control based on the v3 version, in order to better control the transmission and processing of messages, and avoid network congestion and high load caused by excessive message transmission speed.
Maximum packet size limit (Maximum Packet Size): MQTT v5 allows the client and server to negotiate the maximum packet size during the handshake. As shown in the figure below, this maximum packet size limit can be used to control the maximum message size transmitted between the client and the server, preventing network congestion and excessive load due to excessively large transmitted messages.
Message Queue (Message Queue): When the message sent by the server exceeds the processing speed of the client, the server can store the message in the message queue and wait for the client to process it. MQTT v5 defines the queue size and timeout of the message queue to control the size and life cycle of the message queue.
Performance efficiency of MQTT
Compared with MQTT v3, MQTT v5 can better handle large-scale data transmission and improve communication efficiency and performance. For example, MQTT v5 supports functions such as Batch Publish and Message Prefetch, which can greatly reduce the overhead of MQTT communication.
In short, compared to MQTT v3, MQTT v5 has more new functions and security. However, it should be noted that MQTT v5 has added many new functions and concepts, so when using MQTT v5, it is necessary to have an in-depth understanding of the new features of the MQTT protocol so that this new protocol can be better used to build reliable application
- Introducing LoRa stable diffusion: based on LoRa communication
- Communication protocol: ModBus RTU protocol and ModBus TCP protocol
- Brief introduction of GPRS, 4G, NB-IOT wireless communication module
- 10 Strategies for Preventing Data Breaches
- Where is the "explosion point" of the smart sensor market?
- Why does China install so many surveillance cameras?
