Message Queuing Telemetry Transport (MQTT) is a popular and lightweight publish-subscribe messaging protocol that is ideal for connecting Internet of Things (IoT) or machine-to-machine (M2M) devices and applications over the internet. MQTT is designed to operate efficiently in low-bandwidth or low-power environments, making it an ideal choice for applications with a large number of remote clients. It’s used in a variety of industries, including consumer electronics, automotive, transportation, manufacturing, and healthcare.
Devices or applications connected via MQTT are known as clients. These clients publish and/or subscribe to messages on a specific topic or on multiple topics. Subscribed clients receive all messages published to that topic, enabling efficient and fault-tolerant data exchange between many devices and services.
At the heart of an MQTT architecture is a broker. The broker is a server responsible for tracking clients (and any topics they’re subscribed to), processing messages, and routing those messages to appropriate systems.
Several key versions of the MQTT protocol have been adopted as a standard. The OASIS organization manages revisions of the protocol and maintains a complete specification for each version. Each revision of MQTT has expanded on the protocol feature set, so it’s important to know which version of MQTT your devices and broker adhere to.
There are several types of MQTT messages, and each message type contains a specific format that conforming devices and applications must follow. Revisions to the MQTT protocol vary in format and message types. A complete list of message types can be found in each specification of the MQTT protocol.
The three most common types of messages are CONNECT, PUBLISH, and SUBSCRIBE. Each MQTT message contains a header, payload, and optional flags. Depending on the message type, the payload can be variable in length. For example, in a PUBLISH message, the payload contains the data to be sent to all subscribing devices and the length of the data field has a direct bearing on the message’s size. By default, MQTT devices connect on port 1883 in an unsecured fashion or port 8883 when SSL/TLS encryption has been enabled.
Smart cars are a great example of MQTT in action. As auto manufacturers add new features to support everything from remote diagnostics and fleet management to fuel payments and entertainment, MQTT has become a common standard for connected cars. Unlike the Hypertext Transfer Protocol (HTTP) protocol, MQTT can maintain a persistent session even when a car moves in and out of dead zones or if its connection changes cell towers. MQTT also supports bidirectional communications, making it easier for the car and cloud application to send and receive data without waiting for the other to respond.
HTTP and MQTT are both network protocols used to transmit data over the internet. Let’s look at their differences.
Many features of MQTT make it the ideal protocol for messaging between IoT devices (the “things” in IoT) and backend systems. Here, we focus on four features:
MQTT supports Transmission Control Protocol/Internet Protocol (TCP/IP) as its underlying transport protocol. This widely used networking protocol ensures messages are sent reliably between clients and brokers.
There are several reasons why TCP/IP is considered reliable and efficient:
While it’s the most common, TCP/IP is not the only choice for transport of MQTT messages. The MQTT protocol also works over User Datagram Protocol (UDP) and WebSockets.
We are proud to offer the following free resources to help you continue researching how NGINX can secure, load balance, and provide high availability for MQTT-based IoT systems.