MQTT Essentials Part 6: Quality of Service 0, 1 & 2


Welcome to the sixth part of the MQTT Essentials, a blog series about the core features and concepts in the MQTT protocol. In this post we’ll focus on the different Quality of Service levels within MQTT. We already stumbled upon the term ‘quality of service’ a few times in some of the previous posts, so now is the time to explain what’s behind it.

Quality of Service

What is Quality of Service?

The Quality of Service (QoS) level is an agreement between sender and receiver of a message regarding the guarantees of delivering a message. There are 3 QoS levels in MQTT:

  • At most once (0)
  • At least once (1)
  • Exactly once (2).

When talking about QoS there are always two different parts of delivering a message: publishing client to broker and broker to subscribing client. We need to look at them separately since there are subtle differences. The QoS level for publishing client to broker is depending on the QoS level the client sets for the particular message. When the broker transfers a message to a subscribing client it uses the QoS of the subscription made by the client earlier. That means, QoS guarantees can get downgraded for a particular receiving client if subscribed with a lower QoS.

Why is Quality of Service important?

QoS is a major feature of MQTT, it makes communication in unreliable networks a lot easier because the protocol handles retransmission and guarantees the delivery of the message, regardless how unreliable the underlying transport is. Also it empowers a client to choose the QoS level depending on its network reliability and application logic.

How does it work?

So how is the quality of service implemented in the MQTT protocol ? We will look at each level one by one and explain the functionality.

QoS 0 – at most once

The minimal level is zero and it guarantees a best effort delivery. A message won’t be acknowledged by the receiver or stored and redelivered by the sender. This is often called “fire and forget” and provides the same guarantee as the underlying TCP protocol.


QoS 1 – at least once

When using QoS level 1, it is guaranteed that a message will be delivered at least once to the receiver. But the message can also be delivered more than once.


The sender will store the message until it gets an acknowledgement in form of a PUBACK command message from the receiver.


The association of PUBLISH and PUBACK is done by comparing the packet identifier in each packet. If the PUBACK isn’t received in a reasonable amount of time the sender will resend the PUBLISH message. If a receiver gets a message with QoS 1, it can process it immediately, for example sending it to all subscribing clients in case of a broker and then replying with the PUBACK.
The duplicate (DUP) flag, which is set in the case a PUBLISH is redelivered, is only for internal purposes and won’t be processed by broker or client in the case of QoS 1. The receiver will send a PUBACK regardless of the DUP flag.

QoS 2

The highest QoS is 2, it guarantees that each message is received only once by the counterpart. It is the safest and also the slowest quality of service level. The guarantee is provided by two flows there and back between sender and receiver.


If a receiver gets a QoS 2 PUBLISH it will process the publish message accordingly and acknowledge it to the sender with a PUBREC message.


The receiver will store a reference to the packet identifier until it has send the PUBCOMP. This is important for avoid processing the message a second time. When the sender receives the PUBREC it can safely discard the initial publish, because it knows that the counter part has successfully received the message. It will store the PUBREC and respond with a PUBREL.


After the receiver gets the PUBREL it can discard every stored state and answer with a PUBCOMP. The same is true when the sender receives the PUBCOMP.


When the flow is completed both parties can be sure that the message has been delivered and the sender also knows about it.

Whenever a packet gets lost on the way, the sender is responsible for resending the last message after a reasonable amount of time. This is true when the sender is a MQTT client and also when a MQTT broker sends a message. The receiver has the responsibility to respond to each command message accordingly.

Good to know

There are a few things you should have in mind when using QoS. These are not obvious or clear on first sight.

Downgrade of QoS

As already said, the QoS flows between a publishing and subscribing client are two different things as well as the QoS can be different. That means the QoS level can be different from client A, who publishes a message, and client B, who receives the published message. Between the sender and the broker the QoS is defined by the sender. When the broker sends out the message to all subscribers, the QoS of the subscription from client B is used. If client B has subscribed to the broker with QoS 1 and client A sends a QoS 2 message, it will be received by client B with QoS 1. And of course it could be delivered more than once to client B, because QoS 1 only guarantees to deliver the message at least once.

Packet identifiers are unique per client

Also important to know is that each packet identifier (used for QoS 1 and QoS 2) is unique between one client and a broker and not between all clients. If a flow is completed the same packet identifier can be reused anytime. That’s also the reason why the packet identifier doesn’t need to be bigger than 65535, because it is unrealistic that a client sends a such large number of message, without completing the flow.

Best Practice

We are often asked, when to choose which QoS level. The following should provide you some guidance if you are also confronted with this decision. Often this is heavily depending on your use case.

Use QoS 0 when …

  • You have a complete or almost stable connection between sender and receiver. A classic use case is when connecting a test client or a front end application to a MQTT broker over a wired connection.
  • You don’t care if one or more messages are lost once a while. That is sometimes the case if the data is not that important or will be send at short intervals, where it is okay that messages might get lost.
  • You don’t need any message queuing. Messages are only queued for disconnected clients if they have QoS 1 or 2 and a persistent session.

Use QoS 1 when …

  • You need to get every message and your use case can handle duplicates. The most often used QoS is level 1, because it guarantees the message arrives at least once. Of course your application must be tolerating duplicates and process them accordingly.
  • You can’t bear the overhead of QoS 2. Of course QoS 1 is a lot fast in delivering messages without the guarantee of level 2.

Use QoS 2 when …

  • It is critical to your application to receive all messages exactly once. This is often the case if a duplicate delivery would do harm to application users or subscribing clients. You should be aware of the overhead and that it takes a bit longer to complete the QoS 2 flow.

Queuing of QoS 1 and 2 messages

All messages sent with QoS 1 and 2 will also be queued for offline clients, until they are available again. But queuing is only happening, if the client has a persistent session.

So that’s the end of part six in our MQTT Essentials series. We hope you enjoyed it. In the next post we’ll cover persistent sessions in MQTT, which are tied up closely with Quality of Service levels.

Have a great week and we’ll hope to see you on the next MQTT Monday!

You like the MQTT Essentials? Then sign up for our newsletter and get notified on each new post as soon as its available. If you prefer RSS, you can subscribe to our RSS feed here.


  1. Fernando says:

    I have one question about QoS.

    As mentioned before MQTT protocol is above the Transport Layer or TCP. my understanding about TCP is that every time it sends a datagram, the receiver acknowledge it and also provides QoS. So why to use the QoS when protocols like TCP already have it? Does not make it redundant?

    Thank you.

    1. Hi Fernando,

      this is a great question! A very extensive and in-depth answer by Andy Stanford-Clark (one of the inventors of MQTT) can be found here in the following link, make sure to check it out:!searchin/mqtt/stanford/mqtt/6JZTV5XIwEQ/9K6QolImMdUJ

      To summarize the excellent link: TCP offers reliability on top of the TCP / IP stack, MQTT offers application-to-application data reliability. This differentiation is very important if you are dealing with unreliable networks (mobile, wifi, …) since in-flight packets can get lost if your TCP connection drops.

      Hope this helps!
      Dominik from the HiveMQ Team

  2. Rohit says:


    Is there a way to browse a given mqtt topic,without messages to be deleted/removed. Kind of non destructive read?

    1. Hi,

      each client (with persistent session) has its own queue if the client is offline, Topics can’t be browsed per se. If you are looking for an approach to read all messages on a specific topic, you can just spawn a new client which subscribes to that topic. All other clients won’t be affected by that.

      All the best,
      Dominik from the HiveMQ Team

  3. Eddie says:

    Hi all,
    I have 2 questions regarding reliability with QoS:
    – if a publisher send a message to a subscriber using a broker, how can publisher knows when receiver receives the message.
    – What is the purpose of the packetid from the publish command, since receiver will not see it (i’ve played with emqtt…an erlang mqtt server) and :
    sender publish to a topic with a packetid=5 ….broker ..receive it and send back the pub ack…and the subscriber receive it but with a different packet id


    1. Hi Eddie,

      the publisher does not know that the message was delivered to a subscriber. The publisher only knows when the message was published successfully to the broker. The publishers and subscribers are completely de-coupled. For more details about that I can recommend:

      The packet identifier is used for identifying associated messages in a message flow so. A message flow is always Client -> Broker or Broker -> Client. Each Tuple [Client,Broker] use their own packet ids due to the de-coupling in a pub/sub system. So the packet identifier is needed for the client and broker implementations to collate messages. Packet ids are usually a implementation detail and most client APIs don’t expose the packet identifier.

      Hope this helps,
      Dominik from the HiveMQ Team

  4. Iain. says:


    Regarding receiving a PUBLISH with a QoS of 2 you say the following:

    “After the receiver gets the PUBREL it can discard every stored state and answer with a PUBCOMP. The same is true when the sender receives the PUBCOMP.”

    However, what happens if the PUBCOMP goes missing? The broker will resend the PUBREL but if the client has discarded every stored state, then the sequence which lead to the PUBREL will have been forgotten and the client will behave as if it has just received a PUBREL out of the blue. I am struggling to find an elegant way to handle this, but maybe I am missing something?

    Thanks for creating this series. I’ve found it very useful.


  5. Iain says:


    Is your commenting system working correctly? For instance on this page ( it states there are 8 comments, but I can only see 6. Other pages have similar discrepancies. I posted a comment on this page a few days ago and after an initial “waiting for moderation” message it disappeared.


    1. Hi Iain,

      sorry for the late reply. The comment should now be available.

      Regarding the comment number: Thanks for the heads up! We’ll check if there’s a problem with the displayed number.

      Thanks so much,
      Dominik from the HiveMQ Team

  6. tayyab says:

    great tutorials. thanks

  7. AlekSi says:

    > The duplicate (DUP) flag, which is set in the case a PUBLISH is redelivered, is only for internal purposes and won’t be processed by broker or client in the case of QoS 1. The receiver will send a PUBACK regardless of the DUP flag.

    What about QoS 2?

    1. Hi AlekSi,

      the same goes for QoS 2 but with PUBREC instead of PUBACK.

      The HiveMQ Team

  8. William says:

    Thanks for these great articles. I have questions about the process of QoS 2. Regarding this article: “After the receiver gets the PUBREL it can discard every stored state and answer with a PUBCOMP. The same is true when the sender receives the PUBCOMP.”

    What happens if the PUBCOMP message missing? Is there any mechanism for the receiver to resend the PUBCOMP message?

    Because this article says that: After the sender received the PUBREC message, the sender can safely discard the initial publish and It will store the PUBREC and respond with a PUBREL.

    When the PUBCOMP message got lost, the sender is still stored the PUBREC message. It can not discard every stored state, and keep it forever.

    William Luo

  9. sujithra says:

    Hi Williams,
    Regarding your response for the “What happens if the PUBCOMP message goes missing? ” .. The question is all about… When PUBCOMP gets lost, the sender will have PUBREC messag by which is might resend the PUBREC message, but the receiver has already discared all the stored state as said above. Then how will it recognize the sender and resend PUBCOMP when it doesnt have any info about the sender.????

    1. Adr says:

      Does any one have an answer to this ?
      “What happens if the PUBCOMP message goes missing?”


    2. Hallo Adrien,

      Let’s take a look at the MQTT 3.1.1 spec

      When a Client reconnects with CleanSession set to 0, both the Client and Server MUST re-send any unacknowledged PUBLISH Packets (where QoS > 0) and PUBREL Packets using their original Packet Identifiers [MQTT-4.4.0-1]. This is the only circumstance where a Client or Server is REQUIRED to redeliver messages.

      What this means is the following:
      It is the sender’s * job to resend unacknowledged packages, when a connection was lost and reconnection happened. (This is true for both QoS 1 and QoS 2)
      Since TCP is the underlying transport protocol for MQTT, when a message ‘goes missing’ a connection loss will inevitably get registered.

      * For clarification:
      Sender does not mean broker or client – both function as a sender in different scenarios. When publishing, the client is the sender. When forwarding a published message to a subscriber, the broker is the sender.

      I hope this answers your question.
      Best regards,
      Florian, from The HiveMQ Team.

  10. arijit says:

    Thanks for these great articles. I have questions about uses of Quality of Service . It’s mentioned in article that for critical application we should use Quality of Service 2 but for which kind of application we should use Quality of Service 2 and for which we should use Quality of Service 1 ?Please provide some specific example.


    1. In general we recommend to go with QoS 1, since the guarantees (at least once) are often perfect for most scenarios. If you have a scenario where you can make sure that the persistent state of a client gets never corrupted, QoS 2 might be a good option if you really want exactly once delivery. Most clients chose to use QoS 1 with manual de-duplication (if needed by the scenario) for best performance and overhead ratio.

      Hope this helps,

  11. Bipal Shakya says:

    I would like to know what you mean by the following extract regarding QoS-0.:
    “This is often called “fire and forget” and provides the same guarantee as the underlying TCP protocol.”

    Is TCP fire-and-forget?? Or do you mean to say that although MQTT QoS-0 is fire-and-forget, it will provide the guarantee provided by TCP?

    1. Hallo Bipal,

      To clarify:
      TCP itself is of course not ‘fire and forget’ and guarantees delivery, as long as the connection is not lost. Unlike UDP for example.
      So as long as there is no connection loss, message delivery is guaranteed on TCP layer.
      QoS 0 is ‘fire and forget’ and therefore does not provide any additional guarantees on MQTT layer.
      Quality of Service levels higher than 0 provide extra guarantees for failure cases.
      As MQTT is at times used in unreliable mobile network scenarios or similar environments, it is often useful to take advantage of these additional guarantees.

      I hope this helps.
      Kind regards,
      Florian, from The HiveMQ Team.

Leave a Reply

Your email address will not be published. Required fields are marked *