Learn about MQTT protocol in one article

Today we will talk about the MQTT protocol in detail, because many messages now support the MQTT protocol, such as RabbitMQ and Kafka, etc. Today we will introduce in detail what the MQTT protocol is.

What is MQTT protocol

MQTT is a message queue transmission protocol that uses a subscription and publishing mechanism. Subscribers only receive data they have subscribed to, and do not receive non-subscribed data. This ensures the exchange of necessary data and avoids the storage and processing of invalid data. Therefore, it is widely used in the field of the Internet of Things, the communication between sensors and servers, and the collection of information.

Since it is a protocol, if compared with the TCP/IP protocol, which layer is it located in the layering?

I mentioned before that the TCP/IP reference model can be divided into four layers: application layer, transport layer, network layer, and network interface layer. TCP and UDP are located in the transport layer, and common protocols in the application layer include HTTP, FTP, SSH, etc. The MQTT protocol runs on top of TCP and belongs to the application layer protocol. Therefore, MQTT can be used wherever the TCP/IP protocol stack is supported.

Main features of MQTT protocol

1) Open message protocol, simple and easy to implement.

2) Use the publish/subscribe messaging model to provide one-to-many message publishing and decouple applications.

3) Message transmission with content shielding of the payload (application data carried by the protocol).

4) Based on TCP/IP network connection, it provides orderly, lossless, bidirectional connection.

The mainstream MQTT pushes data based on TCP connection, but there is also a UDP-based version called MQTT-SN. Since these two versions are based on different connection methods, their advantages and disadvantages are naturally different.

5) Message Quality of Service (QoS) support, reliable transmission guarantee; there are three message publishing service qualities:

QoS0: "At most once", message publishing is completely dependent on the underlying TCP/IP network. Message loss or duplication may occur. This level can be used in the following situations: environmental sensor data, it does not matter if a reading record is lost once, because there will be a second send soon. This method is mainly used for ordinary APP push. If your smart device is not connected to the Internet when the message is pushed, it will not be received when it is pushed, and it will not be received when it is connected to the Internet again.

QoS1: "At least once", which ensures that messages arrive, but message duplication may occur.

QoS2: "Only Once" ensures that the message arrives once. This level can be used in some billing systems with strict requirements. In the billing system, duplicate or lost messages will lead to incorrect results. This highest quality message publishing service can also be used for push notifications of instant messaging apps to ensure that users receive it and only receive it once.

What does this Qos0 mean? If you use this Qos0 configuration as the publishing quality, let's take the client and server as an example. The client sends a message to the server, but the server does not receive it. The configuration is "at most once". At this time, the client will not continue to send the same message to the server. I don't care whether you receive it or not. I configure it to be at most once.

Similarly, QoS1 is at least once, that is, when the client sends a message to the server, if there is no guarantee that the message will arrive, it may continue to send. I don’t care how many times I send it, as long as you don’t tell me that you received the message, then I will send it!

QoS2 is relatively rigorous. Why? It is equivalent to the client sending a message to the server. At this time, it is required to ensure that the client sends it once and the server receives it once. This is equivalent to the concept of only once.

6) Small transmission, low overhead (fixed-length header is 2 bytes), and minimal protocol exchanges to reduce network traffic.

That is why it is said in the introduction that it is very suitable for "communication between sensors and servers and information collection in the field of Internet of Things". It should be noted that the computing power and bandwidth of embedded devices are relatively weak, and it is more suitable to use this protocol to transmit messages.

MQTT Message

• Fixed header All messages contain
• Variable header: Some messages contain
• The payload part of the message contains

The fixed header format is as follows:

Bits 0-3 of the fixed header are flag bits, and the value of bits 4-7 of the first byte specifies the message type.

In fact, these types are also some methods (also called actions) defined in the MQTT protocol to represent operations on certain resources. This resource can represent pre-existing data or dynamically generated data, depending on the implementation of the server. Generally speaking, resources refer to files or outputs on the server.

MQTT protocol implementation

The implementation of the MQTT protocol requires communication between the client and the server. During the communication process, there are three identities in the MQTT protocol: publisher (Publish), broker (Broker) (server), and subscriber (Subscribe). Among them, the publisher and subscriber of the message are both clients, the message broker is the server, and the message publisher can be a subscriber at the same time.

Messages transmitted by MQTT are divided into two parts: Topic and Payload:

1) 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.

2) Payload, which can be understood as the content of the message, refers to the specific content that the subscriber wants to use (limited size).

MQTT message model based on subscription and publication

The process of sending and receiving MQTT messages:

• ClientA connects to Broker;
• ClientB connects to Broker and subscribes to Topic1;
• ClientA sends a message to Broker with the topic of Topic1;
• Broker receives the message from ClientA, finds that ClientB has subscribed to Topic1, and then forwards the message to ClientB;
• ClientB receives the message from Broker.

It is a little different from the traditional queue. If ClientB subscribes to Topic1 after ClientA publishes a message, ClientB will not receive the message.

That’s all I know about the basics of MQTT. When I learn new things about MQTT in the future, I will continue to share them with you.