MQTT protocol specifies the quality of service, which guarantees the reliability of message delivery under different network environments. The design of QoS is the focus of the MQTT protocol. As a protocol specifically designed for IoT scenarios, MQTT's operating scenarios are not only for PCs, but also in a wider range of narrow-bandwidth networks and low-power devices. If the problem of transmission quality can be solved at the protocol layer, it will provide great convenience for the development of Internet of things applications.
|QoS value||Bit 2||Bit 1||Description|
|0||0||0||Publish once at most|
|1||0||1||Publish once at least|
|2||1||0||Only publish once|
The two QoS bits of a PUBLISH packet cannot be set to 1 at the same time [MQTT-3.3.1-4]. If the server or client receives an invalid PUBLISH message with two QoS bits of 1, the network connection is closed by a DISCONNECT message with a reason code of 0x81 (invalid message)
When QoS is 0, the publish of messages depends on the capabilities of the underlying network. The publisher will publish the message only once, the receiver will not answer the message, and the publisher will not save and resend the message. Messages have the highest transmission efficiency at this level, but may not be delivered once.
When the QoS is 1, the message can be guaranteed to be published at least once. MQTT guarantees QoS 1 through a simple ACK mechanism. The publisher will publish the message and wait for the response of the receiver's PUBACK packet. If the PUBACK response is not received within the specified time, the publisher will set the message's DUP to 1 and resend the message. The receiver should respond to the PUBACK message when receiving a message with QoS 1. The receiver may accept the same message multiple times. Regardless of the DUP flag, the receiver will treat the received message as a new message and send a PUBACK packet as response.
When the QoS is 2, publishers and subscribers ensure that messages are published only once through two sessions. This is the highest level of service quality, and message loss and duplication are unacceptable. There is an additional cost to using this quality of service level.
After the publisher publishes a message with a QoS of 2, it will store the published message and wait for the receiver to reply with the PUBREC message. After the publisher receives the PUBREC message, it can safely discard the previous published message because it already knows the receiver successfully received the message. The publisher saves the PUBREC message and responds with a PUBREL, waiting for the receiver to reply with the PUBCOMP message. When the sender receives the PUBCOMP message, it will clear the previously saved state.
When the receiver receives a PUBLISH message with a QoS of 2, it processes the message and returns a PUBREC in response. When the receiver receives the PUBREL message, it discards all saved states and responds with PUBCOMP.
Whenever packet loss occurs during transmission, the sender is responsible for resending the previous message. This is true regardless of whether the sender is Publisher or Broker. Therefore, the receiver also needs to respond to each command message.
MQTT protocol stipulates that each time a message with QoS> 0 is published, a non-zero packet ID must be assigned [MQTT-2.2.1-4]. When the acknowledgement corresponding to this message is processed, the packet ID is released for reuse, and a certain packet ID cannot be used by multiple commands at a certain time.
QoS of MQTT publishing messages is not end-to-end, but between the client and the server. The QoS level at which subscribers receive MQTT messages ultimately depends on the QoS of the published message and the QoS of the topic subscription.
|QoS of published message||QoS of topic subscription||QoS of received message|
The higher the QoS level, the more complicated the process and the greater the system resource consumption. Applications can choose the appropriate QoS level according to their network scenarios and business requirements. For example, QoS 0 is often used for message exchange between services within the same subnet; QoS 1 is often used for real-time message communication over the Internet. There are relatively few scenarios for QoS2, which are suitable for demanding scenarios such as payment requests.