Our company's serial port server, CAN-bus to Ethernet, Ethernet edge acquisition IO gateway and other series of products have MQTT working mode. In this working mode, you can choose to use Alibaba Cloud and other platforms for related testing and communication.

MQTT (Message Queuing Telemetry Transport) is a lightweight publish/subscribe message transmission protocol that is widely used in the field of Internet of Things (IoT). One of its core features is QoS (Quality of Service), which adapts to different network environments and business needs by defining the reliability level of message delivery. This article will deeply analyze the three-level QoS service level of MQTT, and illustrate its application scenarios and characteristics with examples in actual scenarios.

Ⅰ. What is QoS? Simple classification

 The QoS (quality of service) of the MQTT protocol is actually the reliability level of message transmission, which is divided into three levels, corresponding to different "reliability levels".

 1.QoS 0 (transmit at most once)

 Essence: Don't care about it after sending it out, no confirmation and no retransmission.

Suitable for scenarios: For example, monitoring the temperature in the office, it doesn't matter if a few pieces of data are lost occasionally, anyway, it doesn't affect the overall trend.

 2.QoS 1 (transmit at least once)

 Essence: After sending, you will wait for the other party to reply "received". If there is no reply, you will keep resending, but it may be repeated.

Suitable for scenarios: For example, remotely control the air conditioner at home to turn off, and you are afraid that the command will not be transmitted, but it is no problem to turn it off again.

 3. QoS 2 (must be transmitted once and only once)

 Essence: Try your best to ensure that the message is not lost or duplicated, but the process is complicated and the transmission time is long.

Suitable for scenarios: For example, bank transfers must ensure that the instructions are absolutely accurate, and no extra money can be deducted or missed.  

Ⅱ. QoS Actual Cases

1. QoS 0: Save as much trouble as possible

 Scenario example: When building a factory equipment monitoring system, sensors upload data once a second.

Experience: I used QoS 1 at first, but found that the amount of data was too large for the server to handle. Later, I switched to QoS 0. Although data was lost occasionally, it had little impact on trend analysis, and the system became more stable.

Experience summary: Good network environment + data loss allowed in small amounts = choose QoS 0. 

2. QoS 1: Relatively reliable

 Scenario example: The customer wants to make a smart door lock remote unlocking function.

Experience: After using QoS 1, I found that occasionally due to network delays, the door lock would receive repeated "unlock" commands, which would cause users to feedback that "the lock always opens by itself". A deduplication logic can be added to the business layer, such as directly ignoring repeated commands within 30 seconds.

Experience summary: Choose QoS 1 for control commands, but the business layer must handle duplication issues. 

3. QoS 2: Absolutely reliable but costly

 Scenario example: Medical equipment uploads patient vital signs data to the cloud.

Pitfall experience: Because of using QoS 1, a network fluctuation caused data loss, which almost delayed diagnosis. Later, I gritted my teeth and changed to QoS 2. The transmission speed was a bit slower, but the data was definitely not lost or duplicated.

Experience summary: For sensitive scenarios such as medical/finance, QoS 2 must be used, even if performance is sacrificed.  

Ⅲ. How to choose QoS level? 

1. First look at the network environment:

- Stable network (such as LAN) → QoS 1 is enough.

- Poor network (such as mobile network) → QoS 2 is more secure.

2. Then look at business needs: 

- Data trend analysis → QoS 0.

- Control instructions → QoS 1.

- High-risk scenarios such as finance/medical care → QoS 2.

3. Need to weigh resources:

- Although QoS 2 is reliable, messages need to store status and multiple handshakes, which has high requirements for device memory and CPU. If the device is a low-end MCU, don't force QoS 2.  

Ⅳ.Common misunderstandings and pitfall avoidance guide

1. Myth 1: The higher the QoS level, the better

Truth: The overhead of QoS 2 is more than 5 times that of QoS 0! For example, we have done a test and found that 1,000 messages consume 30% more power with QoS 2 than with QoS 0. 

2. Myth 2: QoS 1 will never lose messages

Truth: If the sender loses network connection after sending the message, PUBACK may not be received, and the message is actually lost. QoS 1 can only guarantee "at least once", but it may still fail in extreme cases. 

3. Myth 3: The business layer does not need to handle duplication

Truth: QoS 1 duplicate messages must be handled by yourself! For example, when we were doing smart meter reading before, repeated instructions caused errors in electricity records. Later, a "unique ID + cache check" was added to solve the problem.

Ⅴ. Summary  

 Experience suggestions:

Suggestions for beginners: Practice with QoS 1 first, and then try QoS 2 after you are familiar with the protocol process.

Debugging tips: Use Wireshark to capture packets and look at the QoS handshake process to quickly locate problems.

Performance optimization: Do not use UUID for QoS 2 message IDs, use increasing integers to save memory.