MQTT (Message Queuing Telemetry Transport) is a client-server messaging protocol based on the publish/subscribe model. After establishing an MQTT connection, whether the client publishes messages to the server or the server pushes messages related to subscribed topics to the client, messages are sent using the Publish packet.

__Parameters__
QoS: Quality of Service (QoS): QoS 0 at most once; QoS 1 at least once; QoS 2 exactly once. The specific differences are detailed below.
RETAIN: Specifies whether the message is a retained message.
The MQTT server stores the latest retained message for each topic. When a client subscribes to a topic, if the server has a retained message that matches the topic, that retained message will be sent immediately to the client.
In the publish/subscribe model, when a subscriber receives a message entirely depends on when the publisher publishes the message, which can be inconvenient in certain scenarios. With retained messages, new subscribers can immediately obtain the latest state without having to wait an unpredictable amount of time.
Topic Name: The name of the message topic.
Packet Identifier: A unique identifier for the packet, used for sending QoS 1 and QoS 2 packets. See below for details.
Message Expiry Interval: The expiration time of the message (s). When the message expiry interval is reached and the server fails to initiate message pushing to the matching subscribers, the server must delete the message.
Response Topic: The name of the response message topic. When the message contains a response topic, the receiver should obtain the Response Topic value from the message and use that value as the topic name to publish the response message.
01
__Publishing QoS 0 Messages__
The receiver does not return a response, and the sender has no retransmission mechanism; the delivery of the message entirely depends on the underlying network capabilities. The application message may arrive at the receiver once or be lost.

In simple terms, a QoS 0 message is like shouting into a crowd: the speaker shouts and leaves, not caring whether anyone heard it or if noise interfered with the sound transmission. This is the meaning of “at most once”—it may arrive at most once, but it may also not arrive at all.
02
__Publishing QoS 1 Messages__
To ensure message delivery, QoS 1 introduces acknowledgment and retransmission mechanisms. Before sending, the sender saves the message in case it needs to be retransmitted and specifies a Packet Identifier in the PUBLISH packet as the unique identifier for the packet. After the receiver receives the Publish packet, it replies with a PUBACK packet using the same Packet Identifier. The sender considers the message delivery successful upon receiving the PUBACK packet and deletes the stored message.
If the sender does not receive the PUBACK acknowledgment within the specified time (due to network delays, acknowledgment loss, slow processing by the receiver, connection interruptions, etc.), it will retransmit the message (the DUP flag of the message will be set to 1). In this case, if the receiver does not have an effective deduplication mechanism, it may result in duplicate messages.

To put it simply: imagine you have a very responsible but somewhat forgetful delivery person (QoS 1 transmission mechanism). You ask them to deliver an important package (message). The rule is: they must hand the package directly to the recipient (receiver), and the recipient must sign for it (PUBACK). If the delivery person does not receive the signed receipt within a certain time, or suspects that the receipt was lost on the way, they will make another trip to deliver an identical package (retransmission). As a result, the recipient may receive two packages. The delivery person guarantees that the package will be delivered at least once (reliability), but does not guarantee that it will be delivered only once (no duplicates). The recipient needs to determine whether the two packages are the same and how to handle the second package (application layer deduplication).
03
__Publishing QoS 2 Messages__
QoS 2 is the strictest reliability level in the MQTT protocol, eliminating the possibility of message duplication and loss through a carefully designed four-step handshake protocol and state storage mechanism.

Assuming the sender is A and the receiver is B:
1. A → B: PUBLISH (QoS=2, Packet Identifier=N)
– A assigns a unique Packet Identifier = N to the message and stores it locally.
– A sends the message (status marked as “sent, waiting for confirmation”).
This is the first transmission of the message.
2. B → A: PUBREC (Packet Identifier=N)
– B successfully receives and stores Packet Identifier = N (status marked as “received, not completed”).
– B sends A a PUBREC (Publish Received) acknowledgment packet, containing the same Packet Identifier = N.
PUBREC indicates: “I have received message N and am capable of completing the processing. Please proceed to the next step and do not retransmit it!”
3. A → B: PUBREL (Packet Identifier=N)
– After receiving PUBREC, A discards the locally stored message content (no longer needs to retransmit), but retains the Packet Identifier (the message is in the “waiting for release” stage).
– A sends B a PUBREL (Publish Release) packet, containing Packet Identifier = N.
PUBREL indicates: “I know you have received message N. Please confirm that you are ready to complete this delivery.”
4. B → A: PUBCOMP (Packet Identifier=N)
– B receives PUBREL and marks the message as “completed”.
– B discards the locally stored Packet Identifier = N related to that message.
– B sends A a PUBCOMP (Publish Complete) acknowledgment packet, containing Packet Identifier = N.
PUBCOMP indicates: “Processing complete! The delivery of message N has been finally confirmed.”
After A receives PUBCOMP, it discards Packet Identifier = N.
Summary: How QoS 2 Ensures “Exactly Once”
Prevention of Content Resending: The sender is prohibited from retransmitting the message content after receiving PUBREC.
State Machine Driven: The entire process is a stateful, Packet Identifier-based handshake protocol. Any recovery after an interruption relies on the stored state to continue the process, rather than retransmitting content.
Receiver Deduplication: The receiver strictly identifies and discards duplicate transmission requests based on the Packet Identifier (whether duplicate PUBLISH or duplicate PUBREL), processing the content only once.
Separation of Content and Control: The last two handshake steps only transmit control information (Packet Identifier) without transmitting message content, fundamentally eliminating content duplication caused by retransmission.