MQTT is a standards-based messaging protocol or set of rules used for machine-to-machine communication. Smart sensors, wearables, and other Internet of Things (IoT) devices often have to transmit and receive data over networks with limited resources and bandwidth. These IoT devices use MQTT for data transmission because the protocol is easy to implement and can communicate IoT data efficiently. MQTT supports device-to-cloud and cloud-to-device messaging.
The MQTT protocol has become an IoT data transmission standard because it offers the following benefits:
Implementing MQTT on an IoT device requires minimal resources so it can even be used on small microcontrollers. For example, a minimum MQTT control message can be as small as two bytes of data. The MQTT message header is also small so you can optimize the network bandwidth.
MQTT implementation requires a minimal amount of code that consumes very little power in operations. The protocol also has built-in features to support communication with a large number of IoT devices. Therefore, you can implement the MQTT protocol to connect to these millions of devices.
Many IoT devices connect over unreliable cellular networks with low bandwidth and high latency. MQTT has built-in features that reduce the time it takes IoT devices to reconnect to the cloud. MQTT also defines three different levels of quality of service to ensure reliability for IoT use cases – at most once (0), at least once (1) and only once (2) .
MQTT makes it easy for developers to encrypt messages and authenticate devices and users using modern authentication protocols, such as OAuth, TLS1.3, Client Managed Certificates, and more.
Some languages like Python have widespread support for MQTT protocol implementations. As a result, developers can quickly implement this protocol with little need to code in any kind of application.
The MQTT protocol was invented in 1999 for use in the oil and gas industry. Engineers need a protocol that uses the least bandwidth and uses the least battery to monitor oil pipelines via satellite. This protocol was originally called Queueed Remote Message Transfer Protocol, as it was initially supported by the IBM MQ Product Line. In 2010, IBM released MQTT 3.1 as a free and open protocol for anyone to deploy. Then, in 2013, the protocol was submitted to the Organization for the Advancement of Structured Information Standards (OASIS) specifications body for maintenance. In 2019, OASIS released upgraded MQTT version 5. Now MQTT is no longer an acronym but is considered the official name of the protocol.
The MQTT protocol works on the principle of the publish/subscribe model. During traditional network communication, the client and server communicate directly with each other. The client requests a resource or data from the server, then the server processes and sends back a response. However, MQTT uses the publish/subscribe pattern to separate the sender of the message (the sender of the message) from the receiver of the message (the recipient of the message). Instead, a third component called a message carrier handles the communication between the sender of the message and the receiver of the message. It is the job of the transmitter to filter all messages coming from the sender of the message and deliver the messages exactly to the destination of the message. The transporter separates the sender and receiver of the message as follows:
The sender and receiver of the message do not know each other’s locations on the network and do not exchange information such as IP addresses and port numbers.
Message sender and message receiver are not running or have network connection at the same time.
Both the sender and the receiver can send or receive messages without interrupting the other party’s operations. For example, the receiver of the message does not have to wait for the sender to send the message.
MQTT implements publish/subscribe model by defining server and transporter as shown below.
An MQTT client is any device from a server to a microcontroller that runs an MQTT library. If the client sends the message, it acts as the sender of the message, and if it receives the message, it acts as the receiver. Basically, any device that communicates using MQTT over a network can be called an MQTT client.
The MQTT transporter is a backend system that coordinates messages between different clients. The transporter’s responsibilities include receiving and filtering messages, determining which clients have subscribed to each message, and sending messages to those clients. The feeder is also responsible for performing other tasks such as:
The client and server initiate communication with an MQTT connection. The client initiates the connection by sending a CONNECT message to the MQTT transporter. The transporter confirms that the connection has been established by replying with a CONNACK message. Both the MQTT client and the transporter need the TCP/IP stack to communicate. The clients never connect to each other, but only to the transporter.
Here’s an overview of how MQTT works.
Let’s analyze the details for a deeper understanding.
The term “subject” refers to the keywords the MQTT transporter uses to filter messages for the MQTT client. Topics are organized hierarchically, similar to the path to a file or folder. For example, consider a smart home system operating in a multi-storey house with different smart devices on each floor. In that case, the MQTT transporter can organize topics like:
our house/ground floor/living room/light
our house/first floor/kitchen/temperature
The MQTT client publishes messages containing the subject and data in byte format. The client defines a data format such as text data, binary data, XML or JSON files. For example, a lamp in a smart home system might publish a message about theme living room/lighting.
The MQTT client sends a SUBSCRIBE message to the MQTT transporter to receive messages on topics of interest. This message contains a unique identifier and a subscription list. For example, the smart home app on your phone wants to show how many lights are on in your home. This application will subscribe to the topic light and increment the counter on all messages about the on state.
MQTT communication uses SSL protocol to protect sensitive data transmitted by IoT devices. You can implement identity, authentication, and authorization between the client and the transporter using an SSL certificate and/or password. MQTT transporters typically authenticate clients using their passwords as well as unique client identifiers that the transporter allocates to each client. In most deployments, the client authenticates the server with a certificate or DNS lookup. You can also implement encryption protocols with MQTT.
MQTT is not RESTful. Representative State Transition (REST) is an architectural approach to network communication that uses a request-response communication model between the sender and receiver of the message. In contrast, MQTT uses a publish/subscribe communication model in the application layer and requires a permanent TCP connection to pass messages by push. However, MQTT version 5 adds a new request/response method to work in a similar way to REST, where the sender of the message can attach a special response subject that the receiver handles. and respond appropriately.
Thứ Hai - Thứ Sáu: 8:00 - 17:30
Thứ Bảy: 8:00 - 12:00
Thứ Hai - Thứ Sáu: 8:00 - 17:30
Thứ Bảy: 8:00 - 12:00