The most complete analysis in the history of MQTT protocol (pure dry goods sharing)

What is MQTT?

The full name of the MQTT protocol is (Message Queuing Telemetry Transport), which is the Message Queuing Telemetry Transport Protocol.

It is a lightweight communication protocol based on the publish/subscribe (Publish/Subscribe) model, and the protocol is built on top of the TCP/IP protocol. We know that the TCP protocol itself has the characteristics of high reliability, so based on it The MQTT protocol also has the characteristics of high reliability and low overhead. The reason for the low overhead is that the smallest message transmitted by the MQTT protocol is only two bytes.

In the development of the Internet of Things, MQTT is not the only choice. The protocols that compete with MQTT include XMPP and CoAP protocols.

Regarding the concept of publishing and subscription, let's take the Douyin platform as an example. Each of our users is a client, and Douyin is a server in the MQTT protocol. When we (user 1) follow a certain video publisher ( User 2), such an act of attention can be understood as a subscription; at the same time, user 2 can also follow you, then this is mutual subscription. When user 2 publishes a work, the work is published to the Douyin platform, which is our current server, and this process is the release of news.

It should be noted here that the message published by user 2 (client) is not directly published to user 1, but to the Douyin platform (server). Since user 1 subscribes to user 2's message (equivalent to clicking Follow), so the Douyin platform (server) will push this message to the user (note the difference between publishing and pushing). This is a simple metaphor for MQTT protocol subscription & publication.

The above is a metaphor, let’s compare the actual MQTT protocol communication model:

the realization of the MQTT protocol requires the completion of communication between the client and the server. In the communication process, there are three identities in the MQTT protocol: Publisher (Publish), Broker (Broker) ( Server), Subscriber (Subscribe). 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 load (payload).

• Topic, which can be understood as the type of message, after the subscriber subscribes (Subscribe), he will receive the message content (payload) of the topic
• payload, which can be understood as the content of the message, refers to the specific content to be used by the subscriber

some terms explained

Network ConnectionNetwork Connection

The underlying Transport Protocol (TCP) infrastructure used by MQTT.

• The client uses it to connect to the server.
• It provides ordered, reliable, bi-directional byte stream transfer.

Application Message Application Message

The MQTT protocol transmits application data over the network. When application messages are transmitted through MQTT, they have associated quality of service (QoS) and topic (Topic).

Client Client

A program or device that uses MQTT. Clients always connect to servers over the network. it can

• Publish application messages to other related clients.
• Subscribe to request to receive relevant application news
• Unsubscribe to remove requests to receive app messages.
• Disconnect from the server.

Server Server

A program or device that acts as an intermediary between clients sending messages and clients requesting subscriptions. Server

• Accept network connections from clients.
• Accept application messages published by the client.
• Handles subscription and unsubscription requests from clients.
• Forward application messages to eligible subscribed clients.

Subscribe Subscription

Subscriptions contain a topic filter (Topic Filter) and a maximum quality of service (QoS) level. Subscriptions are associated with a single session. A session can contain more than one subscription. Each subscription to a session has a different topic filter.

Topic Name

A tag attached to application messages that is known by the server and matches a subscription. The server sends a copy of the application message to each matching client subscription.

Topic Filter Topic Filter

An expression contained in a subscription that represents one or more topics to which it is related. Theme filters can use wildcards.

Session Session

Stateful interaction between client and server. Some sessions last as long as a network connection, others can extend across multiple consecutive network connections between the client and server.

Control message MQTT Control Packet

A packet of information sent over a network connection. The MQTT specification defines fourteen different types of control messages, one of which (PUBLISH message) is used to transmit application messages.

MQTT features

1. The client uses it to connect to the server.
2. It provides ordered, reliable, bidirectional byte stream transmission.
3. Use the publish/subscribe message mode to provide one-to-many message distribution and decoupling between applications.
4. Message transmission does not need to know the payload content.
5. Provide three levels of service quality QoS:
6. Very small transmission consumption and protocol data exchange, minimizing network traffic
7. When abnormal connection disconnection occurs, relevant parties can be notified.

Message Quality (QoS)

There are three levels of MQTT message quality, QoS 0, QoS 1 and QoS 2.

QoS 0: Distribute at most once. The transmission of messages is completely dependent on the underlying TCP/IP network. Response and retry are not defined in the protocol. Messages will either reach the server only once or not at all. Messages may be lost. For example, this level can be used for environmental sensor data, where a single loss of data is okay because it will be sent again shortly thereafter.

QoS 1: Deliver at least once. The message received by the server is confirmed by the PUBACK message. If the communication link or the sending device is abnormal, or the confirmation message is not received within the specified time, the sender will resend the message with the DUP bit set in the message header. (guaranteed delivery function)

QoS 2: Distributed only once. This is the highest level of messaging, message loss and duplication are unacceptable, and there is an additional overhead for using this quality of service level. For example, this level could be used in a billing system where duplicate or missing messages would result in incorrect billing.

eg.
The currently popular shared bicycle smart lock, the smart lock can regularly use QoS level 0 quality messages to request the server to send the current location of the bicycle. It does not matter if the server does not receive it, anyway, it will send it again after a period of time. After that, the user can query the location of the surrounding bicycles through the App. After finding the bicycle, it needs to be unlocked. At this time, the QoS level 1 quality message can be used. The mobile phone App will continuously send the unlock message to the bicycle lock to ensure that the message can be reached once to unlock the bicycle. Finally, after the user has used up the bicycle, he needs to submit the payment form, and the QoS level 2 quality message can be used to ensure that the data is only transmitted once, otherwise the user will overpay.

MQTT Control Packet Format

The structure of the MQTT control message

Fixed header	Fixed header, all control packets contain
Variable header	Variable header, some control packets contain
Payload	Payload, some control packets contain

Note: The fixed header must have it, and the variable header and payload can be absent.

[ Fixed header ]: The upper 4 bits of the first byte are the type of MQTT control message + the lower 4 bits of the first byte are used to specify the flag bit of the control message type (only used when PUBLISH publishes a message) + The remaining length is 1~4 bytes (the maximum remaining length field is 4 bytes).
The remaining length includes variable header and payload data.
The remaining length does not include the number of bytes used to encode the remaining length field itself.
The remaining length field uses a variable-length encoding scheme, and for values ​​less than 128 it uses a single-byte encoding. Larger values ​​are handled as follows.
The least significant 7 bits are used to encode data, and the most significant bits are used to indicate whether there are more bytes. So each byte can encode 128 values ​​and a continuation bit.
The maximum remaining length field is 4 bytes.

【Variable Header】: The content of the variable header varies according to the type of the message.
Certain MQTT Control Messages contain a variable header section. It is between fixed header and payload. The Packet Identifier field of the variable header exists in multiple types of packets.
Message identifier (2 bytes): 9 control messages containing message identifiers: PUBLISH (QoS>0), PUBACK, PUBREC, PUBREL, PUBCOMP, SUBSCRIBE, SUBACK, UNSUBSCRIBE, UNSUBACK

Notes on message identifiers:
1. The client and server assign message identifiers independently of each other. Therefore, the combination of client and server using the same message identifier can achieve concurrent message exchange.
2. SUBSCRIBE, UNSUBSCRIBE and PUBLISH (QoS greater than 0) control packets must contain a non-zero 16-bit packet identifier (Packet Identifier) ​​3. Each time the
client sends a new packet of these types, it must be assigned A currently unused message identifier. If a client resends this particular control packet, it MUST use the same identifier when resending that packet subsequently. After the client has processed the confirmation corresponding to the message, the message identifier is released for reuse.
4. PUBLISH packets with QoS set to 0 cannot contain packet identifiers.
5. PUBACK, PUBREC, PUBREL packets must contain the same packet identifier as the originally sent PUBLISH packet. Similarly, SUBACK and UNSUBACK must contain the message identifier used in the corresponding SUBSCRIBE and UNSUBSCRIBE messages.
6. Function: Determine whether these fields need to be included in the variable header based on the flag bit

【Payload】: Some MQTT control messages contain a payload in the last part of the message. For example, for PUBLISH, the payload is the application message.
Control packets that may contain payloads are: CONNECT, PUBLISH, SUBSCRIBE, SUBACK, UNSUBSCRIBE

Fourteen kinds of control messages

Note: C->S refers to the client to the server, S->C refers to the server to the client, C<->S refers to both directions allowing 0 and
15 type values ​​to remain invalid.
The values ​​in the table refer to the upper 4 bits of the first byte of the fixed header, that is, the values ​​of the type of MQTT control message
PUBREC, PUBREL and PUBCOMP only exist at the QoS2 level

Control message No. 1: CONNECT – connect to the server

Note: After the network connection from the client to the server is established, the first message sent by the client to the server must be a CONNECT message.
On a network connection, the client can only send a CONNECT message once. The server must treat the second CONNECT packet sent by the client as a protocol violation and disconnect the client.
The variable header of the CONNECT message contains four fields in the following order: Protocol Name (Protocol Name), Protocol Level (Protocol Level), Connection Flags (Connect Flags) and Keep Alive (Keep Alive)
. An unsigned value indicates the revision of the protocol. For protocol version 3.1.1, the value of the Protocol Level field is 4 (0x04). If
an unsupported protocol level is found, the server must send a CONNACK message with a return code of 0x01 (unsupported protocol level) to the client in response to the CONNECT message, and then disconnect the client. Note: The connection flag byte
contains Some parameters used to specify the behavior of the MQTT connection. It also indicates whether the field is present in the payload. This connection flag will indicate the content of the following payload
Note: The server must verify whether the reserved flag bit (bit 0) of the CONNECT control message is 0, and if it is not 0, the client must be disconnected

CONNECT control message content:
fixed header MQTT 4-bit message type plus 4 reserved bits is 10, the remaining length bytes are determined by the subsequent data length
Variable header fixed protocol name 6-byte length 00 04 + MQTT UTF-8 Encoding 00 04 4D 51 54 54
Protocol level 1 byte 04 represents protocol version 3.1.1
Connection flag 1 byte C2 Set password flag, username flag, clear session flag
Keep connection time 2 bytes 00 78 represents 120 seconds
payload Client ID data length 2 bytes + client ID ASC code + user name data length 2 bytes + user name ASC code + password length 2 bytes + password ASC code

Notice! The payload of the CONNECT packet contains one or more fields prefixed with length, and the connection flag in the variable header determines whether to
include these fields. If included, MUST appear in this order: Client Identifier, Will Subject, Will Message, Username, Password

00 04 4D 51 54 54 | 04 | C2 | 00 78 | 00 09 35 32 38 39 38 36 38 37 35 | 00 06 32 34 38 34 39 33 | 3 6B 64

The fixed header 0x10 means that the client requests to connect to the server. The
fixed header 0x25 means that the variable header and payload have a total of 37 bytes of data, which is not included in the
protocol name. 00 04 4D 51 54 54, 00 04 means 4 bytes, 4D 51 54 54 is the UTF-8 encoded string (also ASC code value) of MQTT.
Protocol level 04 client uses 8-bit unsigned value to indicate the revision version of the protocol. For the version 3.1.1 protocol, the value of the protocol level field is 4 (0x04), the connection
flag C2
keeps the connection 00 78, that is, 120 seconds
00 09 35 32 38 39 38 36 38 37 35 Device ID, 9 bytes, ASC code of 528986875 , same below
00 06 32 34 38 34 39 33 Product ID 248493
00 06 6B 66 62 73 6B 64 Authentication information kfbskd

Control message No. 2: CONNACK – confirm connection request

Note: The server sends a CONNACK message in response to the CONNECT message received from the client. The first packet sent by the server to the client must be a CONNACK packet.
If the client does not receive the CONNACK packet from the server within a reasonable time, the client should close the network connection. A reasonable time depends on the type of application and communication infrastructure.
The content of the CONNACK control message:
the fixed header MQTT 4-bit message type plus 4 reserved bits is 20, and the remaining length bytes are determined by the subsequent data length
Variable header two bytes: connection confirmation flag (the first 7 bits must be 0 , the lowest bit depends on the cleanup session flag in the connection flags) + connection return code (normally 00, otherwise indicates failure)
payload None

Message example:
20 02 01 00
fixed header 20 02: 20 marks message type 2, 02 remaining length
variable header 01 00
payload none

Control message No. 3: PUBLISH – publish a message

The PUBLISH control message refers to the transmission of an application message from the client to the server or from the server to the client.
The client uses the PUBLISH message to send the application message to the server, with the purpose of distributing it to other clients with matching subscriptions.
The server uses the PUBLISH message to send the application message to each matching client.

Message content composition:
the high 4 bits of the first byte of the fixed header are message type 3, the low 4 bits are the DUP retransmission flag-QoS level high-QoS level low-reserved bits, and the second byte is the remaining length
Variable header The variable header contains the subject name (UTF-8 encoding) and message identifier in sequence. There are two bytes of topic name before the topic name, and the message identifier is two bytes.
Note that the message identifier is only present in the message of QoS class 1 and 2, class 0 is not directly ignored
Payload The payload contains the application message to be published. The content and format of the data is application specific. The length calculation is the remaining length - the length of the variable header

Regarding the DUP retransmission flag: If the DUP flag is set to 0, it means that this is the first time that the client or server requests to send this PUBLISH message. If the DUP flag
is set to 1, it indicates that this may be a retransmission of an earlier message request.
The DUP flag must be set to 1 when the client or server requests to resend a PUBLISH packet. For QoS 0 messages, the DUP flag shall be set to 0.

Regarding the QoS level flag bits: PUBLISH packets cannot set all QoS bits to 1. If the server or client receives a PUBLISH message with all QoS bits set to 1, it must close the network connection

Regarding reserved bits: If the RETAIN flag of the PUBLISH message sent by the client to the server is set to 1, the server must store the application message and its quality of service (QoS) so that it can be distributed to future Subscribers whose topic names match.
If the client sends a PUBLISH message to the server with the reserved flag bit 0, the server MUST NOT store the message nor remove or replace any existing reserved messages.

Message example:
30 0E 00 09 6B 66 62 5F 74 6F 70 69 63 31 32 33 QoS level 0 data: 123, level 0 no reply

32 10 00 09 6B 66 62 5F 74 6F 70 69 63 00 01 31 32 33 Level 1 Data: 123

34 10 00 09 6B 66 62 5F 74 6F 70 69 63 00 01 31 32 33 Level 2 Data: 123

The topic name here is kfb_topic: 6B 66 62 5F 74 6F 70 69 63, before the topic name there is a length of two bytes topic name 00 09 message
identifier is only in the message of QoS class 1 and 2, in the example The message identifier is 00 01

No. 4 control message: PUBACK – release confirmation

The PUBACK message is the response to the QoS 1 PUBLISH message.

Message content composition:
fixed header message type 40 + remaining length 02
variable header contains two bytes of message identifier of the PUBLISH message waiting for confirmation. The specific content depends on the message identifier in the previous PUBLISH message.
Payload None

Message example:
40 02 00 01 Reply of level 1, indicating receipt
Fixed header 40 02: 40 marks message type 4, 02 remaining length
Variable header 00 01 is consistent with the message identifier of the PUBLISH message waiting for confirmation
Payload none

Control message No. 5: PUBREC - release received (QoS 2, first step)

The PUBREC message is the response to the QoS class 2 PUBLISH message. (Usually replied by the receiver) It is the second message exchanged by the QoS 2 level protocol.

Message content composition:
fixed header message type 50 + remaining length 02
variable header contains two bytes of message identifier of the PUBLISH message waiting for confirmation. The specific content depends on the message identifier in the previous PUBLISH message.
Payload None

Message example:
50 02 00 01 is the first reply from the server at level 2, there are two replies at level 2, the client sends 62 02 00 01 again, and the second reply 70 02 00 01 from the server indicates that the header 50 02 has been fixed
successfully : 40 marks the message type 5, 02 remaining length
Variable header 00 01 Consistent with the message identifier of the PUBLISH message waiting for confirmation
No payload

Control packet No. 6: PUBREL - publish release (QoS 2, second step)

The PUBREL packet is the response to the PUBREC packet. (Usually sent by the sender) It is the third message exchanged by the QoS 2 level protocol.
Notice! Bits 3, 2, 1, and 0 of the fixed header of the PUBREL control packet are reserved bits and must be set to 0, 0, 1, 0. Servers MUST treat any other value as invalid and close the network connection.

Message content composition:
fixed header message type 62 + remaining length 02
variable header contains two bytes of message identifier of the PUBLISH message waiting for confirmation. The specific content depends on the message identifier in the previous PUBLISH message.
Payload None

Message example:
62 02 00 01 Level 2 Ask again

Control message No. 7: PUBCOMP - publication complete (QoS 2, step 3)

The PUBCOMP packet is the response to the PUBREL packet. (Usually replied by the receiver) It is the fourth and last message exchanged by the QoS 2 class protocol.

Message content composition:
fixed header message type 70 + remaining length 02
variable header contains two bytes of message identifier of the PUBLISH message waiting for confirmation. The specific content depends on the message identifier in the previous PUBLISH message.
Payload None

Message example:
70 02 00 01 The second reply of level 2, indicating complete completion

Control message No. 8: SUBSCRIBE - subscribe topic

The client sends a SUBSCRIBE message to the server to create one or more subscriptions.
To forward application messages to topics matching those subscriptions, the server sends a PUBLISH packet to the client.
The SUBSCRIBE message also specifies (for each subscription) the maximum QoS level, and the server sends application messages to the client according to this.

Message content composition:
fixed header message type 82 + remaining length
variable header message identifier two bytes.
Payload topic filter length 2 bytes + topic filter (+ [can contain multiple] last topic filter length 2 bytes + topic filter +) quality of service level 1 byte only the lower two bits are valid

The payload of the SUBSCRIBE packet must contain at least one pair of Topic Filter and QoS Class field combinations.
Each filter is followed by a byte, this byte is called the quality of service requirement (Requested QoS). It gives the maximum QoS level allowed by the server to send application messages to the client.

Message example:
82 0E 00 0A 00 09 61 70 70 5F 74 6F 70 69 63 00 Level 0
82 0E 00 0B 00 09 61 70 70 5F 74 6F 70 69 63 01 Level 1
subscribed topic named app_topic: 61 70 70 5F 74 6F 70 69 63, the preceding 00 09 is the subject name length

Control message No. 9: SUBACK – subscription confirmation

The server sends a SUBACK message to the client to confirm that it has received and is processing the SUBSCRIBE message.
The SUBACK packet contains a list of return codes specifying the maximum QoS class to be granted for each subscription requested by the SUBSCRIBE.

Message content composition:
fixed header message type 90 + remaining length
variable header variable header contains the message identifier of the SUBSCRIBE message waiting for confirmation. two bytes.
The payload is a graded reply to the last Subscribe Topic message. The number of bytes is the same as the number of topic filters in the previous SUBSCRIBE message.
The payload contains a list of return codes. Each return code corresponds to a topic filter in the SUBSCRIBE packet awaiting acknowledgment. The order of the return codes MUST be the same as the order of the topic filters in the SUBSCRIBE message.
Allowed return code values:
0x00 - Max QoS 0
0x01 - Success - Max QoS 1
0x02 - Success - Max QoS 2
0x80 - Failure

Message example:
90 03 | 00 0A | 00 corresponds to the message identifier of the first subscription above
90 03 | 00 0B | 01 corresponds to the message identifier of the second subscription above

Control message No. 10: UNSUBSCRIBE – unsubscribe

The client sends an UNSUBSCRIBE message to the server to unsubscribe from the topic.

Message content composition:
fixed header message type A2 + remaining length
variable header variable header contains a message identifier. two bytes.
Payload The payload of the UNSUBSCRIBE packet contains a list of topic filters that the client wants to unsubscribe from. Length 2 bytes + subject filter (+length 2 bytes + subject filter)
The payload of an UNSUBSCRIBE message must contain at least one message filter.

Message example:
A2 0D 00 0C 00 09 61 70 70 5F 74 6F 70 69 63
00 0C is the message identifier
Topic name app_topic, namely 61 70 70 5F 74 6F 70 69 63, the preceding 00 09 is the length

Control message No. 11: UNSUBACK – unsubscribe confirmation

The server must send an UNSUBACK packet in response to the client's UNSUBSCRIBE request. The UNSUBACK packet must contain the same packet identifier as the UNSUBSCRIBE packet

Message content composition:
fixed header message type B0 + remaining length 02
variable header The variable header contains the message identifier of the UNSUBSCRIBE message waiting for confirmation. two bytes.
Payload None

Message example:
B0 02 00 0C
00 0C corresponds to the last unsubscribed message identifier

Control packet No. 12: PINGREQ – heartbeat request

The client sends a PINGREQ message to the server. Used for:

1. Inform the server that the client is still alive when no other control packets are sent from the client to the service.
2. Asks the server to send a response confirming that it is alive.
3. Use the network to verify that the network connection is not lost.

Message content composition:
fixed header message type C0 + remaining length 00
variable header no
payload no
server must send a PINGRESP message to respond to the client's PINGREQ message

Telegram:
C0 00 (only this one)

Control packet No. 13: PINGRESP – heartbeat response

The server sends a PINGRESP message in response to the client's PINGREQ message. Indicates that the server is still alive.

Message content composition:
fixed header message type D0 + remaining length 00
variable header no
payload no

Message:
D0 00 (only this one)

Control message No. 14: DISCONNECT – disconnect

The DISCONNECT packet is the last control packet sent by the client to the server. Indicates that the client "gracefully" disconnected.

Message content composition:
fixed header message type E0 + remaining length 00
variable header no
payload no

Message:
E0 00 (only this one)

Note: After the client sends the DISCONNECT message:
1. The network connection must be closed.
2. No more control packets can be sent through that network connection.
When the server receives a DISCONNECT packet:
1. MUST discard any unpublished will messages associated with the current connection.
2. The network connection should be closed, if the client has not already done so.

About the connection flag in the CONNECT control message

About the password flag:
If the password (Password) flag is set to 0, the payload cannot contain a password field.
If the Password flag is set to 1, a password field must be included in the payload.
If the username flag is set to 0, the password flag must also be set to 0.

Regarding the user name flag:
If the User Name (User Name) flag is set to 0, the payload cannot contain a username field.
If the User Name flag is set to 1, a User Name field must be included in the payload.

Regarding the Will Retain bit:
If the Will Retain flag is set to 0, the Will Retain flag must also be set to 0.
If the will flag is set to 1:
1. If the will reserved is set to 0, the server MUST publish the will message as a non-retained message.
2. If will reservation is set to 1, the server MUST publish the will message as a reservation message.

About Will QoS bits:
These two bits are used to specify the quality of service level used when publishing will messages.
If Will Flag is set to 0, Will QoS must also be set to 0 (0x00).
If the will flag is set to 1, the value of Will QoS can be equal to 0(0x00), 1(0x01), 2(0x02). Its value cannot be equal to 3.

About the will flag bit:
the will message is issued by the server, usually the message released immediately after the disconnection. The
will flag (Will Flag) is set to 1, indicating that if the connection request is accepted, the will message (Will Message) payload) must be stored on the server and associated with this network connection. Afterwards, when the network connection is closed, the server must publish the will message, unless the server deletes the will message when it receives the DISCONNECT message

Conditions for release of will news, including but not limited to:

• The server has detected an I/O error or network failure.
• The client fails to communicate within the Keep Alive time.
• The client closes the network connection without first sending a DISCONNECT message.
• The server closed the network connection due to a protocol error.

If the will flag is set to 1, the Will QoS and Will Retain fields in the connection flag will be used by the server, and the Will Topic and Will Message fields must be included in the payload. Will messages MUST be removed from stored session state once published or upon receipt by the server of a DISCONNECT packet from the client.
If the will flag is set to 0, the Will QoS and Will Retain fields in the connection flag must be set to 0, and the Will Topic and Will Message fields cannot be included in the payload. When the network connection is disconnected, the server cannot send the will message.
The server should quickly publish the will message when the condition is met. In the event of a shutdown or failure, the server MAY defer publication of will messages until a later restart.
If this happens, there may be a delay between the server failure and the will message being published.

About cleaning session flags:
Specifies how session state is handled. Clients and servers can save session state to support reliable message transfer across network connections. This flag is used to control
the lifetime of the session state.
If the CleanSession flag is set to 1, the client and server MUST discard any previous session and start a new one. A session only lasts as long as the network connection. State data associated with this session cannot be reused by any subsequent sessions.
Clients with the clean session flag set to 1 will not receive old application messages and will need to re-subscribe to any related topics after each successful connection.
To ensure consistent state in the event of a failure, the client should repeatedly request a connection with session state flag 1 until the connection succeeds.
(usually set to 1)

About the keep-alive time in the CONNECT control message

Keep alive (Keep Alive) is a time interval in seconds, expressed as a 16-bit word, which refers to the time between the moment when the client transmits a control message and the time when the next message is sent. The maximum interval of time allowed to be idle. The client is responsible for ensuring that the time interval for sending control packets does not exceed the value of keep-alive. If there are no other control packets to send, the client MUST send a PINGREQ packet.
Regardless of the value of keep-alive, the client can send a PINGREQ message at any time, and use the PINGRESP message to determine the activity status of the network and server.
If the keep-alive value is non-zero, and the server does not receive the client's control packet within 1.5 times the keep-alive time, it must disconnect the client's network connection and consider the network connection to be disconnected.
After the client sends the PINGREQ message, if it still does not receive the PINGRESP message within a reasonable time, it should close the network connection to the server.
A value of zero for keepalives turns off keepalives. This means that the server does not need to disconnect because the client is not active, that is, it can always keep connected. Note:
Regardless of the value of keep-alive, at any time, as long as the server thinks that the client is inactive or unresponsive, it can disconnect the client.
The actual value for keepalives is application-specific, typically a few minutes. The maximum value allowed is 18 hours 12 minutes and 15 seconds.