Briefly describe the concept of MQTT protocol

MQTT protocol official website

1. The principle of MQTT protocol

        The MQTT protocol is an IoT communication protocol based on Publish | Subscribe

Highlights:

        1. Simple and easy to implement

        2. Support Qos service quality

        3. Small message size (MQTT protocol is built on top of TCP/IP protocol)

Publish subscriber pattern:

        

         The client only needs to subscribe to this topic. When other clients want to send a message to the server, the client can receive the message and realize real-time communication.

Request response mode:

        Request response mode: the client sends a request to the server, and the server returns a response to the client after receiving the request

 2. Introduction to MQTT protocol

        (Message Queuing Telemetry Transport, message queue, telemetry transmission protocol), is a "lightweight" communication protocol based on the publish/subscribe (publish/subscribe) model, which is built on the TCP/IP protocol, developed by IBM in 1999 year released. The biggest advantage of MQTT is that it can provide real-time and reliable message services for remote connected devices with very little code and limited bandwidth.
        MQTT is a client-server based message publishing/subscribing transport protocol . The MQTT protocol is lightweight, simple, open and easy to implement. These characteristics make it widely applicable. In many cases, including constrained environments such as: machine-to-machine (M2M) communication and the Internet of Things (loT). It has been widely used in communication sensors via satellite links, occasional dial-up medical devices, smart homes, and some miniaturized devices (widely used in the node server Internet of Things).

 3. MQTT protocol design specification

  1. Streamlined, without adding dispensable functions;
  2. Publish/Subscribe (Pub/Sub) mode facilitates message transfer between sensors, decoupling Client/Server mode, the advantage is that it does not need to know the existence of the other party (ip/port) in advance, and does not have to run at the same time
  3. Allow users to dynamically create topics (no need to pre-create topics), zero operation and maintenance costs;
  4. Minimize transfer volume to improve transfer efficiency
  5. Take factors such as low bandwidth, high latency, and unstable networks into consideration;
  6. Supports continuous session retention and control (heartbeat protocol)
  7. Understand that client computing power may be low
  8. Provide quality of service (quality of service level: QoS) management:
  9. The type and format of the transmitted data are not required to maintain flexibility (referring to the application layer business data)

 4. Main features of MQTT protocol

  1. Open message protocol, simple and easy to implement.
  2. Use the publish/subscribe message mode to provide one-to-many message publishing and decouple application programs.
  3. Message transmission that masks the content of the payload (application data carried by the protocol).
  4. Based on TCP/IP network connection , it provides orderly, lossless, two-way connection .
    The mainstream MQTT is based on the TCP connection for data push, but there is also a UDP-based version called MQTT-SN. Since these two versions are based on different connection methods, their advantages and disadvantages are naturally different.
    Due to the different connection methods, the advantages and disadvantages are naturally different.
  5. Message quality of service (QoS) support, reliable transmission guarantee; there are three message release quality of service:
    QoSO : "at most once", message release completely depends on the underlying TCP/IP network. Message loss or duplication can occur. This level can be used in the following situations, environmental sensor data, it does not matter if a read record is lost, because there will be a second send in the near future. This method is mainly for the push of ordinary APPs. If your smart device is not connected to the Internet when the message is pushed, the push has not been received in the past, and it will not be received when it is connected to the Internet again.
    QoS1 : "At least once", to ensure that the message arrives, but message duplication may occur.
    QoS2 : "Only once", to ensure that the message arrives once. This level can be used in some billing systems with strict requirements. In billing systems, duplicate or missing messages can lead to incorrect results. This highest-quality message publishing service can also be used for instant messaging APP push, to ensure that users receive and only receive once.
  6. 1-byte fixed header, 2-byte heartbeat message, minimizing transmission overhead and protocol exchange, effectively reducing network traffic.
    That's why it is said in the introduction that it is very suitable for "in the field of Internet of Things, the communication between sensors and servers, and the collection of information. It is important to know that the computing power and bandwidth of embedded devices are relatively weak. Using this protocol to transmit messages is perfect. up.
  7. Online Status Awareness: Use the Last Will and Testament features to notify relevant parties of the mechanism of abnormal client interruption.
    Last Will: It is the last will mechanism, which is used to notify other devices under the same topic that the device that sent the last will has been disconnected.
    Testament: Will mechanism, similar in function to Last Will.

Five, MQTT application field

  • IoT M2M communication, IoT big data collection
  • Android message push, WEB message push
  • Mobile instant messaging, such as Facebook Messenger
  • Smart hardware, smart furniture, smart appliances
  • Vehicle networking communication, electric station pile collection
  • smart city, telemedicine, distance education
  • Power, oil and energy industry markets

6. Implementation of MQTT protocol 

        The realization of the MQTT protocol requires the completion of communication between the client and the server. During the communication process, there are three identities in the MQTT protocol: Publisher, Broker (Server), and Subscriber. Among them, the publisher and subscriber of the message are clients, the message agent is the server, and the publisher of the message can be the subscriber at the same time.

         The message transmitted by MQTT is divided into two parts: topic (Topic) and payload (payload):
(1) Topic: It can be understood as the type of message. After subscribing (Subscribe), the subscriber will receive the message content (payload) of the topic )
(2) payload: It can be understood as the content of the message, which refers to the specific content to be used by the subscriber

Network Transport and Application Messages

        MQTT will build the underlying network transmission: it will establish a client-to-server connection, providing an ordered, lossless, byte-stream-based bidirectional transmission between the two.
When application data is sent through the MQTT network, MQTT will associate the related quality of service (QoS) with the topic name (Topic)

MQTT client

  An application or device using the MQTT protocol that always establishes a network connection to a server. Clients can:

  • (1) Publish information that other clients may subscribe to
  • (2) Subscribe to messages published by other clients
  • (3) Messages to unsubscribe or delete the app
  • (4) Disconnect from the server

MQTT server side

The MQTT server is called "message broker" (Broker), which can be an application or a device. It is located between the message publisher and the subscriber. It can:

  • (1) Accept network connections from customers;
  • (2) Accept application information released by customers
  • (3) Handle subscription and unsubscription requests from clients
  • (4) Forward application messages to subscribed clients

Pub/Sub, Topics, Sessions

        MQTT is based on the Publish/Subscribe mode for communication and data exchange, which is fundamentally different from the HTTP Request /         Response mode  . ) to subscribe to a topic (Topic) . After successfully subscribing , the message server will forward the messages under the topic to all         subscribers Topic Filters;  those without wildcards become Topic Names

        Publishers can only publish messages to topic names, and subscribers can wildcard multiple topic names by subscribing to topic filters

Session (Session)
        After each client establishes a connection with the server, it is a session, and there is a stateful interaction between the client and the server. Sessions exist across a network, and may also span multiple consecutive network connections between a client and server.

Methods in the MQTT protocol

        Some methods (also called actions) are defined in the MQTT protocol to represent operations on certain resources. This resource can represent pre-existing data or dynamically generated data, depending on the server implementation. Typically, a resource refers to a file or output on a server. The main methods are:

  • (1) CONNECT: The client connects to the server
  • (2) CONNACK: Connection Confirmation
  • (3) PUBLISH: Publish a message
  • (4) PUBACK: Publish message confirmation
  • (5) PUBREC: The published message has been received
  • (6) PUBREL: The published message has been released
  • (7) PUBCOMP: Publish completed
  • (8) SUBSCRIBE: subscription request
  • (9) SUBACK: Subscription Confirmation
  • (10) UNSUBSCRIBE: unsubscribe
  • (11) UNSUBACK: unsubscribe confirmation
  • (12) PINGREQ: The client sends a heartbeat
  • (13) PINGRESP: server heartbeat response
  • (14) DISCONNECT: Disconnect
  • (15) AUTH: authentication

MQTT protocol packet structure

        In the MQTT protocol, an MQTT packet consists of three parts: fixed header (Fixed header), variable header (Variable header), and message body (payload).
The MQTT packet structure is as follows:

 (1) Fixed header. It exists in all MQTT data packets, indicating the data packet type and the grouping class identifier of the data packet, such as connection, publication, subscription, heartbeat, etc. Among them, the fixed header is necessary, and all types of MQTT protocols must contain fixed headers.
(2) Variable header (Variable header). It exists in some MQTT data packets, and the data packet type determines whether the variable header exists and its specific content. The variable header does not mean optional, but means that this part exists in some protocol types and does not exist in some protocols.
(3) Message body (Payload). It exists in some MQTT packets, indicating the specific content received by the client. Like variable headers, there are message content in some protocol types and no message content in some protocol types.

Fixed Header

The fixed header exists in all MQTT packets.
The fixed header contains two parts:
the first byte (byte 1),
the length of the remaining message message (starting from the second byte, the length is 1-4 bytes), and the
remaining length is The number of bytes of content-length remaining in the current packet, including variable headers and data in the payload). The remaining length does not include the bytes used to encode the remaining length.
The remaining length is encoded using a variable-length structure that uses a single byte to represent values ​​0-127. Values ​​greater than 127 are handled as follows. The lower 7 bits of each byte are used to encode data, and the highest bit is used to indicate whether there are subsequent bytes. So each byte can encode 128 values, plus an identification bit. The remaining length can be represented by up to four bytes.

Data packet type
Position: 7-4 bits in the first byte (Byte 1) are (Bit[7-4]), identifying 4-bit unsigned value

         The type of the message is determined by the upper 4 bits of the first byte. The 4 bits can determine 16 types, of which 0000 and 1111 are reserved fields. The MQTT message types are as follows:

      

 Flag
        position: 0-3 bits (Bit[3-0]) in the first byte. It means that the byte bit Bit[3-0] is used as the identification of the message.
        The lower 4 bits (bit3-bit0) of the first byte are used to indicate the control field of certain message types, in fact, only a few message types have control bits, as shown in the figure below:

 (1): Among them, Bit[3] is the dup field, if the value is 1, it indicates that the data packet is a repeated message; otherwise, the data packet is the first published message (2): Bit[2-1
] For the QoS field:
if both Bit 1 and Bit 2 are 0, it means QoS 0: at most once;
if Bit 1 is 1, it means QoS 1: at least once;
if Bit 2 is 1, it means QoS 2: only once
; If both Bit 1 and Bit 2 are set to 1, then the client or server considers this an illegal message and will close the current connection.
MQTT message QoS
The quality of service (QoS) of MQTT publishing messages is not end-to-end, but between the client and the server. The QoS level of the subscriber receiving the MQTT message ultimately depends on the QoS of the published message and the QoS of the topic subscription QoS
: QoS refers to the quality of service between the client and the server

 Variable Header

        Variable headers mean variable message headers. Some message types contain variable headers and some do not. The variable header is between the fixed header and the message content, and its content varies according to the message type

 Protocol Version
A 1-bit unsigned value representing the version level of the client. Version 3.1.1
MQTT session
When the MQTT client initiates a CONNECT request to the server, the session can be set through the 'Clean Session' flag.
'Clean Session' is set to 0, which means to create a persistent session. When the client disconnects, the session will still keep and save offline messages until the session times out and logs out.
'Clean Session' is set to 1, which means to create a new temporary session. When the client disconnects, the session will be automatically destroyed.
Will Flag /Will QoS/Will Retain Will Flag : Will QoS: Message quality of last words
Will Retain: Last words to keep the state Keep Alive timer (heartbeat duration)


Heartbeat protocol:

 Keep Alive timer maximum time interval

 Message body (Payload)

Some message types contain Payload, and Payload means message carrier.
For example, Payload in PUBLISH refers to message content (message content published by an application). The Payload of CONNECT contains information such as Client Identifier, Will Topic, Will Message, Username, Password, etc.
The types of messages containing the payload are as follows:

        Payload is the content of the message, and it only appears in certain message types. Its content and format also vary according to message types. Specifically, different
message types contain different Payloads. Please check the official documentation.

Guess you like

Origin blog.csdn.net/frelly01/article/details/128109488