It is an open OASIS and ISO standard lightweight, publish-subscribe network protocol that transports messages between devices.
Historically, the “MQ” in “MQTT” came from the IBM MQ.
Just like HTTP has a client and server, the MQTT protocol defines two types of network entities: a message broker and a number of clients. An MQTT broker is a server that receives all messages from the clients and then routes the messages to the appropriate destination clients. An MQTT client is any device (from a micro controller up to a full-fledged server) that runs an MQTT library and connects to an MQTT broker over a network.
The main difference between HTTP and MQTT is not just in the protocol structure or the data format, but it lies in the concept of Coupling and Decoupling.
To understand that aspect, we must know how MQTT works:
In MQTT, information is organized in a hierarchy of topics.
a) When a publisher has a new item of data to distribute, it sends a control message with the data to the connected broker.
b) The broker then distributes the information to any clients that have subscribed to that topic.
c) The publisher does not need to have any data on the number or locations of subscribers
d) The subscribers, in turn, do not have to be configured with any data about the publishers.
e) If a broker receives a message on a topic for which there are no current subscribers, the broker discards the message unless the publisher of the message designated the message as a retained message.
f) A retained message is a normal MQTT message with the retained flag set to true. The broker stores the last retained message and the corresponding QoS(Quality of Service) for the selected topic.
g) Each MQTT client that subscribes to a topic pattern that matches the topic of the retained message receives the retained message immediately after they subscribe.
h) The broker stores only one retained message per topic.This allows new subscribers to a topic to receive the most current value rather than waiting for the next update from a publisher.
If you want to compare HTTP and MQTT again, there are certain areas:
- Size of the message:The max payload size possible in MQTT is 256Mb and the minimum size of the packet length field is 1 byte.
- Eliminates vulnerable and insecure client connections.
- Can easily scale from a single device to thousands
- Manages and tracks all client connection states, including security credentials and certificates.
- Reduced network strain without compromising the security
Quality of Service (QoS)
Each connection to the broker can specify a quality of service measure. These are classified in increasing order of overhead:
- QoS 0 — At most once — the message is sent only once and the client and broker take no additional steps to acknowledge delivery (fire and forget).
- QoS 01— At least once — the message is re-tried by the sender multiple times until acknowledgement is received (acknowledged delivery).
- QoS 02— Exactly once — the sender and receiver engage in a two-level handshake to ensure only one copy of the message is received (assured delivery).
This field does not affect handling of the underlying TCP data transmissions; it is only used between MQTT senders and receivers.
Latest MQTT version v5.0
In 2019, OASIS released the official MQTT 5.0 standard. Version 5.0 includes the following major new features:
- Reason codes: Acknowledgements now support return codes, which provide a reason for a 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